Personal Kanban Board Examples

I am a big proponent of using Personal Kanban for personal work management. It is an effective technique that allows people to visualise their tasks and limit their work in progress. I’ve used Personal Kanban for the last three years in both my professional and personal life. While I have used various online solutions to create my Personal Kanban boards I prefer to use a real physical board. The visibility and tactile interactions of a real board cannot be beat by even the my most convenient app, mobile or otherwise.

Over this time I’ve snapped a few pictures of the various boards I have put together which I present here.

Below is one of my first Personal Kanban boards from three years ago. My wife and I were relocating from Scotland to the US and had a lot to do to make the move happen smoothly. We were figuring out how to manage the large amount of work we had to do when she asked “can’t we just use one of those board things you use at your work”. By “board thing” she meant “task board”.

I had a small 1.5 x 1 foot whiteboard in my home office at the time. On this I created the TODO, DOING and DONE swim lanes using electrical tape. This board was way smaller than those I typically used for task boards in work but by using small (5 x 3 cm) stickies we were able to fit all of our tasks on. Such tiny stickies are what I have used for my Personal Kanban boards ever since. They minimise my boards’ footprint and force me to be concise with my task naming, especially if I write using a sharpie.

The board worked out well. Its visual nature helped us to build a backlog, prioritise tasks easily and see where we were in the overall move process.

Click to Enlarge

I then started using a Personal Kanban board actively in the work place. At the time this picture was taken I was in a cube in the US with nowhere to put even a small whiteboard. Undeterred I crafted the equivalent to a board on my desktop using painters tape for the swim lanes. Note the addition of the BLOCKED column which I find invaluable.

Click to Enlarge

More recently, back in Scotland, I had reduced desk space so I created as minimalist a desktop Personal Kanban as I could. The swim lane labels are simply sellotaped to the desk with the tasks arrayed in line below.

Click to Enlarge

Similarly when on business trips one of the first things I do at my temporary desk is create a quick ad-hoc Personal Kanban board. All that’s required are mini stickies and a sharpie pen.

Click to Enlarge

Lately my employer has introduced a strict clear desk policy. It looked like my Personal Kanban board would have to go as leaving any written materials on my desk overnight, no matter how innocuous or terse, would break the rules .

Instead I created a more mobile board that I could lock away in a drawer. The basis was a small cardboard box my new webcam had arrived in. I flattened it out, used a sharpie to draw on swim lanes and attached stickies with swim lane labels using sellotape. Finally I used blu tack on the underside of the board to keep it in place on my desktop during the day.

This solution works well and is my current Personal Kanban board. The bonus is that it folds up easily along the original cardboard folds. This allows me to slot it into a small envelope and take it with me when I work at home or go on business trips.

Click to Enlarge

The last example board is not a Personal Kanban board but is the smallest board I have ever created. A colleague and I were the only two developers working on a web app to an aggressive timescale. We wanted a task board to visualise the work but both had an aversion to using JIRA as an online board. Fortunately we sat next to each other separated only by a waist high partition. However, local policy forbade any whiteboards in our workspace as they were seen as being untidy. In addition, due to the partition there was nowhere to put a desktop task board where we could both see and interact with easily.

I then had the idea of making use of the narrow top surface of the partition itself. It worked rather well:

Click to Enlarge

 

Sprint Retrospective Techniques Roundup

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.

 

• The Wheel/Starfish
• Sailboat
• Mad Sad Glad
• The Cool Wall
• Lean Coffee
• Questions Retrospective
• 4Ls
• Satisfaction Histograms
• Circles
• Quartering
• Managing Retrospective Actions

Enjoy.

Sprint Retrospective Techniques 3

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.
• For example: Testing practices, Keeping a clean build, Standup effectiveness, Accuracy of estimates, etc.
• 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.

Definition of Done Workshop

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.

Agile Bug Out Box

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:

• My custom planning poker cards.
• Super sticky notes.
• Mini sticky notes.
• Four whiteboard markers, each a different colour.
• Four black sharpie pens.

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.

Anatomy of a Task Board

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.

Waste Snakes and Investment Ladders

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.

