Until I decide whether or not to start another blog specifically on Technical aspects, I’ll at least indicate in the Subject that they will be such. For today, the question is once again focused on Agile Development.
I recently had a conversation about how “risky” Agile is and how difficult/ impossible the person found it to properly understand what the “plan” is on delivering a project that way.
In my experience, I don’t believe Agile is any more or less risky than any other methodology. After all, in the end, what you’re trying to deliver is a product that your client (whoever it is) can use to make their daily work easier. Whether you spend all your time and effort “up front” trying to figure out exactly ‘how’ your system is going to work and interact with other systems and then try to build it, or whether you take the “build what you need” approach, there will be risks.
The beauty of Agile however is that once you’re done, you’ll (hopefully) have a product that the client loves and can use because it was built “together” as a team. Along the way, as parts and parcels were built and delivered, the Agile Team (ie; developers, product owners, end users, etc) all had buy-in AND a voice on what they want the system to do and behave. If I can make an artistic analogy, this allows a “rough picture” (ie; early Iterations) to slowly be “inked” or “erased” or otherwise get a tighter “line” as it advances. Agile gives you that flexibility to tweak what you’re working on to more accurately match the day-to-day realities your client has to deal with as well as tweak (or improve) how the work gets done.
With the Waterfall approaches I’ve seen/ been involved in, all the up-front analysis, documentation, interviewing, estimation, etc is all done by different people who are usually not involved in the actual coding and developing. Forget having a developer try to understand why they’re being asked to build something, they just do what they’re told. In the end, you may get a wonderful system, but if market situations had changed along the way, it’s just as possible to end up a system that does what it was designed to do, but does not do what it needs to do. And since not everyone works the same, if you build something for the benefit of one person but not the one who will actually use it in the end, chances are high that they won’t be very satisfied by everything either. (This is part of that wonderful discussion of “don’t tell me how to do my job or how it should be done!” 🙂 )
To get back to the “risks” remember that even though a project is Agile, it doesn’t mean it’s a free-for-all (if it is, I would strongly recommend you find yourself another partner). Agile is a methodology for development. Risks exist as possible events and being prepared for them allows you to (normally) mitigate the highest ones. An experienced Scrum Master will not ignore the idea of risks. They will or should hold a Risk Session with the Agile Team (especially including the Product Owners and Sponsors) to identify what those risks are and what can be done about them. Having them thus identified, the Sponsor and Owner will be the ones to prioritize when to tackle them. They become an active part of whichever Sprint they become assigned to.
Is Agile riskier? Only if you’re not following a proper procedure to identify and follow-up on them. As for the whole question of having a “plan” … I’ll adress that at a later time. Once I can stop laughing at the idea that Agile doesn’t really have a plan 🙂