You Are A Failure! Keep Up the Good Work…

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. fear-of-failure-768216

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.

  1. you learn how to actually predict the future, and only commit to work you KNOW you will deliver, or
  2. 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.


10 thoughts on “You Are A Failure! Keep Up the Good Work…

  1. I accidentally submitted my post too soon.

    How do you prevent or minimize people under delivering in other agile systems without a timebox? The team and/or peer pressure to hit a deadline I have seen really cause some teams to gel and deliver more than anyone expected. Is it that timeboxes just make a piece of human nature more visible?

  2. I would like to think after all this time I have achieved a nice but achievable challenge is what I feel comfortable committing to each sprint. If all that is being asked is were all stories completed then I guess I “fail” a lot of sprints but i think instead I consistently deliver 85%+ of the committed stories and that the work done on the remaining stories makes them more known for the next sprint.

  3. Pingback: Jason Montague
  4. Pingback: Jason Duff
  5. Pingback: Jason Montague
  6. Pingback: Carl Schrammel
  7. Good points. Ive asked myself in the past whether externally imposed pressure is necessary for high performing teams. I tend to think it is a positive thing early on as people learn the system and the processes….as well as learn one another. As time goes on though, the need for external deadlines becomes unnecessary at best, and harmful at worst. I found myself presuming people wouldn’t do their best if we didnt give them artificial pressure. I have been proven wrong over and over again on that point.

    I also think the unintended consequences of that artificial pressure ends up subverting people’s ability to leave the variable of quality untouched. By that i mean that, with external pressure to “just finish”, developers and teams tend to cut corners, however small, to ensure the stories are delivered.

    It boils down to the classic carrot and stick model. If you do well, carrot…if you don’t, the sprint is labeled FAILED (which acts like the stick in this metaphor). The problem is that the classic carrot and stick model tends to de-moralize work. Those are both extrinsic motivations. We want to teach teams and people how to find intrinsic motivation to do the best job they can for themselves and their teams.

    In my experience, teams that really understand how to work on limiting the work they have in flight and getting the system to “flow”, have a huge advantage because it starts to become an internal drive to do better without the need for peer pressure, carrots or sticks. And when a team has that feeling, they think of insanely interesting ways to make the work flow fast, with higher quality, and really have a desire directed at the real goal of delivering value and helping their team and customers. That can also happen in Scrum, but it tends to take a long time to get there, and is many times dependent on an incredibly adept scrummaster.

    A last note: One thing I’ve witnessed is how unlikely it is for scrum teams to change their commitments from sprint to sprint. Flow based teams have no boundaries (true) and they are free to fluctuate up or down as they learn. Over time, they tend to fluctuate up, way up, in terms of how much they are delivering. Scrum teams tend to set a threshold at, lets say, 6 user stories. They could have that target for years with no change.

  8. I have seen this mode also. I have also seen it overcome. Changing the concept of “committing to user stories in a sprint” to “forecasting” is a good start. This development stuff is hard and a bit unpredictable at times. The best we can do is forecast this sprint’s weather, so-to-speak. No harm in being off a few degrees.

  9. It seems to reduce down to if we don’t meet our sprint goals we need to call that a failure but failing is not bad. Why call it a failure then?

    I feel schedule pressure reduces velocity particularly when you take into account rework. The Japanese concept that high quality is cheaper (in the long run) can be re-purposed to a sustainable pace is faster than a sprint (that is why I like the term iteration). The book Peopleware addresses this (around page 25) and includes statistics showing that time pressure is not the road to productivity. Teams will put more effective time pressure on themselves than any external force.

    Better forecasts uses Iteration Goals and Stretch Goals to better communicate reality and a commitment. Kanbans and flow based approaches side-step the issue nicely by focusing on flow.

  10. Pingback: AXXUN Inc

Leave a Reply

Your email address will not be published.