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.