Agile Axiom #4 – To be successful with Agile, failure is more than an option, its necessary.

April 8, 2008

I am sure most of you have heard the movie quote “Failure is not an option”. You may have even used it as a motivational technique. With Agile development, I would suggest this statement be modified. It works best like this “Failure from time to time is expected – trying, assessing, and adjusting are not optional“.

Most Agile methodologies call for some type of ongoing assessment of the development process. The assessment is intended to produce explicit process changes that are applied to the next iteration or release. Many Agile teams struggle with this in the beginning – particularly when their roots lie in a traditional waterfall management structure. However, it is one of the most important concepts with “Agile”. It is critical that teams be allowed to fail in the process, bring creative ideas to address problems, and determine how improvements are made. There are two primary reasons for this.

  • The individuals actually working the process are likely to have the best sense of where the problems are and how to address them.
  • People who have influence over how they work are typically more satisfied than those who have a process forced upon them and will demonstrate more passion. This results in an improvement in quality and productivity.

On one of my first Agile projects, the team was struggling with the acceptance rate of their stories at the end of each iteration. For us traditional managers this was of significant concern. It seemed that no matter what we told the team to do, things would not get better. The management team tried measuring the work completed and determine where things were breaking down. This resulted in great debate over the metrics – thats about it.

We even would drive the retrospectives from the management level. If you want to call them retrospectives – these meetings were more like managers listing out what the scrum teams needed to change. Somewhere along the way, we shifted our thinking (with a little influence from Agile thought leaders) to a mindset that allowed us to emphasize the importance of completing and accepting the stories to the teams and then empower them to make adjustments. As managers, we needed to back off and let the teams work the Agile process. The only management directive was that the retrospectives will occur.

Slowly the teams started to increase their story acceptance rate. Each iteration they would make small adjustments to the process. Some would change their iteration plan to accurately reflect the velocity they were able to contribute. Some improved their testing processes to have the Quality Assurance engineer working side by side with developers. The average acceptance rate improved by over 25%.

The challenge with empowering teams to this level is to find the right amount of influence each independent team has on their processes. For example, if there are five teams contributing to a major release of a single product, it would not make sense to allow each team to define its own iteration length. Its important that managers develop a “feel” for how much to control. Managers will likely find themselves in a similar try, assess, and adjust cycle for the how much control they exert over the teams.

My belief is most managers error on the “heavy management” side in the beginning. It is not until they truly understand what is meant by “People over Process” that they begin to see productivity gains on a large level.