Failure
This word is always seen only in it’s negative form. For example:
Lack of success:
“an economic policy that is doomed to failure”
(http://www.oxforddictionaries.com/definition/english/failure)
In the world of Agile it can actually be a good thing. In some ways you can even say that in Agile you strive to fail as early as possible so that you know you are going down the wrong path. On the other hand if you don’t fail then you are more than likely on the right path. What is the right path and what is not is not part of what I want to touch on here, rather I would like to talk about how failure is treated. When dealing with the unknown, Agile offers ‘failure’ as a guidance tool to make sure that you are not going down the wrong path. It works best if the failure occurs as soon as possible. The idea behind Agile is to arrive at your end goal by way of small increments. This indicates that you are prepared to fail, but when you do, you want to do so quickly. Failing quickly is a lot less costly both in terms of time and money. Failure can occur at any level be it as the sprint level, developer level, or worse still at the vision level.
Failure in a Waterfall approach
Failure in Waterfall is bad. It means that all the work that has gone into planning and execution was for nothing as the final output is not what it should have been. Recovery from failure is seen as either an expense, a delay or in most cases both. This usually has a negative impact on morale and promotes negative energy within the team. While applying agile, everyone involved will fail as a team at some point, but because failures are encouraged to happen as soon as possible they can be analysed and a new direction can be organised accordingly.
Applying this way of thinking comes easily to someone that has Agile experience, but for someone coming out of a non-Agile environment it can be difficult to make the mental switch. It all begins with management. The earlier senior management team members understand that failure is a way of life in Agile the sooner an Agile implementation will work for the subordinates. This is not to say that all sprints should fail, nor should all stories, but there will be some of each that will fail.
The reasons can be numerous. The definition of failure can be adjusted over time to tighten a teams performance. For example, a team has been knocking off 40 story points per sprint for a good number of sprints and the members want to try to complete 45 points. If they fail they will know that their velocity is not quite there to handle an extra 5 points of work. Perhaps they can attempt 42. If they hit the target and are able to maintain it for a few sprints it proves that their single sprint failure due to lack of velocity, has indeed helped to increase just that. Another example would be of a team trying to do the infamous tech stack upgrade, which has been neglected for a few years. The team could say that in the initial sprint they will spend 2 story points worth of work to start the upgrade and see how many problems come up. This failure to actually upgrade the tech-stack results in more stories which are more detailed. Although, some could argue that this approach to a tech-stack upgrade is a sprint implementation detail, but at some point management would get a whiff of the fact that the tech-stack was not upgraded in the given sprint either by way of a discussion during the sprint review, planning or a Scrum-of-Scrums. This is the daunting part for the team especially if senior management don’t understand that the failure actually resulted in more precise tasks.
Another example that comes to mind is when a team tries to use a new piece of technology that no one has a lot of experience with, but the team members have heard that using this technology solves a number of problems. Given enough time the team will build up knowledge and experience with the technology, but if the team is asked to estimate some work based on this technology before their knowledge is good enough that will mos likely lead to a failure. Based on the failure the team will learn that their knowledge is not at a level high enough to provide reliable estimates. Perhaps the failure will demonstrate to the team that the new technology is in fact not the right choice. Either way, the failure has to be seen positively and a slight adjustment to the project plan could be made (eg hire an expert, do some training, drop that technology altogether, workshops etc).
So far I’ve only outlined technical situations which might lead to failures. So how about something non-technical. A PO is instructed by the stakeholders that a new feature is needed. This feature has been identified in market research as a way of jumping ahead of a competitor in a particular area. The PO starts drafting Epics and holds preliminary chats with some design people. The work progresses to a point where a team is actively working on the feature, however having spent a quarter of the estimated time the competitor releases the same identical feature on their product. This is a failure, but to what extent? Was the development team to slow to work? Did they over estimate? Was the design too slow? Perhaps. Any answer to these questions does not discredit the fact that the competitor is already selling their feature. All that has happened is that the value of the new feature has just dropped, potentially, significantly. So what does the team do next? What about the PO? Well, if there are more features, with a higher potential value then the team might as well park the now devalued feature and move onto something that promises to bring more value. Or maybe the team should finish the feature to save some value out of it and remain on a level field with the competitor. Essentially, what happened was non other than a failure, but again, there are positives to be taken out of it such as the need to keep a closer eye on which direction the competitor might be heading or what the team should focus on next from a value point of view.
Given either example it is clear that failure becomes part of every team members contribution all the way from an associate developer all the way through to a SVP. The impact of a failure by a person in a partial position might have varying impact on those around them, but at the end of the day a failure should be seen as a learning curve. And, there is nothing negative about learning, or is there?