Posted tagged ‘Scrum’

Over the last three years I have written a number of posts detailing various Sprint Retrospective techniques. Each technique’s writeup describes what it is good for, the steps to run it and includes pictures of real sessions. This post represents a roundup of all of the techniques I have written about with links to the original posts.

This post presents three more sprint retrospective techniques to add to the six I have already detailed in my previous posts Sprint Retrospective Techniques 1 and Sprint Retrospectives 2. Why present three more techniques? Surely six is enough to drive continuous improvement in any team? First of all I have found these techniques to be useful additions to my arsenal for reasons I outline below. Secondly variation is one of the keys to maintaining the effectiveness of a team’s retrospectives and more techniques makes for more variety.

Technique 1 – 4Ls

The 4Ls is shorthand for the following:

What was Liked? What were the things that the team really appreciated about the sprint?

What was Learned? What were things that the team learned that they did not know before the sprint?

What Lacked? What were the things that the team think could have done better in the sprint?

What was Longed For? What were the things the team desired or wished for but were not present during the sprint?

A 4Ls retrospective can be run by following these steps:

Create a poster for each of the Ls and stick them up on the wall (easel paper is good for this purpose but drawing sections on a whiteboard is a good alternative).

Explain the meaning of each of the Ls to the team.

Click to Enlarge

Hand out sticky notes and markers to the team.

Encourage the team to place stickies with ideas onto each relevant poster and wait until everyone has posted all of their ideas.

Click to Enlarge

Have the team group similar ideas together on each poster.

Click to Enlarge

Discuss each grouping as a team and note any corrective actions.

Click to Enlarge

The reason I like using the 4Ls is that it has the potential to cover a wide range of topics in a compact session. It addresses both the positive and negative aspects of the sprint (Liked and Lacked) but also specifically calls out the teams growing experience (Learned) and problematic gaps that can filled (Longed For).

Technique 2 – Satisfaction Histograms

There are many variations of the Satisfaction Histogram. I came across the version outlined here when a team member on a project I was a Scrum Master on offered to run a couple of retrospective sessions. This is how he ran one of the sessions and it turned out to be very effective.

As preparation pick around four topics that you want to gauge the teams satisfaction of. These can be practices, behaviors or anything else you can think of.

Draw a satisfaction histogram for each of the topics on a whiteboard. Label the x-axis 1-5 for each and add the topic name as a heading.

Click to Enlarge

Explain the meaning behind each of the topics to the team.

Explain the meanings of the 1-5 scale to the team. For example, for “Our Team Communication is…”

1 – “…disastrous, is actively impeding the team”

2 – “…bad, not being done effectively”

3 – “…satisfactory, requires improvement”

4 – “…mostly very good, could still be improved further in small ways”

5 – “…awesome, little or no room for improvement”

Distribute sticky notes to the team, one per topic.

Invite the team to place one sticky note in each topic’s histogram to grade how satisfied they are with the team’s performance for that topic. Sticky notes placed on the same topic and number are stacked.

Wait until everyone has placed their stickies.

Click to Enlarge

Discuss the results for each topic in turn. Where there is low satisfaction or a wide-spread of satisfaction grades dig into why this is.

As potential corrective actions are identified by the team, especially for topics with mostly low numbers, note them down.

Click to Enlarge

This version of Satisfaction Histogram has a number of advantages. First of all the selection of topics means that it can be targeted to certain problem areas. Note that the technique can also be varied to allow the team to suggest topics. This can be done by leaving one histogram blank for the team to suggest the topic during the session. As the team becomes more familiar with the technique you can allow them to suggest all of the topics to be scored for satisfaction.

Secondly it is very visual. At a glance everyone can see the topics where the team is satisfied, dissatisfied or in disagreement. This allows the team to focus on the topics where they belive they are most lacking or conflicted about.

Technique 3 – Circles

Circles is more commonly known as Circles and Soup. I dislike the “Soup” metaphor so I refer to the technique simply as Circles. In addition when I run this technique I replace “Soup” with “Concern”. I understand that the technique is based on Stephen Covey’s book Seven Habits of Highly Effective People.