Sprint Retrospective Techniques 2

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:

1. Everyone takes a few minutes to write up one or more stickies with topics they would like the team to discuss in the retrospective.
2. Go through the stickies one by one with the author briefly explaining their question or topic (one minute should suffice for each).
3. 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.
4. 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).
5. All topics are placed under the To Do column in priority order according to the number of votes they have received.
6. The top topic is moved from To Do to In Progress.
7. 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.
8. The topic is moved to the Done column and the next To Do topic is moved to In Progress.
9. 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:

1. Explain the meaning of the questions to the team and provide any necessary clarifications so that everyone is on the same page
2. Encourage the team to place stickies with their answers under each question
3. Wait until everyone has posted all of their answers. Team members can post as many answers to each question as they like
4. Go through each question one at a time
5. Have the team group similar answers to the particular question together into common themes
6. 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.

Perhaps in another year’s time we’ll see the publication of Sprint Retrospective Techniques 3.

Managing Retrospective Actions

In my previous post on Sprint Retrospective Techniques I outlined several approaches teams can use to identify corrective actions to drive continuous improvement. However, I have learned from experience that identifying corrective actions in a retrospective is only part of the battle.

To ensure that the team get the full benefit from their proposed actions they must be appropriately managed. Without such management valuable corrective actions can get lost or unnecessarily delayed and the team can lose faith in the retrospective process. The end result can be a stalling of continuous improvement which is a disaster for an agile team. This post outlines a couple of measures I take to effectively Manage Retrospective Actions.

Agreeing the Actions

The starting point for retrospective action management is in the retrospective itself. If the session has been successful then at the end there will be a set of corrective actions that have been identified by one or more team members. The Scrum Master should go through each action in turn to confirm that the entire team agrees that it is valid. A valid action is one that will improve the team’s productivity without incurring undue cost. Reviewing the actions reinforces their importance and gets everyone in the team in agreement that they are worth implementing.

You may find that the team cannot agree on which actions are worth doing. If the debate hits an impasse then dot voting can be used to break the deadlock. Dot voting can also be useful if there are too many corrective actions for a team to handle. The team can use dot voting to prioritise the most important actions for short term implementation. Lower priority actions that the team does not have the bandwidth for can be dropped for now. Do not worry about losing them as, if they have value, they will crop up again in future retrospectives when they may be more viable for implemention.

Retrospective Actions Board

At this point I have seen teams create stories for each of their actions that then go into the product backlog. I don’t do this because the actions are not stories at all. They are instead things that the team can do to make the business of implementing stories quicker or easier. They can represent documentation, changes to process, improved tooling and so on. What they are not is functionality for the end user. They should not therefore be prioritised with stories.

However, the corrective actions need to go somewhere or they may be forgotten and never implemented. As I believe that retrospective actions are so important and their implementation can be so crucial to a project’s success I make them as visible as possible using a Retrospective Actions Board:

Click to Enlarge

A retrospective actions board is just like a physical task board except the cards on it hold the agreed retrospective actions rather than stories. Actions that have not been implemented reside in the To Do column, those in flight are in the In Progress column and those that the team have actioned sit in the Implemented column. As the unimplemented actions sit right in front of the team every day they cannot be forgotten. In addition everyone can see what actions have been done. This means that the team can see real progress towards their own continuous improvement.

It is one thing to make the actions visible but how do we ensure that they actually get picked up? It is up to the Scrum Master to reinforce the message that any team member can pick up a retrospective action for implementation. After all the team agreed on the actions because they all believed that the actions would make the business of implementing stories quicker, easier, simpler, would result in less bugs, etc. There is therefore nothing wrong with a team member improving the team’s ability to do work by implementing actions while at the same time others carrying that work out by implementing stories. Initially the Scrum Master may have to get involved to ensure that the balance between actions and stories remains optimal. Having a WIP limit on the In Progress column is one way of doing this. However, a self organising team will find a productive balance very quickly and such intervention will rarely be necessary.

Electronic Retrospective Actions Tracking

