The Self-Abuse of Sprint Commitment


When I was first exposed to agile software development seven years ago, executives told us the “what” of the change but very little about the “why.” For example, we logically assumed that the reason we were no longer allowed to sit in meetings (“Standup!”) was that our new vice president had some kind of irrational hatred of chairs.

Initially, we were excited by the platitudes: “No more releasing poor-quality products. We release every two weeks, and it’ll be like a bus on a schedule. If a feature is not of high enough quality to justify release, it doesn’t get on the bus. Only the scope that’s ready goes out on that bus.”

Even better, scope creep was to become a thing of the past. From now on the engineers would decide what they could do in a given time frame. This new system of team commitment would mean the death of crunch mode. Of course, our new VP informed us all that crunch mode was a “management failure” that he would not tolerate.

Imagine my surprise when I saw features still creeping into our new, smaller release cycles. Engineers were just as stressed. They weren’t working fewer hours—if anything, they were working more. Quality was now even more of a rubber-stamp exercise than it had ever been.

A zealous and passionate senior developer whose heart was full of undying love for the company and who had started there as an intern informed me that he had to work through the following weekend because he was way behind on his commitments. I asked him if he realized that he would be contributing to an intolerable management failure by doing so, and he gave me a puzzled look.

“But nobody’s making me work the weekend,” he said insistently.

I countered, “Then why are you doing it? Why don’t you just take up where you left off on Monday?”

“Because this is the last weekend before we ship sprint nine, and if I don’t work the weekend, I’ll never finish in time. Nobody’s making me do this. I made the commitment myself,” he said.

This only gave me more questions, so I asked, “Why did you commit to something that would require you to work over the weekend to deliver?”

He said, “At the time I didn’t know it was going to take this long.”

So I asked him, “If you made a commitment without the information you needed to accurately understand the scope of what you were committing to, is it reasonable for you to have to keep that commitment in light of the new information?”

He seemed to be getting annoyed and further elaborated on his feelings on the subject.

“But it’s my fault for not knowing what I was committing to, so I should be responsible for delivering that through any means I can. There’s no other way about it.”

I asked him, “What about the bus? Isn’t this kind of thing supposed to be mitigated by just removing your unfinished thing from the bus because it won’t be ready?”

He said, “But I committed to releasing this feature, and if I don’t get it on the bus, it’s my fault, nobody else’s.”

I asked, “Did you have the option not to commit?” I had lost him. We were back from coffee and he was far too busy punishing himself for a predictable failure of the system to continue the discussion.

Humans react in predictably irrational ways to the systems to which we subject them. I’d say from conversations I’ve had with some consultants that some of these self-blaming and self-shaming behaviors are perceived as a desirable consequence from this kind of iterative, commitment-based approach.

In my experience, collaboration and quality suffer when we pressure people to work themselves to death by forcing them to promise things they cannot yet understand.

What other options are there? There are useful, more humane ways to achieve predictability and reduce risk in project delivery.

Once we understand the nature of the system and can coherently express the intents of the delivery organization, we are in the best possible position to begin experimenting with more humanistic approaches to delivery.

If the organization is using an iterative approach with timeboxed sprints, it can reduce the probability of the problem described above by starting and ending iterations midweek. This can help, but it doesn’t guarantee that panic won’t still set in and lead to weekend work or long nights.

Reducing the batch size of increments of work to the smallest measurement that can deliver value to the customer and business creates more frequent logical breakpoints in the development process, which reduces urgency to complete features. If everything is small, we can deliver any time.

One technical way to achieve this end is to invest in continuous delivery systems. By eliminating timeboxes, we can ease the cognitive load and stress caused by deadlines. Of course, this can be accomplished without continuous delivery, but that’s a topic for another article.

Experimenting with humanistic approaches to optimizing the flow of value is a valuable and worthwhile endeavor. Emotional well-being is essential to the optimal performance of knowledge workers. Investing in systems-thinking approaches to improve the lives of our workers will pay dividends in improved quality, engagement, and creativity.

User Comments

crsuresh's picture

Adam, thanks for bringing up an important point.. in addition to sensitising the team as well as management, it is important that the scrum master here see if is this is becoming a sustained trend and counsel the team accordingly.. if is a one off thing it might be alright.. but not if it keeps persisting..

March 24, 2014 - 11:39am
Adam Yuret's picture

Thanks for your comment! 

So, my concern is that if the organization's system sends a different message, no scrummaster or manager's words or efforts to convince teams otherwise will overcome that system and culture. I've seen many a scrummaster try to encourage self-organization at the individual team-level when the organization still had annual performance reviews and other policies that create incentive to do as their told. While I think scrummasters can help, if the system disagrees with what the scrummaster is saying usually it will eject the scrummaster and the system will prevail. 

Thanks again for your comment. :-) 

March 25, 2014 - 12:10pm
Ed Kelly's picture

Excellent article Adam!  I've not seen anyone address this topic before.  As much as we try to know everything we can before the beginning of a sprint or a multi-sprint release, there are often surprises that occur when the code is examined deeper or when testing reveals unknown behavior.

April 1, 2014 - 11:31am
Leyton Collins's picture

When I read "saw features still creeping into our new, smaller release cycles" my response in that climate would have simply and directly been "Then you're not Agile. You're doing pretend Agile." Actually, in reality, I have said this. Of course people are going to be stressed, and collaboration and quality will suffer! 

I applaud (loudly) the senior developer in your article. Not enough people these days honor their commitments; whether they did so appropriately with full understanding or not. Too many people look for excuses not to honor them.  It's like dealing with children who cry "it's not my fault!" and in the same breath bemoan their lack of authorized accountability or autonomy. It's also one of the reasons for the person leading the project to actually lead and ensure the team understands what they are commiting to do, and then does an appropriate retrospective to help ensure they don't keep doing it. 

Eliminating timeboxes is like giving up on Agile like a golfer throwing their clubs in the lake after a bad round on the course, or choosing to go Lean. Nothing wrong with following a Lean approach if that's what will work best in that environment. In such cases following a Lean approach is better that trying to be Agile, faking it, and as you noted, pressuring "people to work themselves to death by forcing them to promise things they cannot yet understand". 

BTW ... it's not the fault of the golf clubs, it's the golfer's. Same thing with Agile.

April 4, 2014 - 12:42pm


About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.