I love the word “failure”. I love it! Why? Because it lets me know that teams are trying to get better! People are human, and everyone will fail (with some regularity in complex situations – I might add). To me, an awareness of failure, and open dialogue about failure is crucial for teams to begin to take ownership of committments, and their own evolution. But there’s a problem. 
In my experience with some agile frameworks, failure is a nasty little concept. It doesn’t have to be, but sadly it tends to turn out that way.
The story goes like this:
Someone (me in a few regretful cases) enters and organization and creates a buzz around new concepts like Scrum and XP. We form teams and have lots of earlier struggles and, conversely, lots of early wins. During the process, the concept of time boxed iterations (sprints) is taught and internalized. Sprint planning commences and sprint goals are agreed to.
Thoughtful leaders keep these goals from becoming a list of user stories to be delivered. They design goals to be (struggling for a word here)… “thematic” (meaning, the goal is something a team and a business can sink their teeth into and is the living embodiment of the features, stories, and tasks that make it up the Sprint).
Fast forward to the retrospective:
The retrospective kicks off and Sprint Goals are discussed. Inevitably someone says, “we sort of delivered the goal, but we aren’t DONE. We missed 2 user stories. We committed to 10, and we only got 8 of them done. How can that be a success!?”
This is typically followed by a giant sucking sound that, over time, turns out to be the souls of the people that worked tirelessly to get 8 pitiful stories completed. (the sounds of them leaving their owners)
The game is now afoot:
What is a typical Pavlovian response to this kind of interaction? If I rap your knuckles and called you a failure because you can’t plan in 2 week increments, you have 2 reasonable “protective” responses.
- you learn how to actually predict the future, and only commit to work you KNOW you will deliver, or
- you sandbag in an attempt to ensure success and your own self preservation.
In my experience, working with brilliant, thoughtful, honest (albeit human) teams, the typical response is #2…. They commit to 6 stories, “success” is restored, and the balance in the force is regained.
What just happened?
My guess is that most teams, as they mature, could begin to deliver huge volumes of value…more than they ever thought possible in the beginning. Unfortunately, when teams link story count and timelines to failure, those outer boundaries are unachievable. Sadly, we have just created a team that will rarely, if ever, commit to more than 6 stories. Mostly it’s because of an incredibly myopic view and definition of “failure”.
Teams internalize failure as “not delivering the requisite number of stories on time”, no matter how hard you try and convince them otherwise. In fact, I have NEVER met a Scrum team that defines failure as anything other than not delivering enough on a predetermined timeline. That’s it. That’s all I hear. Ever…. Ever-ever. Really.
That’s not to say that teams don’t fail for many other reasons, but those really AWESOME failures (the ones we need to discuss and learn from) are rarely talked about, and (as I said two sentences ago) are never internalized as the actual “failure”.
To me, the interesting things that happen are when we try new techniques and they don’t work out, we implement strategies that need a little tweaking, we build a product that no one will buy, etc, etc. Those are awesome and can teach us a lot, and need attention. Time-boxed approaches make discussing these types of failures difficult because most are focused solely on the stop watch.
In Conclusion:
The fact that you cannot tell the future as a team is not revolutionary, interesting OR relevant, so let’s adopt an approach that doesn’t tie “professional guessing” (even in small time boxes) to our shared definition of success. For good measure, I would love to hear some of your examples of sprint failure, or your opinions on the topic! For extra credit, discuss how lean thinking and flow-based models help alleviate some of the problems caused by time-boxed approaches.