Are you a scrum master, coordinating with another team? You might be told, “Why isn’t that done? It should be ready by now.”

Are you a business analyst, talking about a change that doesn’t impact today’s stories? You might be told, “Don’t mention it during the stand-up meeting.”

Are you QA, trying to determine if this is a bug or not? You might be told, “Don’t you see the developers are busy? Why did you interrupt them while they were coding?”

And so on.

It’s an epidemic. Agile developers treat their non-dev teammates as part of their personal fiefdom, there to serve. Preferably quietly, so you don’t interrupt their thinking while they are developing. And woe unto those who are not present when called upon.

Developers are the gravitational center of the team. Everyone and everything revolves around them. For the last 5 years I’ve been saying, “Agile is methodology by developers, for developers.” I’ve been watching this behavior for years. It’s irritated me for years. But is it wrong? Should developers be the center of a team’s universe?

Where’s the value?

First, we need to agree on a basic metric. The only time software is valuable is after it has been delivered to the users. Software sitting in on personal workstation doesn’t add value to a business or consumer. Software waiting for the next release cycle isn’t providing anyone any value. It might be “done,” but it’s not giving anyone any benefits until it’s used.

I’m a business analyst. It’s incredibly important to understand the business goals when you’re building software. A good scope document doesn’t add value. Detailed specifications don’t add value. Designs and tests and servers do not add value, either. Only working software—working in the hands of users—has a chance to deliver value.

If working software is the primary measure of how we add value (See Agile Manifesto Principles), then we need to organize the software development process to get more software out the door. How do we do that?

Eliyahu Goldratt, a physicist who became a management guru, noticed manufacturing lines were organized to maximize the use of all the machines. This was making accountants happy, but it caused problems with extra work, waste, and a growing warehouse full of partially completed products. Goldratt determined manufacturers can make more money by organizing their production lines for consistent throughput around the bottlenecks (constraints).

The same problems, and solution, affect software development. Agile provides a set of tools for software projects, optimizing for the bottleneck, developers. Keeping developers focused leads to a more productive team. Optimizing for developer throughput (for example, having BAs and QAs nearby to answer their questions) means working software is delivered sooner. Optimizing for developers means you increase the chance real value will be delivered. Because the real value of software comes only after it’s delivered, it makes sense to be organized around developers.

What about other bottlenecks?

The truth is, processes have more than one bottleneck. After you optimize for the first bottleneck, you need to be ready to discover the next one. It takes diligent focus to watch the process and work on the next bottleneck. You cannot stop at the first one; bottlenecks are everywhere and you need to continue to watch and optimize.

Developers, because of their role, have a huge number of bottlenecks. They need the right level of requirements, properly configured workstations, the right tools, a good environment for checking in their code, time to understand the technology stack, available test systems and data bases, automated tests, and so on. If you are on a project long enough, you may find this list whittled down. I have never seen it eradicated, but I have seen it get pretty small.

What’s right?

Unfortunately, and I think this was part of my ongoing frustration, teams are not good at optimizing for other parts of the process. I’ve been parts of teams where the biggest bottleneck isn’t with supporting the developers, it’s with the testing or requirements supporting development. It’s not that teams cannot say, “I see you need help over there.” Rather, they seem to acknowledge the problem and then think it will go away.

Agile is right. Organizing your team for consistent throughput of working software provides the most value to customers. Supporting developers leads to better software, quicker. It’s the teams that are failing the process. When your team has a problem, discuss it. Work on it. Eliminate it.

Agile isn’t just for developers, but it will be if you don’t pay attention.

Do you agree, is this the right way to develop software?
Do you think it’s a problem? Why? Please leave your comment below.

Don’t blame me for the extra “l” in “modelling,” Chris Matts came up with the title and he’s from the UK. They claim to know the “mother tongue” better than we do in the states, but they sure do get a bunch ...

I will be giving a new version of my talk about Behavior Based Requirements at this year’s Professional Development Day in Minneapolis / St. Paul. I am excited because I have reworked the entire presentation to both show my passion and give attendee...

Apr 9, 2013

10Comments

Jake Calabrese • 2012-05-24T09:41:58+00:00

Great post – I think the idea you bring up is a serious issue. It often seems like we are sub-optimizing “writing code” in the software development process or even software development rather than solution development. While there are certainly some (many?) who would argue this point, customers do not want software, they want solutions. The focus has to be on the organizations ability to deliver valuable solutions – everyone has to be involved!

Pankaj Kanchankar • 2012-05-25T07:37:02+00:00

A great post indeed. I have worked on agile teams for more than 3 years. Agile teams are centered towards devs as most of the times they are the bottleneck. On my team when they are not, say QA is bottleneck then team recognises that and take up qa activities. They even help in test automation. We have QAs pitching in for story detailing when BA bandwidth is the constraint. I agree that it is a team thing. Agile always emphasised on self organising team that takes care of such scenarios.

Thanks for your comments. You’re right, a good self-organizing team takes care of these problems. And I am glad your team is doing well helping each other. Congratulations.

Craig Fox • 2012-05-25T10:33:05+00:00

