Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Sprint Events Are Not a Waste (Unless They're Done Wrong)!

DZone's Guide to

Sprint Events Are Not a Waste (Unless They're Done Wrong)!

One Scrum guru explains why if your Scrum team feels Scrum events aren't a good use of time, they're probably doing them wrong.

· Agile Zone ·
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

I have read in several Lean and DevOps sources that the Sprint events imply a kind of waste, so teams are supposed to move to a Continuous Delivery or Kanban lifecycle as they become mature. This post is to discuss why that is simply not true, regardless of what lifecycle each team chooses as their favorite.

Scrum Theory Roots the Sprint Design

As you can read in the Scrum Guide and in many posts on the Scrum.org blog, Scrum is based on the empirical process control theory, or empiricism. Complex problems are better solved by self-managing and self-sufficient teams in short feedback loop iterations, where those teams can inspect and adapt whatever needed as they discover information about the problem being solved.

Events should not be judged just by estimating their efficiency in terms of how many team member's time they take. Their outcome is much more than that.

Sprints and their events are not just "meetings to plan and track work," but opportunities to share points of view, to remove erroneous assumptions (and hence wasteful work later) and to come up with the best possible decisions (because they are rooted in the collective intelligence and not the individual's capacity).

The House of Scrum by Gunther Verheyen.

Besides decision optimization, Sprint events also contribute to the growth of the team via co-learning and the development of a true team consciousness and sound relationships among its members. The Aristotle Project by Google showed that a team where decision-making and communication are balanced works better than other, more talented, but less participative, teams.

Focusing on individual team member performance or backlog items throughput (e.g. velocity) may be counterproductive. A good team's outcome is more than the sum of the outcomes of their members. The product's outcome is more than its output (e.g. lines of code, number of resolved tickets).

Waste According to Lean

In Lean thinking, waste means unneeded work which adds nothing to the value of the product. Tom and Mary Poppendieck identified these seven sources of waste in their book Implementing Lean Software Development.

  1. Inventory: Unfinished goods (also called "work in progress," or WIP).
  2. Overproduction: Producing more than the demand requires.
  3. Extra processing: Additional steps in the process that aren't really needed.
  4. Transportation: Shipping the goods from one place to the other.
  5. Waiting: Lag between process steps.
  6. Motion: Moving around within the process.
  7. Defects: Flaws in the deliverables that impact their features/functionality.

Let's use these sources as a definition of waste and find out how Sprint events can become wasteful.

How Can Events Produce Waste?

If a team does not correctly understand Scrum or fails to take advantage of the continuous improvement provided by retrospectives, events could become sources of waste. Some examples according to Poppendieck's sources of waste, underlining possible flawed events, are:

  1. Inventory: Teams do not sufficiently track the Work In Progress during the Daily Scrum and end the Sprint with "undone" work.
  2. Overproduction: The Development Team and Product Owner fail to forge a good Sprint Goal during the Sprint Planning and to understand together what the priorities for the Sprint.
  3. Extra processing: Teams fail to use Retrospectives to identify unneeded steps or steps that could be automated.
  4. Transportation: Teams may not be self-sufficient and PBI may have dependencies from external sources. This may not be identified or tackled enough during Retrospectives.
  5. Waiting: Teams use the Daily Scrum as their only Synchronization mechanism and hence, they wait for them to make decisions. Also, an item's dependencies may not be identified prior to the Sprint during refinement, or during Sprint Planning, so items could be blocked within the Sprint.
  6. Motion: During Sprint Planning, team members may not sufficiently understand the team's plan to achieve the Sprint Goal and Backlog, and later they may fail as well to optimize the Sprint activities during the Daily Scrum.
  7. Defects: Teams do not use the Definition of Done to identify items that are not ready to be released into the Sprint's increment, and that may not be identified during the Sprint Review and fixed within the Sprint Retrospective.

Agile, It's Not All About Speed, But, Rather, Value

The goal of this post was not to compare in detail neither Scrum and Lean nor Scrum and Kanban. It was also not to say which is better. The goal was to remove the mistaken idea that Sprint events are wasteful and getting rid of them will increase team productivity.

The term agility too often is confused with speed. In my opinion, the ultimate goal of Agile is not to produce more (output) but to produce more (outcome).

Learn more about the myths about Scrum and DevOps. Download the whitepaper now brought to you in partnership with Scrum.org.

Topics:
scrum ,agile ,sprints ,scrum team

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}