A few short weeks ago at the PSQT conference, I had the fortune of sitting in on Tom Cagley‘s session, titled Impact of Risk Management on Software Quality. One of the components that Tom mentioned as part of the Agile Risk Taxonomy is Agile Organizational Risk or People Risk. He describes it as the “impact of an environment populated by people.” Some may think that this is the most nebulous risk, when compared to business or technical risk. I think it’s probably one of the most important but, unfortunately, it’s often swept under the rug.

Team of engineers discussing planning at meetingThis leads me to question what the secret sauce of any professional team is. Being together and playing for a long time together. Look at Michael Jordan. Look at Kobe Bryant. There were and are others that could be considered better players, and those “better or more talented” players may actually have better statistics. But in the long run, the best stats and the most championships come from these two. And of course you might say Jordan couldn’t have done it without Pippen and that Bryant needed Shaq. But that’s the whole point – they played together for a long time. At XBOSoft, I also believe in keeping the team and its core players together for a long time. That’s how we win software testing championships. :)

So what drives sustainability? What enables a team to stay together for a long time? For Agile, one of the key principles is a sustainable pace, but how do we get there?

Elements in Attaining Agile Sustainability

Planning: Most of the time, we forget stuff that needs to get done. That’s fine because the beauty of Agile is that you can try again one iteration later to get it right. So in your initial planning, do the best you can. Make sure you incorporate activities other than feature development itself, such as performance, security analysis, and work items to reduce technical debt. If you forget, document it and try again the next time.

Estimating: Measuring whether your actual and your planned match is a critical activity. It’s not whether or not you were accurate that is the most important, but why? And then, trying to improve with better estimates the next time based on what you learned.

Workload monitoring: The problem with planning and missing your plan, or deviating from plan is that most of the time it is one direction, over budget. Very rarely will you under-budget the time it takes to get something done. At all costs, avoid burnout and rushed situations because we all know what happens when we’re in a hurry. We make mistakes. Measure overtime and try to understand why the overtime occurred (unplanned work). Getting to the reasons why and attacking those will probably have the greatest impact on quality of any of your activities.

So when you think about Agile risk management, don’t overlook Agile organizational risk and, in particular, what can make your team and the software it’s developing sustainable. Moss Drake and I will be facilitating a full day workshop at #PNSQC16 on October 19 on managing risk in Agile projects which will cover this and much more. Hope to see you there.