I agree in that the analysis and development process itself does not add much value to a business in itself. The result of having proper functioning solution that meets the business need is of critical value. Regardless of the development methodology, the Project Manager needs to remove obstacles, unclog bottlenecks and coordinate resources for developers, BA’s, QA, and technology. That includes making sure there is appropriate availability and accessibility to support the developers. After all, without them, the only deliverable that the business cares about does not exist.

“Software” or “Solution”? It makes a difference. Software Development needs, well, software developers. Solution Delivery often does not need software development…or developers.

I say this a lot in discussions like this, but I will say it again: over the decades I have done requirements for a lot of projects, but I would say I can count on the fingers of one hand the number of projects that were brand new software development. The solution when a new system was needed was most often a purchased package, the rest of the projects were for enhancements to existing systems; developers did that work but it was not software development.

My take is that the most important part of “Agile Software Development” is the “Software Development”. I am sure I have not seen anything that calls itself “Agile Solution Delivery” …just did a google search and anything that came up was still about software development.

By the way, about those new development projects I was involved with; they were done in-house for companies that whose business was selling insurance or delivering packages or leasing big green farm equipment, i.e. not software companies. Even if the project was a success, delivered a useful and effective system, the effort usually so ‘exhausted’ the IT department people(and/or the business budget for IT)that the next big project would start with the stated strategy “let’s look at packages this time, development will be considered only if there is absolutely nothing we could buy.” …and that is pretty much what happened, packages were bought. …and that has become easier to do as the better package products have become more configurable; the need to “change the package code” has fallen dramatically.

So, if you really need to develop new software, go Agile all the way; just be sure you really need new software to deliver a solution to the business.

Firstly, great contribution to what is still an ongoing debate (although for someone who started with DSDM in 1994, I’m not sure why it is still an ongoing debate after nearly 20 years).

The value is in that which enables an organisation to better achieve its goals; delivering software alone is seldom the thing that delivers the value. It is of course part of developing the capabilities of an organisation, but will achieve nothing at all if end-users are not trained, if sales and customer support are not readied to be able to sell it and support customers through their experience life-cycle, if finance cannot bill for it, and marketing have not promoted it.

There are a lot of other factors required to be in place to realise the value, and all too many teams focus solely on technical delivery … so they pat each other on the back for a job well done and leave others to clear up the mess and finish the job. The focus of any project has to be ensuring that the value/benefit gets realised, involving all the disciplines that requires. And as David Wright points out, this often does not involve software development (i.e. sometimes it is just process change, policy implementation, training, shop-fit out, etc.).

Bottlenecks occur with any of these disciplines. You’re right that we should continue to work to eliminate bottlenecks. Most implementations of the agile manifesto serve the developer first, foremost, and only. However this is short-sighted, another example would be the testing team. As fast as developers work, if the test team are not geared up to handle what the developers deliver, then you get another pile-up on the conveyor belt. Should we then change our approach to work around the needs of the testing team? Well, yes and no.

We do need to inspect and adapt all the time, and that will necessarily affect all disciplines involved. One area where focusing more will generate better outcomes is effective analysis at the last responsible moment (but then I would say that, wouldn’t I).

Yes Scrum is designed to change with the business etc – but in reality… if only the development team work is tracked through the scrum then all other work can be seen as invisible – all the prep that a sprint needs from the product owner and the business gets hidden. The developers can be seen as the most important people (because they are the most expensive?). The idea that a well functioning agile adoption should result in people working sustainable hours (i.e. not huge amounts of overtime) seems to only apply to the development team. As a product owner I have felt that I have a constantly clamouring nest of chicks saying ‘feed me feed me’ …….it’s all too easy to have the TEAM as king in Scrum and everything else serving that (and you’re not part of the team as business or Product Owner)

Update: June 18
As of today, the LinkedIn Agile Business Analysis discussion now has 28 comments in the ongoing conversation about if / how / why Agile is focused on Developers. It’s a must read part of this discussion.

Jake Calabrese • 2012-05-29T11:16:22+00:00

The question: ‘what is the most important part of “agile software development”‘ – emphasizes the point – it focuses on software. But, what if we did not ask that question. We need to ask what is most important about agile or agility. I agree (@David), we do not see much about “non-IT agile” (e.g. agile solution delivery), but we see some – and we will continue to see even more. The amazing thing about agile is not software, it’s the people, collaboration, teams, learning, and self-organization (feel free to add more). If agile thinking is limited to software, we do the world a disservice.

Great question and a good post. The responses seem to fall into two types I’m happy to see: some focus on efficiency, the thread evident in the posting, while others have rightly focussed on effectiveness. It’s the classic distinction between “doing it right” and “doing the right thing”. Agile implementations that deliver high quality software quickly and efficiently can still fail to deliver value.

Put another way, running at full tilt into a dead-end alley does not produce a good result. So yes, Agile has been focused too much on the development team by many of its implementors. That’s why Dan North (@tastapod) came up with with what he calls Feature Injection (Correction: originator was Chris Matts) and why excellent practitioners like Liz Keohg (@Lunivore) weave it into their work.

While it could be argued that the development team and technical practices used are not part of “doing the right thing” that’s not entirely right. If the “development” process extends all the way to deployment, resulting in getting working software into the hands of actual customers so that the marketplace can provide feedback, then the development process is involved. Yes, this requires the business to have the will to make this happen and to adopt practices that allow it to happen.