The Self-Abuse of Sprint Commitment


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.