The idea behind circles is to get the team to focus their energies on what they can change and not to waste time worrying about what they cannot affect.

A Circles retrospective can be run by following these steps:

Define what an impediment is to the team:

“An impediment is anything that prevents you or the team from delivering work as efficiently as possible. An impediment is anything that blocks you working or slows you down.”

Distribute sticky notes and markers to the team.

Ask the team to write down all of the impediments encountered in the sprint, one per sticky note, and have them post them onto a whiteboard.

Wait until everyone has posted all of their impediment ideas.

Click to Enlarge

Ask the team to identify and remove any duplicate impediment stickies.

Click to Enlarge

Draw three concentric circles on the whiteboard and label them, from the inside out, “Control”, “Influence” and “Concern”.

Click to Enlarge

Define what each of the circles means to the team:

Control – Impediments for which the team can take action to remediate.

Influence – Impediments for which the team can collaborate with or make a recommendation to an outside entity to remediate. For example, another team, group or line management.

Concern – Impediments over which the team has no ability to Control or Influence.

Invite the team to collaboratively place each of the impediments in the appropriate circle.

Encourage and guide any debate as to what should go where.

Wait until all of the impediments have been placed in one of the circles.

Click to Enlarge

Go through each Control impediment one at a time and have the team:

Gain an understanding of what each impediment is.

Identify remedial actions that are within the team’s control and write these on the whiteboard.

Go through each Influence impediment one at a time and have the team:

Gain an understanding of what each impediment is.

Identify contacts and recommendations to influence their remediation and write these on the whiteboard.

Review the Concern impediments to gain an understanding of what they are.

Note that as the impediments are discussed the team may identify actions that had not previously occurred to them. This can cause the impediments to move inward. For example an impediment that was initially placed in Concern may move to Influence or Control.

Click to Enlarge

Circles is my new favourite technique but I use it sparingly. The reason I try not to overuse it is because it focuses very much on impediments and does not have the “celebration of success” aspect that is built into most other retrospective techniques. However, it is a powerful technique for sprint retrospectives as well as for other purposes. It is, for example, ideally suited to holding retrospectives into releases especially those that proved to be problematic.

A few months ago I underwent a career change by converting from being a Scrum Master to an Agile Coach. I am still adjusting to my new role but am, by and large, enjoying the challenge and change of pace that it entails. I work with a number of internal teams which represent a fairly broad spectrum of Agile experience from novice to intermediate.

When I engage with a team for the first time I ask them a number of initial questions to help me to gauge their Agile maturity. Some of these concern the Agile ceremonies they practice and the particular Agile artifacts they make use of. What has surprised me so far is that an overwhelming number of these Agile teams did not have a Definition of Done.

For those not familiar with what a Definition of Done (DoD) is I will attempt to summarise the concept here. A DoD is a checklist of useful activities that are carried out by a software team every time they implement a user story. The DoD can, for example, include things like ‘Code’, ‘Unit Test’, ‘Integration Test’, ‘Peer Review’, etc. The idea is that the culmination of all of these activities against a given set of requirements will result in potentially releasable software. That is quality software that satisfies the requirements. Until all of these activities are completed successfully for a given user story it cannot therefore be considered ‘Done’.

It is important to note that every team’s DoD will almost certainly contain different activities because they do different types of work and have different means of ensuring quality. Therefore every team has to spend some time coming up with their particular DoD.

For Agile teams an agreed and published DoD is essential as it brings transparency to a team’s way of working. Firstly it helps to ensure that everyone on the team is on the same page as to what “Done” means and how they should get there. Secondly as the DoD is written down it can be discussed and subsequently altered as the team agree to make changes to how they work to improve quality and efficiency. For example, via their retrospectives.

Some of the teams I coach had not heard of a DoD. Some had but had not written theirs down. However, they insisted that they knew what it was. As an experiment I asked several members of the same team what they thought their team’s DoD was. I got back as many different answers as the number of team members I asked. Although the teams thought they had a shared idea of their DoD they did not.

As a result of these findings I have been on a DoD offensive of late. This has involved explaining the benefits of having a DoD and helping teams to get their initial DoD published. I have helped so many teams define these recently that I have come up with a workshop format to help drive them out. I present the outline of this DoD Workshop format in this post.

