I have a confession to make. For the last year I have had an obsession with waste. My study of waste has occupied a large portion of my time and I have even been roping others in to help with that study. Fortunately this is not as unhealthy as it sounds as waste in this context refers to the wasteful activities that my team engage in.
Specifically my obsession relates to identifying where we are wasteful and how we can continuously reduce the waste we identify. The end goal of this waste reduction is to allow the team to become more productive by allowing them to focus more time on productive activities like completing user stories.
So what exactly is waste? One definition describes waste as:
An act or instance of using or expending something carelessly, extravagantly, or to no purpose: “it’s a waste of time”.
In the team context my definition of waste is a little different. Here waste is all the things that the team have to do that are not user stories. Customers have not asked for these things to happen but we have to spend time on them anyway.
However, most wasteful activities do have to happen or no sane team would spend time doing them at all. For example, my definition of waste would label release activities as waste. How are we to get the functionality described in stories into production if we don’t fill out forms for Change Management or actually execute the release steps? Alternatively, the same would apply to essential build maintenance. How can we do continuous integration if we don’t maintain all of the changing moving parts of the build and associated tests?
In my opinion just because we have to do these things does not mean that we can’t question how we do them in attempt to cut down the time we consume doing them. In essence when I talk about waste I am really talking about Opportunity for Waste Reduction. Following my “all non-story work is waste” idea gives the following generalised waste examples for my current team:
- Defect resolution
- Support
- Release activities
- Test maintenance
- Working for other projects
- Miscellaneous (everything else)
(When I discuss this idea the most controversial waste example is defects. Some people I talk to don’t think defects are waste and that time spent fixing them should be ranked alongside story implementation time as being productive. However, I believe that if stories are implemented correctly then we don’t have defect fixes to do in the first place. If we strive to reduce defects then we have more time for new functionality. This makes defects wasteful).
The idea is not to eliminate these activities because we cannot – at least not completely. Instead we should strive to reduce the time we spend on them as much as possible.
A Scrum Master will hear about waste all the time in stand ups, retrospectives and general team chat. Such feedback will identify specific wasteful activities. The retrospectives will even furnish you with corrective actions. This is a good start but I wanted to go further and quantify how much time we spent on specific wasteful activities.
I wanted to do this because I did not want to rely wholly on feedback from stand-ups and retrospectives on waste as it may not be the whole story. I suspected that the waste that team members complain about the most may be the waste that is frustrating them the most but may not represent the biggest cost to the team as a whole. For example, one person may be complaining of spending thirty minutes a day fixing broken builds. However, we may also be losing a total of two days a week across the team to bug fixes which nobody is specifically highlighting because it is not frustrating them. Both sources of waste should be addressed in time but the latter is more costly and should be addressed first. If all waste is highlighted on a level footing then we can see where our corrective actions can be most productively applied.
So to quantify the waste we introduced the concept of a Waste Snake.
The Waste Snake
A Waste Snake is a visual representation of a team’s total wasteful activities for a given period of time. The idea is to set aside some wall space and to form a chain of stickies. Every time the team has to do something they consider to be wasteful they write up a sticky and add it to the chain. The longer the snake gets the more of an issue the team can see they have with waste.
Rather then have one long elongated snake I decided to fit our Waste Snake onto a white board and make it more of a block. It loses the snake effect but the team can still see the waste grow over the course of a sprint so it makes a great information radiator. The Waste Snake can also act as a memorandum which can be used to prepare for retrospectives or even as the focus of the retrospective itself.
Click to Enlarge
The advantage of the Waste Snake is that each waste item is represented by a sticky. This means that various items of metadata can be included. For our Waste Snake stickies we include:
- Team member’s initials
- Short description
- Approximate time spent on waste activity
Here is an example following this format:
Click to Enlarge
Metrics
While the stickies take a very short time to write up and place on the Waste Snake their content provides very useful metrics. Each sprint I enter all waste items into a custom spreadsheet including all of the details from stickies. For the waste description I derive a waste category such as “release activity”, “defect”, or “support” and where relevant sub-divide by environment. For example, “UAT Defects” go in a separate category from “Production Defects”. Note that different teams will have different sets of waste categories.
The spreadsheet automatically calculates total waste for the sprint as well as a breakdown by category. It also charts the waste trends across all available sprints. Using this information I and the team can see our top waste areas as well as the ongoing impact on waste of previously implemented retrospective actions.
Looking back at the retrospective notes for the first sprint in which we collected figures I can see that they had an immediate impact. We noted that in that sprint SIT defects were consuming a disproportionate amount of time at forty plus hours and that we were losing ten hours to assist other projects. In response we beefed up our testing standards and instituted knowledge transfer exercises to the other projects.
This process of tackling the biggest sources of waste based on actual metrics has carried on ever since. For example, we have reduced defects through more stringent requirements, speeded up release activities through tooling and our ability to produce new functionality quickly through refactoring as well as dozens of other improvements in all areas. These actions were all driven and targeted by real waste data.
The historical waste figures are also useful as a component in calculating velocity. In fact because waste can potentially consume so much time I believe it is as important a factor in velocity calculations as historical velocity and planned resourcing figures are.
Waste Changes Over Time
At the outset of the Waste Snake exercise I had an expectation that we would be able to drive down waste to a low level and keep it there. This does not happen in practice. I have found that it is possible to drive waste down in one area but it soon starts to grow again somewhere else. This is not due to neglect as one might expect but due to the constantly changing environment that teams work in. For example, the team’s make up can change, the characteristics of their workflow can change and their external environment can change bringing in new corporate and regulatory requirements which must be obeyed.
That is not to say that driving down on waste is futile. It simply means that you are never done with it. Just as agile teams should continuously improve they must continuously drive down on waste in its many new and varied forms.
Waste Snake Alternative
Note that there are other ways to collect waste metrics. For instance, I know of several teams that collect lego bricks in a box to represent waste. For example a single brick could represent an hour and each colour represent a different waste category. As teams carry out wasteful activities they add bricks of the appropriate colour to the box. At the end of the sprint the Scrum Master can count up the bricks of each colour in the box to get waste metrics. They can even build a lego wall of the submitted bricks to take to the retrospective to demonstrate the magnitude of waste and provide a talking point.
Using lego bricks is a good lightweight way to collect waste metrics if you don’t need the extra detail that can go on a sticky. However, for me the Waste Snake is the way to go because of the detail it provides for just a little more overhead.
The Investment Ladder
I have spoken about Waste Snakes but the title of this post also includes the term Investment Ladder. A few sprints after introducing the Waste Snake idea we hit a problem. Team members were doing non story tasks which were actually beneficial. For example, refactoring, attending relevant training and carrying out retrospective actions. These were not stories so the rule was that they should go into waste. This did not seem right as these were positive behaviors.
In fact they were investments that were being implemented to either drive down on waste or to make us more productive. They should not therefore be lumped in with waste. I decided to break the Waste Snake in two and introduce an “Investment Snake”. A team member had a better idea and suggested “Investment Ladder” as the combination of the two mirrors the name of the board game Snakes and Ladders:
Click to Enlarge
Investment is now tracked to the same degree as waste with similar stickies and its own categories (“Release Streamlining”, “Relevant Training”, “Refactoring”, etc) and it also has its part to play in velocity calculations. However, whereas we actively try and reduce waste we actively encourage managed investment.
More importantly team members not only see a growing Waste Snake reflecting their opportunity for improvement but also a growing Investment Ladder that demonstrates all the good things they are doing to improve.
THE UPWARD SPIRAL 