Scrum and Lean

As a Scrum coach and practitioner, I find that Scrum itself, backed up by my experience, provides most of the guidance that I need to advise clients during agile transitions. However, sometimes it is useful to look at other flavours of agile. Lean Software Development, which shares a common ancestry with Scrum in that they were both inspired by the Toyota Production System and the Toyota Product Development System, provides additional insight that can be used in combination with Scrum.

Lean Software Development emphasizes that part of the improved productivity that can come from transitioning to agile methods comes from the elimination of waste. In their book “Lean Software Development: A Toolkit for Software Development Managers”, Tom and Mary Poppendieck describe seven types of waste:

Partially done work

When organizations or teams start their journey on the agile road, it is quite common for there to be one or more fully implemented but not acceptance tested features at the end of an iteration. This is wasteful because it results in a testing “debt” that needs to be carried over into the next iteration and will delay the deployment of valuable functionality.

Extra features

It’s wasteful to spend time developing features that the Product Owner hasn’t asked for and possibly won’t need. This is really important — as agile practitioners we need to dedicate ourselves to delivering what the Product Owner has asked for and we need to trust the Product Owner to prioritize the Product Backlog so that she gets maximum return on her investment. Of course, this does should not stop team members from proposing Product Backlog items.

Relearning

The Agile Manifesto tells us that we should value “working software over comprehensive documentation”. However, it can be wasteful if the team forgets things that it has learnt or decided and needs to invest time in rediscovering things that it has already dealt with. With agile methods we have a number of techniques to help us to minimize this type of waste. We deal with the classic “how do we communicate with the people who are going to have to maintain this code in the future” problem by creating automated acceptance and unit tests which act as a road map to help people understand the intention behind and the implementation of the code. In addition, we try to capture knowledge as it is acquired by making notes on the project’s Wiki. I often recommend that teams do design work in front of a white board, capture the contents of the white board using a digital camera and upload it to the Wiki. In addition, I recommend that teams maintain a log of important decisions (e.g. why did the Product Owner discard a particular User Story) on the Wiki. By these means we can reduce the amount of wasteful relearning in our Sprints.

Handoffs

It’s inefficient if team members have to do a task and then pass along the results of that task to someone else who does their bit and so on until a particular piece of functionality has been completely developed. There is additional communication every time there is a handoff. It can also be soul destroying — most human beings are better motivated if they can be responsible for more of the whole. The business process re-engineering community has known about this “aggregation” of tasks for a long time yet many organisations still insist in working in silos and handing-off between the silos. In agile software development we should try to avoid handoffs wherever possible.

Task switching

It’s tremendously wasteful to keep switching tasks — something that we all know but many organizations still insist on building switching in to the daily work schedules of their employees. I often see this in software development shops when it comes to support. Developers are expected to do second or third level support at the same time as they are working on new functionality. In a Scrum team with say 6 developers, it would be more efficient to have one developer formally outside the team dedicated to support during each Sprint. So that everyone gets a turn at support (spreading the knowledge and meaning that no one has to do this, perhaps onerous, task for too long) the support role could rotate amongst the available developers.

Delays

Anything that we have to wait for when developing software results in wasted time. By avoiding handoffs, we can reduce delays but we also need to make sure that we have the resources and information that we need when we need it. For example, if the Product Owner is not available to the team due to other commitments, that can delay the team or cause them to have to switch to another task, resulting in further waste.

Defects

Defects are wasteful especially when detected late. In agile software development we therefore spend more time unit testing, refactoring and acceptance testing than with traditional methods. A good agile team will consistently produce code with a low defect density.

To make progress in an agile transition its important to _start_ to address all of the sources of waste and this is something that I am increasingly recommending to my agile enablement clients. Like most aspects of agile enablement, it can be highly beneficial to take baby steps as one eliminates waste, to avoid ruffling too many feathers. However, until the sources of waste in a software development organisation are understood it is difficult to start to take those baby steps so I strongly advocate identifying the sources of waste early even it does result in a degree of discomfort.

Here’s an idea: on a prominently displayed white-board or flip-chart, draw up a large table with the 7 types of waste in the first column, ask the team to brainstorm sources of waste in the second column and ideas for eliminating them in a third column. Where necessary discuss these sources of waste outside the team as well and develop a concrete plan of action (using SMART actions if possible). Cross out or erase the waste sources as you eliminate them during the course of the agile transition.