The Workshop Format

The workshop is designed to be run in-person and ideally the entire team should be present. When not all of the team members can attend and the team is not cross-functional then all functions should be represented. No specific preparation is required on the part of the team. I allow an hour for the workshop and hold it in a room with a white board or similar usable wall space.

I start by explaining what the session is about, i.e. creating the team’s DoD which will subsequently be published on their wiki. This of course involves explaining what a DoD is and how it can help the team. This normally raises a few questions from the team and I address these before moving onto the next stage of the workshop.

Next I hand out sticky notes and sharpies. I request that the team think of all of the high-level activities that they normally engage in to get a story done. I ask them to write each of these items onto the sticky notes with one activity featured on each sticky note. I insist that everyone writes up at least a few sticky notes and that they only include the activities that they do now not things they would ideally do in the future.

Once everyone has finished writing I get the team to post all of their items, in no particular arrangement, onto the white board.

Click to Enlarge

Next I ask the team to collaboratively group similar and identical items together. Team members may have used different terminology to describe an otherwise identical activity but by working together they can identify which stickies are actually the same thing.

Click to Enlarge

With the groupings complete we go through each one and validate all of the items within it are truly the same activity. I also check that the team actually does the particular activity now and that it is not simply an aspiration. Any such aspirational items are removed.

Next I work with the team to place each activity group into a timeline. The placement of the activities reflects the order in which each takes place within the team’s development process.

Click to Enlarge

With the timeline in place we now turn attention to creating a headline name for each activity. This is necessary because individual team members may refer to the same activity by a different name. For example, “Implementation”, “Coding” and “Development” are all different terms for the same things. Having the team agree on a single name for each activity introduces a consistent terminology that the team can use to enhance their communication when discussing their DoD. In addition if a team struggle to create a headline name for one of their activity groups then it suggests that it may need to be broken up into several more nameable activities.

The agreed headline names are written against each activity.

Click to Enlarge

With the headline names agreed I go through each activity again. This time I ask the team to define what is involved in accomplishing each of them focusing on the deliverables, outcomes and conditions that represent success. These descriptions are written against each activity beside the headline name.

Click to Enlarge

The combination of the ordered activities and the more detailed descriptions represent the team’s DoD.

Post Workshop

Finally I snap a picture of the board and collaborate with the Scrum Master to have it documented in the team’s wiki and communicated out to the team. If possible I also recommend that a paper copy be posted somewhere in the team’s physical work area.

Note my insistence throughout the process of only including the things the team does now. This may seem overly constraining when the team could be suggesting good adaptions. However, the main purpose of the exercise is to capture what the team does now. Immediately after the DoD is agreed and published the team is free to discuss it and make positive changes. This may even happen in a separate, later section of the workshop. The key is to write it down first, warts and all, so that the team’s improvements can be made against a known state.

When to Run the Workshop

So far I have only used this workshop format to help document the DoD for teams that are already sprinting. However, new teams should not wait until they are partway through a project before they create their DoD. They should instead put it in writing at the very beginning.

I envisage that this workshop format could be used equally as effectively to create the initial DoD for a newly formed team. The only difference would be to have the team write-up stickies for the activities they think they will need based on their previous experience. Otherwise the session could be run in much the same way.

A month ago I relocated from Scotland to the US. This move necessitated a lot of planning (and heavy use of more than one personal Kanban board). Many decisions had to be made. In particular I had to decide what to take with me and what to leave behind.

One of the things I decided to leave behind was my rather voluminous Agile Kit. Everything in the kit has its use but it wasn’t going to fit in my luggage. Also by the time the main shipment of my belongings travelled between Scotland and the US I would have had to replace most of it anyway. I therefore gave away most of the kit to my local Scrum Master colleagues.

I say I gave away most of the kit because I would need a couple of materials to hand from day one of my move to help me facilitate planning and retrospective sessions in my new workplace.

