The Self-Abuse of Sprint Commitment

[article]
Summary:

Adam Yuret explains what can go wrong when teams blindly commit themselves to sprints; collaboration and quality suffer when we pressure people to work themselves to death by forcing them to promise things they cannot yet understand. Investing in systems-thinking approaches to improve the lives of our workers will pay dividends in improved quality, engagement, and creativity.

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.

User Comments

14 comments
Mike Olliges's picture

I see this so much.  Thanks for sharing. 

March 20, 2014 - 1:40pm
Adam Yuret's picture

Thanks for the comment, Richard. :-) 

I am aware of the language change, but I have not yet encountered a scrum coach or implementation that understands how to do probabilistic forecasting or even dropped the use of the term "commitment" from their lexicon.

To the contrary I see resistance to the concept that commitment is not a desirable system. Quotes such as "Removing the word commitment from the scrum guide is the worst idea ever." and "In order to achieve predictability it is essentially to reduce velocity variance and form stable teams that make and meet commitments." 

Of course using relative estimation to guess at the complexity in large user stories doesn't help with understanding the nature of variation and how to forecast reliably. That's probably a longer article though than a comment-reply. :-) 

Needless to say, without an understanding of the differences between forecating and estimation, how cognitive bias and psychology impact our ability to accurately promise anything; the nomenclature just becomes lip-service. People will just say "Teams need to forecast accurately which means they make and meet their forecast." 

Thanks again for your comment.  

March 21, 2014 - 11:56am
Richard Hundhausen's picture

This is why I encourage teams to create a Sprint Goal. Where the team merely forecasts the PBIs it believes it can deliver this Sprint, it commits to the Sprint Goal. So, there is still commitment, but to the overarching goal of the Sprint, not to all of the selected PBIs.

If the Development Team delivers 3/4 of their forecast, they still met their goal (and delivered value in the form of working software). If stakeholders want to know why they missed their forecast, the answer is easy "What they do is hard, but we're improving.".

Sounds like the coaches and implementers you know need to take a dose of their own Kaizen guidance, and keep up with the times! :-)

March 21, 2014 - 3:34pm
Eric Jacobson's picture

Maybe I’m in a weird mood right now but I see things differently.

I admire the ambition to follow through on commitments.  The people I enjoy working with most are those that don’t mind putting in some extra time to do the fantastic.  When I do it myself, I feel great…proud and like I really accomplished something.  Why not bend over backwards thanking the dude that worked all weekend?

I know I know, I‘m missing the point.  I guess the point is that Sprints can be stressful b/c they might lock people into their commitments.  Personally, I’m a Kanban guy.  But I get Sprints…or maybe I don’t.  IMO, that’s the whole beauty of Sprints!  They deliver as planned.   If team members are stressed, they should commit less.  What’s so hard about that?  If they are ambitious, they should commit more.  You adjust each Sprint.  Eventually, your Velocity flattens out.  The commitment is completely within the control of the project teammates, right?

 

BTW - I think I was on a panel with you, Adam, in a TWIST podcast with Matt Heusser.  Good to see your article and thanks for making me think a bit.  Cheers!

March 21, 2014 - 4:52pm
Adam Yuret's picture

Hey Eric,

Thanks for the comment...

I think much of this dysfunction comes from systems that ascribe too much intent onto the actor.

I think people want to follow through and be good at their jobs. I don't think this is a unique attribute.

The dude that worked the weekend likely was not as effective in his knowledge work and definitely was not modeling a sustainable pace. Furthermore he was neglecting his family to be there over the weekend. There's also a tacit implication that effort = value and they're orthogonal in my experience. For more on Resource Efficiency Vs. Flow Efficiency and Slack see: http://youtu.be/V1TON3FAIvU Deck here: http://www.slideshare.net/AdamYuret/productivity-is-killing-us

As far as making & meeting commitments is concerned I would recommend reading Jim Benson's short eBook on Cognitive Bias "Why Plans Fail"<http://www.amazon.com/Why-Plans-Fail-Cooperandi-Mememachine-ebook/dp/B00... The Planning Fallacy alone makes us incapable of making realistic estimates for how long complex work will take especially since we're incapable of imagining all the things that will go wrong.

I assure you the corporate culture at this organization didn't adjust it's velocity commitment because that guy had to work the weekend to make it.

Unfortunately, too often effort is considered the metric for success. "Good People" want to work harder and longer while "Bad People" want to slack off and not work as hard. The resource management paradigm this enforces creates executives that optimize for effort instead of the flow of value.

