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.