By Philip Lew
With all the wild weather and traffic issues in Atlanta lately, I am really pleased my presentation at the Atlanta Quality Assurance Association — AQAA — last week on “Managing Agile Software Projects Under Uncertainty” went so smoothly. Managing agile risk is a rather broad topic that is actually a full workshop I compressed into 75 minutes. I really work hard to get the crowd engaged and ready to participate because I truly believe in Edgar Dale’s Cone of Learning.
In the beginning of the talk, we covered the reasons for agile project failure and took a vote as to why people thought or had the experience of failure in agile. The results were quite interesting:
What I find most interesting is that Lack of Test Automation was the last reason that people cited as a cause of agile failure. So while everyone is touting automation as the cure for the test crunch at the end of agile development iterations, the problems are much less technically rooted.
Let’s talk about the top 3 from the vote.
Managing Agile Risk: Top 3 Reasons for Agile Failure
This was the number 1 reason for agile failure? Why? Truthfully because many people don’t have full commitment to agile which is partly related to the third reason, AgileFall.
So, while not being committed, teams may not follow the process that fully takes advantage of agile. They also may delete parts of the agile process that they ‘don’t like’ or don’t think are suited to their organization therefore crippling their process.
An example of this may be that there are no testers involved in working on requirements or the customer is not actively involved, or the end user is not understood/involved. Involving the customer on a regular basis, while it may be painful, is a critical part of agile.
Agile Doing – Not Being
This is one of my favorites. When I explained what it was, it seemed that everyone nodded their heads. This is where people go through the agile process, for example holding daily stand up meetings, but are just not into it. They may show up but their minds are elsewhere.
Instead of collaborating and communicating, they still do their own thing, and just say everything is ‘normal’. Instead of really learning and opening up to share ideas for improvement, they don’t even show up for retrospectives.
This is where a team converting from Waterfall to Agile and they either implement part of each or they implement mini-waterfalls. This can also be called ScrummerFall. What you end up with instead of Agile, is FrAgile.
This is a process that is random and doesn’t work. This is where teams claim that Agile means no documentation and operate in chaos.
The fact is you do need documentation, but just less and only if necessary. It is possible to blend processes but only if well thought out. Most of the time, AgileFall is not.
Agile Risk Management Techniques
For managing agile risk, two of the key techniques we discussed in the class were:
Preventing low probability failure events
“Black Swan” events as Nassim Taleb would say are events that are very unprobable, but can kill you. So even if they have a small probability you need to acknowledge them and prevent or mitigate. Events in this category include key team members quitting or a security intrusion.
Circumventing Optimism through a Pre-mortem
We all have a tendency toward optimism. As illustrated in Daniel Kahneman’s book, Thinking Fast and Slow, we all have this natural cognitive bias. That’s why there are so many entrepreneurs that fail.
Ignoring that 85% of businesses fail in 18 months, they think that through their hard work, intelligence and decision making will lead to success. Ignoring factors outside their control, our economy depends on them!
However, when applied to software development what this means is that our estimates are almost always wrong, and usually in the optimistic direction. Or, we ignore risk because ‘it could never happen to me”. Our society also rewards optimism and has a stigma towards pessimists. Who wants to hang out with people who are all gloom and doom? To give “permission” for pessimism, we did an exercise called a Pre-mortem where we simulated a situation where at the the end of the project, the project was a total failure. In this exercise, team members discuss why they failed. This sounds silly, but if you go through the exercise, you’ll be able to draw on your team’s experience to identify potential risks that could lead to failure.
Being agile about Agile
In the beginning of the talk and at the end, I emphasized the difference between agile and Agile. We seem to forget that Agile, the development methodology, started off as agile, the adjective. In implementing Agile, you need to be agile, flexible and ready to fail. Being ready to fail, learn, and get up again should be part of the Agile Manifesto. It’s implied but perhaps that’s not good enough.
See you in June?
We ran over time, at AQAA, but it seems people learned a lot and no one left early. For me, AQAA was an engaging crowd with almost record attendance! That’s good considering it was at the end of the workday and I’m sure they had other things on their minds.
This talk is a pared-down version of a one-day workshop titled Agile Risk Management. Managing agile risk is something that my friend Moss Drake — who I met at PNSQC — and I have had umpteen discussions. This will culminate in our joint workshop on June 5 at Better Software West in Las Vegas. See you in Vegas!