"If the team is stressed, they should commit less."

Is a fantastic idea that is rarely supported by the Theory X management systems. I've never met anybody who thought they should err on the side of less when asked by management to commit or who viewed the team's commitment to the business as elective. Even if they did, the odds they'd build in slack or estimate their capacity correctly are pretty low.

Accepting that people are doing their best and focusing on improving the system to achieve predictability seems like a more humanistic solution to me.

Thanks again for the comment, I could go on and on and I feel like I already have ;-) . A future article of mine pending is about "depersonalizing work" which dovetails into this conversation.

I remember that TWIST podcast, it was fun. I hope you're well and please don't be a stranger. :-)

March 21, 2014 - 7:56pm
Tom Looy's picture

Adam - thanks for your thoughts on an important subject.

Here's how I choose to look at the Sprint commitmen: it's not a commitment to management but rather a commitment within the team to each other.  

I see the Sprint commitment as a way to address Lencioni's Five Dysfunctions of a Team and to build trust within the team. (For those who haven't read Lencioni's book, the Five Dysfunctions are: Inattention to Details, Avoidence of Accountability, Lack of Commitment, Fear of Conflict, Absence of Trust.) 

March 21, 2014 - 6:30pm
Adam Yuret's picture

Thanks for the comment Tom, 

I have not read 5 dysfunctions and I'm not sure that I'm keen to do so now. Those "team dysfunctions" read a lot like "ways to blame people for the failure of the system." to me. I feel like I've been inspired to write a post about that alone. :-) 

I can think of ways in which each of those team level "dysfunctions" come from the way systems are designedand how trying to control people out of those dysfunctions could potentially be perilous. 

All of that said, I am not sure how a sprint commitment builds trust, encourages healthy conflict, or increases detail attentiveness. I don't think I've ever seen management that didn't pay attention to velocity and it's variance or teams of people who felt like failure to deliver on their commitment was not something bad or about which they should be ashamed. If we replace sprint commitment with smaller batches of more standard work and a forecast based on probablistic data-driven outcomes, we may create more humanism and agency. Both of which will likely help take a systems approach to solving for those "team dysfunctions" 

Thanks again for the comment, Tom. Don't be a stranger, if you're still in my city we should grab lunch sometime soon. :- )

March 21, 2014 - 8:04pm
Bryan Gebhardt's picture

Don't count "Five Dysfunctions" out yet.  I've found it a simple and effective framework for thinking about how to improve teams. The dysfunctions are the things you see in your team and I've seen it as my job to help build the opposite in my teams through a variety of means.

They also build on each other.  For example commitment doesn't build trust.  It's the opposite.  Trust builds the ability to commit to a decision, path, etc.  You need your team to trust each other to have effective commitment, say, to the decisions the team is making.

A little more about each one:

Absence of Trust: Trust is the foundation of real teamwork. However, in most teams members will not be "vulnerable" with each other (air dirty laundry, admit mistakes, weaknesses and concerns without fear of reprisal). Without trust the team will not be able to achieve results.

Fear of Conflict: Teams that lack trust are incapable of engaging in unfiltered and passionate debate about ideas. Instead, they resort to veiled discussions and guarded comments.

Lack of Commitment: Without having aired their opinions in the course of passionate and open debate, team members rarely, if ever, buy in and commit to decisions.

Avoidance of Accountability: Without commitment and buy-in to a clear plan of action, even the most focused and driven people often hesitate to call their peers on actions and behaviors that seem counterproductive to the good of the team.

 

Inattention to Results: Failure to hold one another accountable creates an environment where team members put their individual needs or even the needs of their division above the collective goals of the team.

April 1, 2014 - 1:23pm

Pages

About the author

Adam Yuret's picture Adam Yuret

Adam Yuret provides lean and agile consulting services to organizations ranging from enterprise fortune 10 corporations to small non-profits and health care providers seeking help in adapting to the new post-agile paradigm of short learning cycles and continuous delivery pipelines as Principal Consultant at Context Driven Agility (CDA) Consulting. Adam is a "celebrated international speaker" (he presented in Canada and some people actually clapped!) who's been featured twice on InfoQ and invited to speak at numerous conferences, including San Francisco Agile 2012, Conference for the Association of Software Testing 2010, Software Development & Evolution Conference 2012 and many local events in the Seattle Area.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09