Agile is about managing risk

It is not easy to explain what is agile or the need of agile practices in software development. Agile is not only about releasing early a valuable product even if it is the highest priority.

Anyway, a few days ago I found this tweet:

I showed the picture to my wife, and I tried to explain it to her. It was funny because she couldn’t understand what’s wrong with the first part of the picture and why the second one is the proper way to build software. She insisted that if you want to build a car, you should do the a wheel the proper way, then the other wheel, then the body and finally you deliver the car.

So why many people in the software development world are trying to deliver a skateboard, and then a bike, and then a scooter, and finally a car?

I think it is about managing risk.

It is not about following the coolest paradigm or techniques. But about identifying what usually goes wrong when developing software, and providing solutions.

Users complain that what they receive is not what they asked for, it is delivered late, and it costs too much. Software developers say users don’t know what they want, and they keep changing the vision throughout the project. As a result, many software projects end as a failure.

To avoid it, the typical solution is to increase the requirements analysis phase (not a straw-man, see previous link). You set in stone what the user wants and if the user changes his/her opinion (or he/she doesn’t understand what appears on the requirements document), bad for him/her. Then, the software is designed, properly built, tested and deployed. And finally (or at least later in the process) you put a wrap and show it to the user. I call it a waterfall mindset.

Traditional software development Traditional software development. Source: http://www.umsl.edu/~sauterv/analysis/random_analysis_thoughts.html

From a pure risk perspective that is a lot of uncertainty. We don’t know if that is what the user wants. We don’t know if we’ll deliver on time. Any change could have catastrophic consequences. Your product is not ready to look until very late in the process.

Agile is almost the opposite. It’s about delivering early, something that can be used right from the start, and slowly enhance it. It is about talking with the user throughout the process. It is about developing software WITH the user. Problems tend to appear early in the process, and you tackle them as they appear. Sometimes problems are the result of a growth without a blueprint, and you need to rebuild things you’ve already built. But that’s OK, because Agile is about facing risks.

I’ve been part of teams with daily stand-ups, with sprints, with code reviews, but with a waterfall mindset. Agile shouldn’t be a warm feeling of this is right, or cool. Agile should be a way to minimize risk.



First published here