Iteration discipline: another Agile mind-shift – level 200

In an effective organization, discipline is key. You can't run a loose ship and expect to be effective. One of the disciplines that his hard to master is speculation.

Speculation

When working on a story, the developer team might have questions or even ideas for improvement. A common temptation is to speculate about a solution that seems right to the developer(s). Sometimes this speculation is correct, and sometimes it isn't. Either way, developers should not speculate about business value. Note that I am assuming we have a healthy organization where a product manager (or customer) is actually planning the software and thinking about business value. In this environment, the customer is responsible (and qualified) for determining priority based on business value. A customer is charged with knowing the problem domain and making decisions about what software to write to fulfill the business need. Developers take this business landscape and deliver a technical solution to the business problem. Developer speculation can hurt productivity when developers start making assumptions about the business problem.

I talk about discipline because it takes effort sometimes to force the customer to make business decisions. Developers are the technical experts, and customers are the business experts. Just as a customer is not qualified to make assumptions about technical feasibility or technical estimates, a developer is not qualified to make assumptions about business value or priority. When I say "qualified", I mean it is not their role in the organization.

How to beat developer speculation (or guessing)

Keep the customer onsite so that the communication overhead is very low. That way whenever questions come up, the source of information is right there.
Plan the iteration effectively. An iteration planning meeting should model and task out the work planned for the iteration. Whether if be one, two, or three weeks, do a good job planning so that all big questions are answered up front (or spikes are declared for specific items). Lean on the customer during the iteration for smaller, detailed questions. If you have a hard time planning for your three-week iteration, shorten the iteration to one or two weeks.
Focus on delivering software. Focus on the iteration. For the individual developer, that means trusting your customer and manager. Developers are creative and have good ideas. These ideas should be communicated to the customer, but the customer is responsible for integrating those ideas into the roadmap. An idea that pops up mid-week should not halt the iteration unless it was something critical that was missed. Planning (in detail) only a short period of time allows for changing course rapidly since each iteration's plan is defined in real-time. Remember, the customer (or customer representative) is always planning the future roadmap.
Don't tolerate it. This is more of a management item. It's a slippery slope. If a little speculation (or developer-driven business plan) is allowed, then more will follow. Be clear about the roles of the development organization, and have the developers enforce this discipline within the team. All technical discussions should focus on iteration deliverables.

What about planning ahead to prevent major technical problems?
Someone on the team should be a strong enough developer to understand these issues. This is not a role, but more a capability. If the team is filled will strong developers, then any developer is capable of seeing a roadblock coming. If the team is more junior with only one senior dev leading the way, then it will fall on that person's shoulders, but this is more of a team-makeup issue. In practice, with strong people, you have high-quality, loosely coupled, well-tested code that is delivered every iteration. In this healthy environment, the code is easy to change to react to business decisions down the road. If you have good people, they won't be coding into a roadblock.

What's the secret?
No secret. Get good people, and they will deliver good software. There is no cookie-cutter process that magically turns a dysfunctional developer culture into an effective one. Good people, driven by Agile principles formulate a good process and deliver good software.

Jason Haley 7:50 pm on November 10, 2006

Very interesting point. It seems that most the time knowing the development side is a major drawback to how useful the system really can be … unless of course you have yoda like discipline 🙂
Scott 12:58 am on November 11, 2006

“Note that I am assuming we have a healthy organization where a product manager (or customer) is actually planning the software and thinking about business value”

Where can I find one of those? It seems to me that a GOOD product manager is hard to come by, and the “business value” they deliver is sub-par. The developers that I’ve worked with in the past know more about the product being delivered than the product manager, and have no choice but to “speculate” about design decisions because their leader isn’t qualified to do it for them.

I also think “speculation” may be an unfair word to describe a developer’s ideas. Just because they aren’t directly involved with the customer doesn’t mean that their ideas are without merit. Imposing rules that are in-effect limiting developer creativity seems counter-intuitive to me. How can a product manager (unless they are developers as well) know the best solution to a problem?

I do agree that the solution is to erase any “dysfunctional developer culture” that may exist, but I’d like to add that it is also important to change how developers are perceived by others in the organization. When developers are viewed as little more than sacks of meat that can talk to a computer, it does very little in the way of productivity/effectiveness.

I just realized that all of this sounds a little rant-y, sorry about that 😉
jpalermo 6:39 pm on November 12, 2006

Scott,
“It seems to me that a GOOD product manager is hard to come by. . .”

Sad, but true. The “Customer” is a role on a development team. A lot of the time folks have to fill more than one role, and that certainly doesn’t exclude Customer. Someone should be filling the role of Customer, and it’s that role that is responsible for business value decisions. I, too, have worked in a situation where I had to double as Customer and talk with eventual end-users to determine what would be useful and what would not be. If a developer has to also fill the role of Customer, then you do what you have to do.

“Just because they aren’t directly involved with the customer doesn’t mean that their ideas are without merit.”

You are correct, sir. Please refer to my 3rd bullet point: “Developers are creative and have good ideas. These ideas should be communicated to the customer, but the customer is responsible for integrating those ideas into the roadmap.”

There are also two types of solutions. Business solutions may be “allow action by using a right click”, but the technical solution might be “use XXXX 3rd party library to accomplish XXXXX”.

I agree with you about perception of the developer. At some companies, management treats them like a commodity. At my company, developers enable our core business, and not all developers are the same. A good developer is 10X more productive than an average developer (or more). Coming straight from development, I manage with this in mind. I know the developers I’m looking for, and I know how to stay away from the average ones. It’s not completely managements fault though. Our industry has so many bad developers, and it brings the industry batting average down. There is no accreditation process to work on software. There needs to be.

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

Iteration discipline: another Agile mind-shift – level 200

Related