When it comes to an agile model, failure is an option
It’s OK to fail when taking an agile approach to a business service or software development project, but if you fail, fail fast.
As one expert explained to me, if you don’t fail, you don’t really uncover the true nature of the problem trying to be resolved, or what works and doesn’t work.
“’Success is counted sweetest. By those who ne’er succeed,’ to quote Emily Dickinson,” said Ross Pettit, client principal at Chicago-based ThoughtWorks Inc. “You don’t want to be Wile E.Coyote, but you want to be in a situation in which you try and fail, because the more often you do that, the more you learn about the problem in front of you.”
He has seen too many agile projects fall apart because IT is afraid to fail. What ends up happening is failure on a larger scale; the project never crosses the finish line.
The iterative nature of the agile model allows for failures. Many agile projects are chunked out in weeks, so when something doesn’t work one week, you pick up the pieces, and apply what you learned to the next phase of the project.
Having project facilitators is critical to picking up the pieces quickly. This could be the CEO, the CIO, or a head of a department. Facilitators are the ones that the project team can turn to and say, “Here’s what we need access to, here’s the person we need to talk to, here’s the people we need to work on this problem.” “This allows stakeholders to make the resources available for what need to be done, immediately,” he said.
And if you are a stakeholder, don’t assume that you know what agile means. An agile model involves terms like velocity and iterations. A common word used by Pettit is story or an epic story to describe an agile project. All of these are common terms, but in the agile word they have a different meaning.
An epic story is the ultimate solution you want to achieve. So each release phase of the project tells part of the epic story, and is repeatedly compared with the theme of that story to make sure the project sticks to an agreed-upon plot.
“Just remember that very familiar terms are used in agile, so don’t understand them too quickly,” he said.
And don’t fall into the trap of viewing an agile model as one prescriptive approach that needs to be followed as if law. An agile approach is a living and breathing project that changes, otherwise it wouldn’t be called agile, points out Elena Mitelman, principal with agile consulting firm SmartEdge LLC.
She offers this other takeaway:
Using another process (waterfall, RUP, etc.) and calling it agile is a common mistake. It’s important to actually do it, rather than just slap a new name on an existing process.