Aligning Stakeholders with Iterative Development

Iterative and Incremental Delopment

Are you challenged with getting your stakeholders to agree on one requirement? If so, don't feel alone. It's not uncommon as a business analyst to be stuck in the invidious position of reconciling the interests of disparate stakeholder groups. You'd like to think this would be handled at a level higher than you–and in an ideal world it would–but in many cases it's left to the business analyst to handle the negotiation that gets everyone's agreement on the same requirements document. In my experience, much of the debate from any given stakeholder camp is driven by opinion and unqualified assumption. In this case it may be wise to adjust your project to an iterative development style.

Incremental Not Required

Iterative and incremental development (IID) has been used for decades to mitigate against the risk of uncertainty and at least the iterative part can come in handy to raise the collective comfort among your stakeholders. If your stakeholders are arguing about what the “right solution” should look like, their arguments are likely coming more from a place of anxiety and less from a place of certainty. Iterative development means cycling over the entire scope until it looks right. It’s often coupled with incremental development (hence IID) which means building the scope in small pieces at a time. Incremental development can be useful for some purposes (e.g., small wins); however, iterative development is more valuable for bridging alignment. It’s fine to use incremental development if it fits your purpose, but it’s not required to resolve stakeholder alignment issues.

Agile Not Required

The other thing that's not required is a full-blown agile methodology like Extreme Programming or Scrum. Iterative methodologies have been overshadowed by the emergence in popularity of agile software development (and all the flavors thereof), so the distinction has been lost on many. There's a very important difference between agile methodologies and iterative methodologies (which are a superset of agile), mainly in the area of human dynamics. Agile methodologies require self-organizing teams, high levels of collaboration, and a lot of inviolable rules that everyone must adhere to. This puts a lot of pressure on the coach or project manager to protect the methodology. None of this is required on an iterative project. The only requirements are time-boxes of a predetermined length and the understanding that you'll build the solution a few times to flush out the uncertainty.

Scope Freeze Eventually Required

This isn't a never-ending ScopeFest though. The other distinction between iterative and agile development is the intention of how scope is handled. Agile methodologies are generally more relaxed on what direction the scope takes. As long as fully-functional software is deployed at the end of each sprint or iteration, agile projects are happy to take the scope in any direction the end users want. This is not so with iterative development. Sure, there will be some discovery along the way, but the overall theme with iterative development is that you're progressively removing uncertainty. At some point, you'll be close enough to freeze scope–and that's exactly what you should do. I generally like to target at least three and not more than six iterations before it's time to stop arguing and lock down the scope.

Conclusion

If you're struggling to get your stakeholders on the same page, iterative development might be the answer. It's a whole lot better than being lodged in analysis paralysis while stakeholders argue over who's right. If you keep it simple and focus on iterating over the solution until everyone's satisfied, then you have a good shot of success. Stay away from agile if you can and drive the uncertainty out until you can freeze scope. Talk to your project manager today about shifting your development style to an iterative approach. Otherwise, you might be stuck in stakeholder gridlock for a long time.