I decided to have a little fun with the exercise and brand my mini Agile kit. I have an unhealthy fascination with weird reality shows. One of the shows I watch is Doomsday Preppers. Preppers are survivalists who prepare for extreme, sometimes civilisation ending, events. One thing preppers have constantly to hand is a bug out bag. This contains everything a prepper needs to survive for a few days should the worst happen and they need to get out of dodge fast.

Stretching the analogy more than a little I decided to create a prepper styled Agile Bug Out Box. I chose a box rather than a bag as it would protect its contents better and I liked the look of Corinna Baldauf’s Scrum Master Emergency Kit which also takes the form of a box. The box would contain everything I would need to perform my agile role for a few weeks.

The box itself is simply a small Tupperware box which is durable and fits easily into my luggage. I labelled it “Agile Bug Out Box” using the Old Stamper font and added some warning stripes to make it look suitably prepper-like:

Click to Enlarge

With the box picked and labelled I had to decide what to put in it. This was tricky because the box is very small and I use a lot of stuff day-to-day. I had to consider what I absolutely needed not just what made my life easier. I finally settled on:

To round out the kit I used thin elastic hair ties to tie the pens and cards together so the kit would stay ordered:

Click to Enlarge

So why did I settle on these particular items?

One of the planning techniques I use is planning poker so I needed a deck to do that. While I gave away all my other official decks I couldn’t part with my custom hand-made deck or risk them to surface transit.

The super stickies, white board markers and sharpies are essential for me so that I can run retrospectives. Every technique I currently perform utilises some or all of these items.

Finally there are the mini stickies. I use these in concert with larger stickes to create basic, compact personal Kanban boards for when I am on the road like this example here:

Click to Enlarge

I have been in the US for four weeks now and my Agile Bug Out Box has proved to be invaluable. However, there is a Staples store just over the road from my office so I will start building up a full agile kit again soon. I’ll keep my Agile Bug Out Box to hand though. After all you never know when you’ll need to bug out.

One sign of a healthy Agile community within a work place is an abundance of varied physical task boards. By varied I mean that the boards are not identikit copies of each other in form and composition. For example, boards that do not have the exact same swim lanes, card types and information items on the cards. Just as all projects are different so their main information radiator, the humble task board, should reflect their different characters and requirements. Variation in task boards is an indication that teams are adapting to overcome their own particular issues and not just participating in an Agile cargo cult.

The task boards in my current workplace certainly demonstrate this kind of healthy variety. This is advantageous, not only because it shows each team exploring their own different path to improvement, but because seeing what other teams are doing can spark change in your own team.

In that same spirit of sharing, in this post I present an anatomical tour of my current team’s task board in the hope that it may spark ideas for other Agile teams. Note that in no way am I recommending our current task board set up as a perfect example. It is just the set up that works well for us at this moment in time.

Scrumban

Before going into the details of the task board I will explain our current development methodology as it has had a huge impact on our task board’s construction.

Until relatively recently the team utilised straight Scrum. The team was relatively mature and decided to move away from Scrum’s fixed iteration structure towards a more continuous flow approach. Kanban was an option we wanted to try. However, jumping straight to Kanban struck us as being a little risky. We instead decided to have a go at a hybrid approach known as Scrumban.

The Scrumban process is outlined in an article written by Corey Ladas. In summary the idea behind Scrumban is to start with Scrum and move towards Kanban step by step. Specifically the following practices and artefacts are introduced gradually over time:

Break up existing work flow into clearly defined steps

WIP limits on work swim lanes

Introduce queue swim lanes

Maintain a cumulative flow diagram to measure performance

Limit the size of the backlog

Use an order point to indicate when the backlog should be replenished

The idea is that if all of these transformational steps are followed then you will be able to shrug off much of the Scrum framework and emerge with a continuous flow process far closer to Kanban.

For example, with the introduction of the last change one of the main Scrum ideas, fixed iterations, can be eliminated. Planning happens when it needs to and not at the start of each iteration. The other Scrum ceremonies such as demos and retrospectives can also be demand driven or have a cadence potentially unrelated to the original iteration length.

As you can imagine the task board was central to making our way through the transition stages of Scrumban described above.

Our Task Board

