Yola & Co. used to do this in the past…

Once in a while I encounter senior engineers, architects, designers, etc. who started their carreer before the 90s, telling me Agile is what they did in the past. Before they practiced Prince2, RUP, ITIL, CMMi and the waterfall approach. But were they really?

If they know how Agile is really working, why are they still asking for time to do a full analysis? Why do they lock themselves up for several weeks or months before they come up with a detailed plan for the development teams? Or even worse, why do they still require fixed time, fixed scope, fixed price deliveries from their contractors? Occationally I see this happen in even the most Agile environments I’ve been working in. What is it with us that makes us tumble in this pitfall?

The weird behavior I see is, when things starts to become complex, we seek security and certainty by planning into detail. Especially companies that are transforming their way of working to Agile tend to display this behavoir. This is in contradiction to what Dave Snowden explaines in his Cynefin Framework:

Complex, in which the relationship between cause and effect can only be perceived in retrospect, but not in advance, the approach is to Probe – Sense – Respond and we can sense emergent practice.

I’m not telling you to dive in head first without thinking as soon as you encounter a complex problem but neighter will I tell you to sit back and think it over for the upcoming months. Of course we can perform a small analysis for the foreseeable part of the work ahead. This is most viable for the Product Owners. But after some analysis we have to build at least something so we can do inspect and adapt in retrospect. This will mitigate risk, espacially knowledge risk, and create insights on how to proceed for the next steps. This again is viable for the Product Owner but also for the development team that will be more capable in making a realistic estimation for the work ahead. And that by itself will mitigate time risk by becoming predictable.

Beside knowledge risk, technical risk will also be mitigated by releasing the first minimal viable product (MVP) into the production environment as soon as possible. I’m talking here about minimal viable and not minimal marketable. Viable might be viable for developers, architects, etc. and not necessarily for the end users. It will proof if the chosen solution and architecture is working and one can adapt early in the process of developing the product.

So next time a complex problem is encoutered, please stay out of your ivory tower, or cubical for that matter, and try to do it Agile if you chose the Agile way of working…and be surprised, it’s not the same as what was done in the past.