The Self-Abuse of Sprint Commitment

[article]

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

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

Nov 09
Nov 09
Apr 13
May 03