The team is lucky to have exclusive use of three sizeable white boards laid side by side. This gives us a huge space to lay out our task board. In common with all of my boards I use electrical type to create lines as, opposed to drawn on lines, as the tape cannot be accidentally rubbed off.

Here is a picture of all of the boards that comprise the task board. I will describe the contents of each board from left to right.

Click to Enlarge

The first board contains two areas “Ready for Estimation” and “Waste Snake/Investment Ladder”:

Click to Enlarge

The bottom area is not strictly related to the task board and is used for waste and investment tracking. I have outlined the purpose of tracking waste and investment in a separate post for those who are interested.

The top area is more relevant to this article and contains cards representing stories that are deemed to be “Ready for Estimation”. This is a prioritised backlog of work for which the requirements have been defined to the appropriate level. The top priority stories from this area are estimated periodically before being placed onto the task board proper which starts on the middle board.

The middle board contains the bulk of the task board’s swim lanes:

Click to Enlarge

There are a number of features worth noting here.

Firstly are the numbers 8 and 2 in the “Ready” swim lane. The “Ready” swim lane contains stories that have been estimated by the team and accepted into the work flow but for which work has not yet started. The 8 represents the maximum number of stories that can appear in this swim lane. The 2 is the lower limit at which we schedule a planning and estimation session to accept more items from the “Ready to Estimate” area into the “Ready” swim lane. We are able to maintain a low Order Point value as our team in co-located and therefore our required lead time for planning and estimation sessions is low.

Secondly the numbers 6 and 3 for the “In Progress” and “In Verification” swim lanes represent WIP Limits for these work in progress steps. These numbers have been tuned over time to achieve optimal flow. “In Progress” represents the process of a story being implemented to a state that satisfies our Definition of Done. “In Verification” represents the process of checking that completed stories are truly up to scratch as regards our testing and UI standards. The “Done” swim lane acts as a queue between these two work in progress states. Stories can move to the “Verification Failed” or “Verification Passed” swim lanes (found on the next board) as appropriate. The team have a rule that states that a team member must remediate any of their stories that fail verification before starting a new story.

Thirdly note that stories in the “In Progress” and “In Verification” states have avatars attached to them with paper clips. The avatars represent the team member currently working on the story. Each team member has chosen a South Park character to represent them. Task board avatars are a great communication method as, at a glance, anybody in the team can see who is doing what.

The third board contains the remaining swim lanes that make up our flow:

Click to Enlarge

The “Verification Passed” swim lane forms a queue for items awaiting demo. As this queue fills up we schedule demos with the Product Owner. Stories which are accepted by The Product Owner move into the “Demoed” swim lane.

The “Demoed” swim lane represents my biggest disappointment with our current process. As you can see it is double the width of the other swim lanes. This is to accommodate the large number of stories that are potentially ready for release but have not yet been released. Unfortunately in our organisation the high coordination costs of UAT and Production release means that releases are not as frequent as we would like. The positive thing about the swim lane is that this issue is made very visible on the task board which may itself help to spark change in this area.

Accessibility and Visibility

Besides the rich information conveyed by the task board two other things make it highly effective: its accessibility and its visibility.

The task board’s accessibility refers to there being unobstructed space around it. This means that the team can have their stand ups around it. Having the task board present at stand ups eases communication during the ceremony as the project’s current state is right there for all to see. The task board’s accessibility also means that team members can take responsibility for keeping the board up to date at all times during the day. This takes discipline but is achievable if team members can see the benefit.

The task board’s visibility refers to it being in a prominent position viewable to all team members while they work. Coupled with the fact that the board is always up to date this visibility means that the board makes for a powerful communication medium at all times of the working day. I especially like it that the positive act of a team member moving a card through the flow is seen by everyone and has a motivating effect on the team.

Story Cards

Just as important as the information the task board conveys is the information that individual story cards make available. Here is a typical story card from our task board:

Click to Enlarge

I prefer to use large 6″x4″ cards for task boards as more information can be fitted onto them than stickies. Larger writing can also be used aiding the overall readability of the task board. In concert with a magnets (and a magnetic whiteboard) it is easy to move the cards through the task board’s swim lanes and they never fall off the board. We display the following information on our story cards:

