Back in the days when everyone was doing big waterfall projects, both in software and other fields, we used to have an “Analyze”-phase. Today we do barley dare to call a project waterfall (because no one want to be associated with something so out-of-fashion as waterfall-projects).
Still we see the same behavior as we saw when doing the waterfall-analyze-phase. Today it sometimes gets covered as “pre study” or “breaking down the entire scope in great detail into the backlog so that we uncover all risks, can accurately estimate, set a release date and calculate the cost”. Sounds easy but in reality, many traditional project plans failed because of the believe that this could be done with accuracy if you just did it well enough.
It’s easy to understand why we continue to drive development like this in our businesses. As humans we do not like uncertainty. Certainty and predictability are much more comfortable. It doesn’t matter if the plan we create is made up of guesses and unreliable assumptions - As long as we feel that we are in control.
When software is built, we are always solving new problems. The domain is new, and the requirements differ. Ways of solving technical problems evolves with new frameworks, languages and other techniques to increase efficiency and enabling new more powerful features to be developed. That, in its nature, is making software development hard to predict to the detail required to create a predictable plan.
So, if planning can’t give us predictability; Why should we bother? Planning is crucial - But plans are not! The fact is that if your plan is not changing, you are probably not getting enough important feedback. A plan serves the purpose of giving alignment and understanding of the goals based on what is known today. A plan could include a forecast of what to release and when. But following the plan is not a goal or a measure of success. The measure of success is delivering value and meeting the users and stakeholders needs as well and soon as possible!
If we try to control uncertainties, we are not open-minded and welcoming of the changing needs of our users and stakeholders. We do not focus on what brings value to our users now. We do not focus on validating our assumptions. Instead we focus on deliver the things that we agreed on based on the knowledge we had then (which may be completely different from the need today. Or even worse; made up by false assumptions about the user needs). That will make us spend time and money on features that will never be used (aka. Waste). That will also make us miss new market opportunities! Market needs are changing quickly and frequently, and it is not predictable. If our world is changing quickly, why shouldn’t our plans?
If you have made the decision to leave waterfall behind and go with an agile approach - Dare to skip your analyze-phase! It wasn’t a good idea then, and it’s not a good idea now. Put your focus on validating your hypotheses as quickly and reliable as possible. Release frequently! Act on the insight that it brings! Don’t spend valuable time and money on something no one asks for. Done correctly that will be the best approach for both your business, customers and users.
Do you try to control and avoid uncertainty instead of embracing the discoveries and adapting to new possibilities? Do you focus on scope and feature delivery instead of learning about what brings most value for you users and other stakeholders? Hope you found this post interesting (and not too provocative).