3 REASONS TO SPRINT

Several teams I’ve worked with wonder why it is important to finish work within the Sprint timebox. “This is an artificial container for my work,” they explain. “Why can’t our work just take the time it takes? Why must it be get all the way done in one Sprint?” In my experience, these frustrated teams are likely looking to move away from poorly implemented Scrum toward what will be disastrously implemented Kanban and just-in-time work processing.

Sprints offer three things that just-in-time work processing does not.

Focus

Software development teams that process work in a just-in-time manner often find a lack of focus. The Sprint container is a way to provide enough room for the creative work software developers do. In other words, time must be provided for developers to focus instead of worrying about the next piece of work they must pull in order to decrease cycle times.

Slack

Slack time is a fundamental ingredient to innovation. Healthy Scrum teams make slack time by pulling a little less work than there is capacity for work to be done. When developers are working ticket to ticket in a continuous flow model, slack is considered waste and teams will strive to eliminate it, bringing innovation to a grinding halt.

With little slack time to grow the capabilities of the team through automation or introducing new practices, the team can stagnate and fail to improve over time.

Prescribed Inspection and Adaptation

When teams stop observing Sprint boundaries for the work they do, they often soon begin to drop the ceremonies of Scrum that made them successful in the first place: Sprint Planning, Sprint Review, and Sprint Retrospectives. Each of these events inspects something and adapts something and when we stop doing them, improvements we’ve made in the past begin to fade away.

These events from Scrum are the backbone of team improvement and ongoing excellence. Losing them will immediately begin chipping away at the improvements they introduced.

Wrapping Up

There are other ways in which Sprints help teams, but these are my top three. If you are tempted to eschew Sprints for just-in-time ticket processing, don’t forget the ingredients of innovation that you risk leaving behind: focus, slack, inspection, and adaptation.

Published by

David Starr

David Starr is Director of Technical Learning at GoDaddy. He is a professional software craftsman committed to improving agility, collaboration, and technical excellence in software development teams. He is the founder of Elegant Code Solutions, has served in numerous leadership contexts, and was as an early and consistent advocate for agile software development. He has successfully led product development initiatives and organizational transitions in numerous positions including Chief Software Craftsman at Scrum.org, Sr. Program Manager for Visual Studio and Team Foundation Server at Microsoft, Chief Software Architect, Director of Product Development, Pluralsight Author, independent consultant, and trainer. David’s professional focus is on all aspects of developing, delivering, and operating software systems. With specific attention on the end-to-end process, methods, and practices of high performing development teams, his skills transcend specific technology stacks, although he has has a specific skills focusing on the Microsoft stack. He speaks at various international conferences, is a frequent guest on various podcasts, author of articles throughout the technology industry, and the founder of Elegant Code Solutions. He is a 5 time Microsoft MVP in Visual Studio ALM.

2 thoughts on “3 REASONS TO SPRINT”

  1. Slack is probably the most important. Hard for management to understand, but it makes an immense difference in the long run.

Comments are closed.