The release name

The issue tacking number

The story name

The story point estimate

The avatar of the team member working the story is attached

The size of the cards means that we can introduce new items of information in future as required.

(Note that we continue to estimate in story points. This illustrates that we are still very much in the Scrumban transition stage rather than having become a Kanban project. This is one of the things I like about Scrumban: you don’t have to go the whole way all at once.)

Our stories are cross-cutting and so most of them inolve the creation of a UI screen. To guide the team member in the creation of the UI we create simple wire frames of the UI layout which are stapled to our stories for easy reference:

Click to Enlarge

Using the same technique any type of relevant attachment can be added to cards further improving their utility.

All other specific detail about the story including test examples are included in the electronic issue tracking system. The appropriate tracking number is referenced on the front of the card.

Avatars

While the primary use for avatars is to enhance communication they can also add a bit of fun for the team. The first thing to do is pick a theme for the avatars. Cartoon or comic books characters work well because they are usually easily recognisable. Next let team members choose their own avatar in line with the theme. This will engage them more than if you just pick an avatar for them and will encourage use of the avatars on the task board.

For example, for my team I decided on South Park characters for the theme and had team members chose the characters to represent them:

Click to Enlarge

I coach another team and in this case Mr Men characters were used for avatars:

Click to Enlarge

You can see from the pictures above that the avatars have been laminated. I recommend that you do this as otherwise, if the avatars see normal use, they quickly become tatty and unreadable.

Task Board Sharing

I hope that this post will help spark inspiration in other teams to change their task boards to enhance their communication. On the flip side I am always interested in what others have done with their task boards so I can learn new tricks. Please share your ideas and task board pictures so that others can benefit.

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.

A year ago I published a post on Sprint Retrospective Techniques that I employ to help my team to continuously improve. Since then I have tried out many other techniques to keep things fresh for the team. In this post I present three more simple techniques I have found to be especially effective.

Technique 1 – The Cool Wall

The Cool Wall is my favourite retrospective technique at the moment as it is not only very effective but also a lot of fun. I discovered it while browsing blog posts on the web looking for new retrospective techniques to try out. I am a fan of the UK motoring show Top Gear and this technique is based on an occasional segment from the show, “The Cool Wall“.

In the show the presenters Jeremy Clarkson and Richard Hammond decide how cool various cars are by placing pictures of them in various categories labelled: “Seriously Uncool”, “Uncool”, “Cool”, and “Sub Zero”. The show involves audience participation but ultimately the presenters (especially Clarkson) decide how cool each car is (usually overriding the audience).

For the retrospective version of The Cool Wall the cars are replaced by cards that represent positive practices or behaviours that the team engage in. For example, ‘Continuous Improvement’, ‘TDD’, ‘Listening to Customer Feedback’, etc.

The Scrum Master plays the part of the presenter while the team take on the role of the studio audience. For each card the Scrum Master asks the team:

“How cool are we at…<thing written on card>”

The better the team decides they are at the thing written on the card the cooler the category they agree to place it in. The Scrum Master then places the card on the board in the agreed “coolness category”. The most important difference between the retro technique and the TV show (and the reason it works as a retro technique as opposed to as entertainment) is that the audience/team decide on “coolness” not the presenter/Scrum Master.

The technique requires a little preparation. Beforehand the Scrum Master should prepare the behaviour/practice cards. The content should be topical to the particular team and their current circumstances. I also create small voting cards for each “coolness” category to allow the team to efficiently vote rather through the yelling and shouting that happens in the TV show. This also prevents the team from aligning themselves with the first vote that is shouted out.

Click to Enlarge

The next step is to draw the cool wall on a large whiteboard complete with the headings “Seriously Uncool”, “Uncool”, “Cool”, and “Sub Zero”:

Click to Enlarge

The session proper can now begin. The Scrum Master produces each card in turn and asks the team how cool they think they are at what is written on it. The team use their voting cards to display their choice. If there are wildly differing opinions on “coolness” then discussion can ensue until some consensus is reached. At this point the Scrum Master places the card on the board in the appropriate “coolness” category and moves onto the next card. Just like in the show it is permissible to place a card between two categories where agreement cannot be reached. This voting and discussion process proceeds until all cards have been placed on the Cool wall:

