Some people say that We Spend Too Much Time in Meetings. Scrum recommends that we spend no more than about 15% of our time in meetings and the rest should be spent building working software. That’s a pretty good ratio. Still we may get the feeling that sprint events are a waste of time, and indeed this may be the case - IF WE’RE DOING THEM WRONG. Here’s why.

What is waste?

That is an interesting question. We all know what if feels like when our time is being wasted but it is a bit more difficult to quantify that feeling into a number that we can measure and then improve on. Many people have studied efficiency in systems and have done that work for us. Take for instance, the discipline of Lean Manufacturing. Closely related to Six Sigma, Lean defines 7 (sometime 8) Muda or wastes that a system may have. What are they?

“Muda, Mura, Muri”

7 wastes of Lean

• Transport
• Inventory
• Motion
• Waiting
• Over-Processing
• Overproduction
• Defects

These were originally envisioned in the context of manufacturing, but we also see parallels in software production.

• Transportation: Shipping the goods from one place to the other, or handoffs from one person/team to another
• Inventory: Unfinished goods - also called as “work in progress,” or WIP
• Motion: Moving around within the process - context switching on multiple projects, non-co-location, non-integrated toolsets
• Waiting: Lag between process steps - QA is waiting for development, developers are waiting for information from a vendor
• Extra processing: Additional steps in the process that aren’t really needed - overly complex branching structures
• Overproduction: Producing more than the demand requires or building features that go far beyond customer need
• Defects: Flaws in the deliverables that impact their features/functionality

The Wrong Way

Scrum Events done wrong will result in waste and will feel like a waste of time

Waste in Scrum Events

Let’s narrow this down a bit. Do we see the possibilities of waste within the Events described in Scrum? This is certainly possible and almost guaranteed if the Scrum Events are not conducted properly. Note some of these examples:

• Transportation: May happen when the product being developed cannot completed by the single team. Code may have to be “moved” to other teams or may have dependencies on outside vendors or process partners. Processes may even require that documents/code/deliverables be “handed off” within a team or between teams. The Scrum Event where these inefficiencies should be identified and addressed is the Retrospective. A poor Retrospective will fail to capture transport wastes, or fail to deal with them appropriately. “The same old things always come up in our Retrospective and nothing ever changes. Why should I bother going?”

• Inventory: The Scrum Event where we track work in progress (WIP) is the Daily Scrum. A bad Daily Scrum will not show the team their progress through the Sprint Backlog, they may not be aware of the Sprint Goal or know how much work is remaining. Without a Big Visible Board and a Burndown Chart, the Daily Scrum often degenerates into a status update.

• Motion: Work moving through the system will be made visible in the Daily Scrum. Kanban boards with huge numbers of columns are a clear sign of too much motion. There is too much motion when the team has to move to a different room for the Daily Scrum, when tools are not available, when rooms change. The Retrospective should be used to identify and reduce the motion waste. (see #1)

• Waiting: In a poor Daily Scrum, the team will not be able to coordinate their work. There may be hidden and unresolved impediments. Team members will likely spend a fair amount of time waiting for each other and/or for external dependencies.

• Extra Processing: The Retrospective is the time to examine the process and look for improvements. If this is not done, there will be waste!

• Overproduction: If the Sprint Planning meeting is not well executed then the Product Owner and team will not synchronize their understanding. They may fail to agree on a Sprint Goal and the team will likely not build the “right thing at the right time”. A bad Backlog Refinement meeting will fail to prepare the team for up coming work.

• Defects: Bugs in the software will inevitably surface if the team has not met their Definition of Done. A Sprint Review where the Potentially Shippable Increment (PSI) of software is not adequately reviewed will let those bugs pass resulting in all kinds of waste later on.

Ultimately, Scrum Events done wrong will result in waste and will feel like a waste of time. Events done right, in the right order, at the right time all work together to support great Agile. Don’t miss your team’s well executed Scrum Events!

The Right Way

Scrum Events done right will not only reduce waste but will be fun and enjoyable!