The Retrospective Actions board is a powerful information radiator for continuous improvement but it is not the whole story. In addition to the physical board I find it informative to keep an electronic history of the actions a team agrees. I do this because with a steady stream of implemented actions the Implemented column on the board will quickly fill up and need to be cleared down. The history of what the team has achieved is then lost. In addition the history can record meta data about actions such as when they are identified, when they were implemented. I call this Retrospective Actions Tracking and it is represented by a page in the team’s wiki:

Click to Enlarge

The tracking page is a permanent record of every retrospective action that has been agreed and its current state. The colour coding indicates actions that are waiting to be implemented (red) or have been implemented (green). I also record the sprint retrospective in which the action was agreed and the sprint in which it was actioned (if applicable). As you can see all of the team’s sprints are named after (good) beers. It is also interesting to record in sprints how long it takes the team to make good on the actions (Sprint Lag). If a successful team ever needs a reminder of the importance of retrospectives and of their progress towards improvement a quick review of this page will reassure them.

The tracking page is also useful for identifying actions that are not being carried out. If an actions sits unimplemented for many sprints after it has been agreed it is worth asking why. It could be that the action is blocked. A blocked action is no less an impediment to the success of the project than a blocked story and may require the Scrum Master’s intervention to facilitate its removal. Alternatively you may find that the action is simply obsolete and that the team no longer believes it its implementation to be worthwhile. In this case, and with the team’s agreement, the action can be removed from the tracking page and the physical actions board.

Action Post-Implementation

Finally it is important to come full circle at the next retrospective. The Scrum Master should review the Retrospective Actions Tracking page prior to the retrospective to see what actions have been implemented in the last sprint. They should use this information in the retrospective to celebrate the team’s continuous improvement success at the same time that completed stories are celebrated. This reinforces to the team that they are making good on the agreed actions just before they identify another set. This helps keep the flow of actions coming.

Summing Up

Retrospective actions can sometimes be neglected. I’ve done it myself with a previously held and incorrect belief that actions would just get done because they were obviously important. However, it is not as simple as that. The actions need to be thoroughly agreed, made visible, their completion actively encouraged and their successful implementation celebrated. Only with these steps in place can a team make the most of the great ideas they have in retrospectives.

My Agile Kit

Over time practising Scrum Masters tend to accrue a kit of stuff that helps them carry out their role. When it comes to planning, estimation, retrospectives and creating and maintaining information radiators such as physical task boards then having a stock of certain props and consumables makes life much easier. I call this collection of useful stuff an “Agile Kit”.

The items that any particular Scrum Master possesses in their Agile Kit will differ but the core items will probably be the same for most: whiteboard pens, markers and stickies. Effective utilisation of these items depends on having an appropriate amount of accessible wall space usually in the form of one or more whiteboards. In my opinion those who attempt to perform as a Scrum Master using electronic aids alone is missing out on the advantages of a tactile and highly visible work environment. Nothing creates more of a buzz within a team then seeing stories move from left to right through the task board.

Most of the items in my Agile Kit take the form of the contents of the drawer of my office desk. It was only recently I collected it all together in this one single easily accessible place. I was surprised by how much stuff I use, much of it every day, to carry out my role. However, use it I do so I thought it would be of interest to others to present the contents of my Agile Kit here.

This is basically a post about stationary which may not seem like an important Agile topic. However, I find that when Scrum Masters get together and the discussion turns towards how we do our jobs we talk about the little details including the raw materials we use to build our boards and run our retrospectives. I have picked up more than one tip or trick that has added to my Agile Kit and assisted me in my role as a result of such discussions.

Here is a picture of my Agile Kit:

Click to Enlarge

Each item pictured and its purpose within my kit is described below.

Top row, left to right

Click to Enlarge

Planning Poker Cards – I have several decks of these including the set I made myself. The others were picked up during conferences and training. I find the cards to be a very useful prop for sprint planning despite the current wave of “estimation is a waste”.

(The planning poker process is an excellent structure within which the team and Product Owner can have a conversation about a story to get on the same page while getting a swift estimate for the customer. Estimation is not a waste if you know why you are doing it and can do it quickly. Either extreme, be it lengthy estimation or no estimation at all, should be questioned).