Click to Enlarge

With all of the cards on the board it is time to move onto the next step. One card at a time the team discuss the things they are “Seriously Uncool” and “Uncool” at doing and identify corrective actions to improve their “coolness” at doing the thing on the card. I tend to write the key points of the discussion and any corrective actions onto the board as we go for future reference:

Click to Enlarge

Technique 2 – Lean Coffee

I have written about Lean Coffee before in reference to the Lean Agile Glasgow meetups. Lean Coffee is a great technique for democratising meetings which is also suitable for retrospectives. The democracy comes from the team providing the topics and prioritising them for discussion.

While I allow an hour for most retrospective sessions I run I find that a Lean Coffee retrospective session requires up to two hours for a full discussion of the most important topics to take place. It is also the only type of retrospective that I run with the team sitting down as it does not require the use of a board.

The session follows this format:

Everyone takes a few minutes to write up one or more stickies with topics they would like the team to discuss in the retrospective.

Go through the stickies one by one with the author briefly explaining their question or topic (one minute should suffice for each).

Everyone dot votes on the topics they most want to discuss. Each attendee gets three votes to spend – they can put multiple votes on any one topic and can vote for their own topics if they so wish.

A Personal Kanban is created with three columns: To Do, In Progress, Done. The In Progress column is WIP limited to 1. Stickies are used to create the headings (see picture below).

All topics are placed under the To Do column in priority order according to the number of votes they have received.

The top topic is moved from To Do to In Progress.

A 15 minute discussion ensues around the topic. A smart phone is handy to do the timing. If discussion around the topic dries up before the 15 minutes are up then progression to the next step comes early. Any corrective actions that are raised during the discussion should be noted down for agreement at the end of the session.

The topic is moved to the Done column and the next To Do topic is moved to In Progress.

Repeat from step 6 until the session time or topics are exhausted.

Click to Enlarge

Technique 3 – Questions Retrospective

The final technique is the Questions Retrospective. The format involves posing a series of question to the team about how things have gone from their perspective. For example, here are some questions which I have gleaned from various sources and that I think make for a good generalised set:

What Worked Well?

What Should We Do Differently Next Time?

What Did We Learn?

What Don’t We Understand That Needs To Be Clarified for Future?

What Made You Mad?

What Made You Laugh?

You can target specific topics by introducing specific questions to address them, for example, to explore an event, good or bad, that has occurred in the preceding sprint.

Note that while this technique works well for sprint retrospectives I find it to be especially powerful for project retrospectives where a longer period of time is being considered. All of the pictures below were from a recent project retrospective I ran hence the sheer number of answers that were given.

In preparation for the session I send out the questions to the team in advance to encourage as much feedback as possible. In the case of a project retrospective I do this several weeks in advance. I also encourage the team to bring any answers they have pre-written on stickies so that ideas they have before the session are not lost and to speed the session up a bit.

Immediately before the session starts I write all of the questions onto a large white board:

Click to Enlarge

When the team members have all arrived the session can proceed:

Explain the meaning of the questions to the team and provide any necessary clarifications so that everyone is on the same page

Encourage the team to place stickies with their answers under each question

Wait until everyone has posted all of their answers. Team members can post as many answers to each question as they like

Go through each question one at a time

Have the team group similar answers to the particular question together into common themes

Discuss each grouping one at a time identifying and recording any corrective actions

Click to Enlarge

You Can Never Have Too Many Techniques

Keeping retrospectives engaging, and therefore effective, requires constant work on the part of the Scrum Master. Having a static set of techniques, however tried and tested they may be, is not enough and we have to keep innovating. I find I have to constantly seek out new techniques to accomplish this. Fortunately Agile practitioners are a generous bunch and new techniques are constantly being published on their blogs.

I have not been taken with every technique I have read about or gone on to try out and frequently make my own small adaptations to those I do use to increase their effectiveness for my team’s particular circumstances. This amounts to quite a lot of work but the rewards in the form of continuous improvement are worth it.