November 25, 2013

Agile Requirements Uncertainty

<I wrote this article first for ProjectManagement.com here as part of their Requirements series>

Agile approaches are often used on projects where the end goals are not fully known or may change during the life of the project. This seems unusual to my engineering PM friends who manage the fabrication of facilities. To them, not knowing what it is you are supposed to be building or letting things change along the way is a sign of poor scope definition, requirements gathering, and change control. I hear quips from them along the lines of: “You guys need some rigor and decent specifications, maybe then you could build IT systems that work and don’t go over budget!”

They are right of course, for their domain of defined repeatable projects; first establishing a well formed scope definition and complete specification is the way to go. However, many IT projects are not defined, repeatable endeavors, but instead design explorations into unchartered territory for that organization. The mix of technology has not been used that way before. Sponsors have a vision of the end state, but not a lot of specific detail. No matter how much upfront work is done there seems a host of unknown issues that surface during the journey to the destination. Build/ feedback cycles with adaptive plans and progressive elaboration of requirements is the way to deal with these inevitable uncertainties.

These intangible, unprecedented, emergent, evolving characteristics of IT projects are difficult to explain, but need to be understood. They impact how we plan and execute today’s knowledge worker projects as well as how we should manage requirements. When the specifications are clear such as “A kitchen reno with new counter tops and appliances” then simple, signed off requirements can work well. Yet when things are more vague such as “A winter vacation to someplace warm” remaining flexible to changes and new ideas can be valuable.

Let’s look at some of the differences between plan driven, traditional practices for requirements management and those used in agile methods:

Learning and applying traditional methods of requirements management is easy, it is akin to a shopping list approach. We ask questions like “Did you get milk?”, “Did you get the bread?”, “What else do we need?” Changes may be declined or accommodated. “Billy wants some chocolate!” too bad, tell him he can’t have any, or “Oh, I remember we need light bulbs!” We can then ask do we have enough money for light bulbs, do we have time to go find them, etc. It is all pretty much second nature.

Agile requirements management on the other hand is less intuitive. The constant reprioritization, comparison of new ideas with remaining features, and focus on business value has more balls in the air. Like packing a backpack for a multi day camping trip we are always weighing up the benefit verses the size / weight penalty of bringing something along while keeping an eye on an ever changing weather forecast. There is more re-evaluation, more substitutions, more “Do you really need it?” type questions.

Traditional requirements management has a more satisfying progression of closure – Feature A is in the signed off spec, so we are doing it! This is like saying it was on the shopping list so we will buy it. The fact that it may then sit in a cupboard and never be used is a separate discussion. Agile requirements management lacks this reassuring closure since all remaining items are up for reprioritization or substitution until the completion of the project. Our shopping list is being changed as we walk around the store and that makes some people uncomfortable. However, fewer items should go unused.

In the end it comes down to trading off certainty against flexibility and value optimization within your purchasing decision. If you know you want a vacation at the Hotel Del Coronado in San Diego and that ticks all your boxes then you can lock down the requirements early, book it and be done with it. If you are not sure if the twins will be joining you for a vacation and are looking for the best value 4 star hotel; you will want to keep your options open longer and have some flexibility to best satisfy your purchasing needs.

Comments

Your comment "many IT projects are not defined, repeatable endeavors, but instead design explorations into uncharted territory for that organization" in my opinion is only slightly wrong in that it starts with "many". Too many projects unnecessarily are made in to explorations for the sake of using technology in new ways. Where we need to innovate (and by that I mean business innovation - new products and services for the company; then yes, an agile approach is often / always(?) beneficial. But for other projects, why take the risk? Simple, known technology that works allows IT to focus on developing and IMPLEMENTING business logic in a risk averse way. Sure, things can change, but we can manage that. The need for constant reprioritization should be less if you are not innovating (as I define it above). Now reality may dictate that an enterprise does not want to do a lot of big up front planning, and wants to start building and realizing value soon. Great - do it the agile way. But too much change for non-innovation projects may just mean you were not properly prepared. Agile does not mean no up front planning.

Mike, you've described two end points on a continuum. Most software development projects need an approach somewhere in between. More importantly, most software development projects are actually part of something larger - a program, or a portfolio of capital investments. Failing to take those related activities into account is a far more common source of problems than simply accommodating changes to functional or technical requirements. I'd like to hear your thoughts on how we can accommodate these external influences in our project planning.

Thanks for your comment, you raise a good point, many projects don’t exhibit the “uncharted territory” so why use agile, and why risk a change to agile? This is true, a whole chunk of projects do not need the exploratory nature of agile methods and could be run just fine with traditional, plan driven processes. I have chosen not to work in that space, instead I work on custom application development for new and difficult to solve problems. I see many such projects a year and since I have been doing this now for 20 years, when I work on a more traditional project I still tend to use agile elements. I just prefer the increased collaboration, fast feedback cycles, smaller batch sizes, etc.

To me, using an agile approach is not adding new process or risk, but you raise a great point. Any change from the norm brings new risk. Adopting agile for the first time when your project does not need it is adding unnecessary risk of failure that needs to be carefully considered. Why are we introducing change? What improvements are we hoping to gain? How will we checkpoint and evaluate its effectiveness?

Hi Dave
Thanks for your comment and since you also bring up my seeming bipolar view of the world, I certainly accept I must have conveyed that. Yes, for ease of contrast I painted black and white views of the world when in fact we live with shades of grey. I think all projects are points on a spectrum and beyond the agile one I described are some like one I am working on right now that uses concurrent set based development and does A vs B sessions with the users. This is even more extreme but only the second time I have been asked to do it so I assume not that common.
Jim Highsmith talks about a “methodology per project” meaning since each project is different then so should its approach be. I like this recommendation and think process should be situationally specific. Anyway, you asked about integrating projects into a program and portfolio. Some great frameworks for this include the Scaled Agile Framework that describes how traditional and agile projects can be effectively managed together at a program and portfolio level. See http://bit.ly/IG1co6 the there is Disciplined Agile Delivery (DAD) that also does this along with providing a robust framework for hybrid approaches. I think both are useful references for creating frameworks for project execution.