Electrical Tape – I use electrical tape to create swim lanes on task boards. In minimal time I can use the tape and some scissors to create clearly defined, relatively straight and durable swim lanes on a whiteboard. If you have a magnetic board and want to be really fancy then do as one of my colleagues does and use magnetic tape for swim lanes for guaranteed straight but moveable lines.

Masking Tape – Masking tape can be useful when board space is at a premium. For example, to temporarily attach flip board paper over a task board to create a quick and dirty retrospective space.

Stapler – The stapler comes in handy for permanently attaching extra pages to the back of story cards. I use these extra pages to add details to a story that do not fit on the front of the card. I predominantly do this to attach hand drawn wire frames of the screen that a story is to implement. I find that this is much quicker to do and more convenient to access than an electronic equivalent.

Magnets – I have an abundance of large magnetic whiteboards at my disposal at the moment and make extensive use of them in concert with magnets. I tend to prefer to use magnets rather than stickies for anything that may be in place for more than a few days or needs to be moved around a lot. For example, story cards on a task board.

Middle row, right to left

Click to Enlarge

Stickies and Super Stickies – Stickies are an obvious addition to any Agile Kit due to their flexibility and high availability in most workplaces. I use them predominantly for our Waste Snake and retrospective actions boards and in retrospective sessions. They come in many colours and sizes which can be used to discriminate between different types of “thing”. I tend to stick with standard yellow and resort to making marks on the stickies themselves to discriminate between them. The only problem with stickies is that they tend to fall off surfaces after a limited amount of time. This is okay when they are used in a short retrospective session but unsuitable for a more permanent Waste Snake or retrospective actions board. This is where Super Stickies come in. They cost a bit more but will stay stuck to a whiteboard indefinitely even after being moved repeatedly.

Scissors – If you get creative with your boards then scissors are essential for cutting tape or paper to size.

Story Cards (6″x4″) – I prefer to use white 6″ x 4″ sized card for story cards rather than smaller stickies. The cards are attached to the board using magnets. These are big enough to easily fit several detail in in large legible writing which can be read at a distance. Our story cards typically display the story name, release name, tracking number and, if the story is being worked, the appropriate team member’s avatar is pinned to it.

Envelopes – As releases are completed I collect up the story cards and keep them in separate envelopes labelled with the relevant release name. This is not simple hoarding as the cards and their stapled attachments contain many useful details on the original requirement. Myself and the team will infrequently delve into the envelopes to refer to these details after the stories have been implemented and released to production. For example, when investigating related defects or customer queries.

Blue Tack – I occasionally end up in meeting rooms with non-magnetic white boards and want to be able to attach story cards to them. Having blue tack is handy for these instances.

Paper Clips – We recently adopted a Kanban practice of having small avatars for each team member (we used South Park characters). As team members pick up stories they pin their avatar to them with a paper clip. This is a great visual identifier that adds to the status information conveyed by the task board.

Highlighters – Highlighters are useful for identifying important pieces of information on story cards and their attachments and for adding status marks to the front of story cards.

Sharpies – I find that permanent sharpie pens are excellent for writing clearly and legibly on story cards and on stickies in retrospectives.

Whiteboard Markers, Eraser – As you will have gathered by now my role revolves around the various whiteboards at my disposal. As such I have a large stock of white board markers and an eraser handy to make full use of this resource for retrospectives, the various information radiator boards and for the frequent spontaneous brain storming sessions members the team engage in.

Bottom Row

Click to Enlarge

Magic Whiteboard – This is great stuff for creating a small whiteboard using unused wall space. It attaches by static so causes no damage to walls. It is useful for quick brainstorming or retrospective sessions but not as a permanent whiteboard replacement as it only sticks reliably for a day or so.

Not Pictured

Smart Phone – This is not pictured but I find that having a Smart Phone is convenient. I use it to take pictures of the retrospective board after the retrospective session is complete. The pictures then form the basis of the post retrospective communication including any corrective actions agreed by the team. This is more convenient than a regular digital camera because I can mail the images directly to my work email making images available for use immediately.

So that’s my Agile Kit. What do you have in yours?