Building a taskboard using a laser guide
Here’s a high tech and original way of building a physical taskboard. (source: Agilar team @ Belgacom)
Samir Hanna is a ScrumMaster at F-Secure in Bordeaux. He and his team felt they needed to improve their taskboard.
“The board is the mirror of the team’s daily work. The board was a mess… You could not see anything, everything was confusing… You can’t have clean water coming from a dirty pipe.”
He wrote an e-mail to the Agile Games mailing list asking for a suggestion and was referred to the Visual Management workshop I ran at Agile 2009 in Chicago.
Read Samir’s account on how he ran the workshop within his team, with great results. Nice taskboard Samir! I particularly like the small pictures and the status tags. And of course the gun.
How does a self-managed and self-organized team coordinate holidays and other planned absences? It doesn’t need to be
more complicated than a Team Calendar. Print a blank monthly calendar on an A4 sheet of paper (you can do this from Outlook, or if you want to go fancy, Visio) and put it on the taskboard. Team members write their name on the days they will be out of office.
(Click to zoom on the pictures) The team calendar is also a good place to write down any team events, indicate start and end of sprints, etc. This closeup of the calendar below shows
which 2-week sprints the team will be doing during the month. It also indicates the day they demo and plan (every two mondays) and there is a national holiday indicated by the little island icon.
As you approach the end of the month, you probably want to put up next month’s calendar on the board, at the same time as the current month.
Hello! I am Laura Quesada Allue. I was born in January 2010. Maybe you were wondering why my daddy hasn’t written anything on this blog for the last 8 months? Well, now you know!
This blog post tells the story of how my parents used Visual Management to coordinate the tough project of preparing themselves for my coming to the world. I leave you with them now…
Project initiation
When we learned we were going to be parents, the first thing we did was to think about the main characteristics and constraints of this project.
- There were two main tracks. One had to do with making sure the pregnancy and delivery went well. Tasks in this track were for example periodic visits to the doctor, finding a good hospital, etc. This track was high priority and almost all tasks were “must have”.
- The other track dealt mostly with things we needed to get ready before the baby was born, such as the baby room, the baby card, having enough clothes, the Maxi-Cosi, etc. Tasks in this track were spread all over from “must have” to “nice to have” so they were very good candidates for prioritization.
- We can think of the customer of the project as Laura, and the team as us the parents. Other stakeholders included the doctors, family and friends.
- This project was going live no matter what. Like the Olympics, you can’t change the date one month before launch just because you’re not making it! An interesting note is that we didn’t know the exact go live date, we only had a range. We would be told the exact launch date by the customer (Laura) with aprox. 24hs of anticipation
. So we had to be ready with all must-have functionality by the earliest possible launch date. - For some tasks the acceptance criteria was very negotiable. For example: buying a crib was a must-have. But that the crib should be the coolest crib on earth was nice-to-have. ‘Coolest on earth’ was part of the negotiable acceptance criteria of that story.
- Some tasks had to happen at a certain fixed date, others were flexible. Typical fixed-date tasks were doctor’s appointments for example.
- The team members (us, the parents) were not working full time on the project. This means that at certain moments, if necessary, we could scale up our efforts on this project to the detriment of other parallel projects we were doing (for example searching for a house, or our day jobs).
- We wanted to delay doing things until the last responsible moment, but we also wanted to do things at a sustainable pace. The challenge was to balance our workload evenly.
Based on these characteristics, we chose the following Visual Management
strategy:
- Since the project was time driven, we would build a physical taskboard that visually represented the project timeline.
- We would populate the board with tasks and metadata (important information we had about the project).
- Tasks would have a different color based on their nature: orange for normal tasks, pink for fixed-date tasks (appointments), blue for special events such as Agile conferences or other travel.
- The pink and blue tasks were fixed on the timeline by their nature. The orange tasks could be moved around. We would balance the load by changing the position of orange tasks so as to spread work evenly throughout the project.
- What to do with tasks that got done? First we thought on crossing them out and keeping them there, but we quickly learned that it was visually confusing. So finished tasks would be removed from the board.
Building the taskboard
Note: you can click on all the pictures for a high-resolution version.
The timeline represents the 9 months of pregnancy (blue lines) and the first 3 months of Laura’s life (green line). We didn’t know if we would need the green line, but we had space left over so we put it in anyways.
We wanted to visualize calendar months and pregnancy weeks at the same time, because certain tasks or events are commonly associated with the week number, while months gave us the big picture.
A detail of months and weeks. What you see in blue is all electrical tape.
We got these cute clip magnets at XP Days Benelux; they would come in handy.
Running the project
This is how the board looked when we got started, in week 5 (June 2009). The board was populated with all tasks and information we had at the moment: our initial planning. We adorned the board with some cute baby-themed magnets we got from cousin Flo. Tufte would not like them, they were pure decoration.
Once the project got underway, the following activities were typical:
- We would remove post-its (tasks) as they got done.
- We would add new tasks as new requirements came up.
- Sometimes big tasks got broken up into smaller ones, or one task being completed triggered more to be created down the line.
- We would re-prioritize tasks if they were not done by the original planned date.
- Reports generated by the project, for example the ultrasounds (ecografías), were placed on the timeline.
- Any other relevant information was either stuck on the board with magnets or written with whiteboard marker.
We would regularly make small improvements to the board. For example we added a green “you are here” arrow. Some people asked us what the board was about, so we added the title “Baby Board”.
The board was both an effective planning tool for the future, and a living recount of the past.
You can see that as the green arrow moves along, the post-its disappear with it. The fact that post-its were not accumulating further down the line meant we were proceeding at a good pace. If we would notice a cluster of orange tasks accumulating, we would know we were behind schedule and would react by putting in more time, or dropping requirements.
Finally the date was approaching! We knew the project would be a success because almost all our tasks were done.
Going live
The release to production took 11 hours, and was quite tough for one of the team
members (guess which one)… but eventually it was successful and the project went -very literally- live. Welcome, Laura!
In Belgium, people exchange cards when a baby is born. As cards started to arrive, we put them on the taskboard, turning it into a “celebration” board.
At the end, we almost didn’t have enough room! One of the best cards we got was a mini-taskboard baby card from one of the teams we coached. Thanks guys!
To close, a big smile from Laurita dedicated to all the friends in the international Agile community. Isn’t she cute?
Status tags are my preferred approach to visually attaching state metadata to work items.
In plain english, what this means is that if you have a task, represented for example by a standard size Post-it, you would add a physical tag, represented by a smaller colored Post-it, to indicate it has some particular status, such as “Blocked” or “Delegated” or “Bug” or “Please Test”. This creates visibility and awareness and enables the right people to react to that new status fast.
A visual alternative to tagging is creating special columns or specially designated areas in your taskboard that fulfill the same purpose.
While this is valid, and many people do it, I much prefer tagging to that approach. Taskboard real estate is expensive. If you start creating special areas or columns for each status a piece of work can have, you might quickly fill your Taskboard with empty zones. Furthermore, changing the structure of your taskboard is cumbersome. This might limit the number of status areas you create. Too many areas and columns make people think about waterfall processes, even if they are not meant to be used. For example, look at the picture of the following kanban board:
While it looks good because it was done with care, there is much wasted space in those columns and boxes. And let’s take a closer look at those separate areas at the right. In this example we see a “Back to business” box. What if this status is very temporary? In that case, you are probably better off tagging it. Creating the box has allowed work to accumulate there, unchecked. Are all those post-its supposed to be going back to the main board? Someone is going to be spending some serious time moving post-its back and forth…
Another example: let’s assume a task that involves coding but is functionally testeable is being developed. During the same day the following happens:
- A developer starts and finishes it
- Someone else tests it and finds a bug
- The original developer fixes the bug
- The task is re-tested and this time declared “done”.
This is a typical
scenario in Agile teams. If you have separate columns for “In development”, “To validate”, “Defect found”, you are going to spend the whole day moving the task around columns. People might lose track of where the task went (well, not really – but it does require more effort to locate it). I prefer the much simpler solution of leaving the task in place and rotating status tags on top of it. Another advantage: if it would go through this code-test-bug-fix cycle many times, you can place status tags on top of others, creating a “traceability” effect. With columns, you can’t do that.
Tagging is very flexible. There is no limit to the number of
tags you can create. Some teams create temporary tags for special occasions. In the example above, the tag “checked” was created specifically for the occasion. This can be done quickly and easily by the team by their own initiative. Almost no work is required and suddenly your visual management process includes a new status.
I think the elegance, flexibility and visual appeal of using colored tags for indicating task status cannot be denied. Even in a software tool, it looks good, as the example below shows.
For physical taskboards, my preferred tags are Post-it 653 which come in many different colors. They are the 1.5″x 2″ small ones.
Important detail: if you just stick this small post-it onto a bigger one, it will not stick, it will fall off almost instantly. That’s why I use a small piece of Scotch Magic tape with each status tag. See the first picture in this post for a detail.
Tags: agile, elements, Kanban, Scrum, Task boards, Visual management
In this tutorial I will explain how to build a physical taskboard out of electrical tape step by step, for those of you who -like me- were not born with a gift for bricolage. I admit up front to this post not being my most intellectual piece of work ever, but I’m hopeful more than one of you out there will find it at least marginally useful.
I
will demonstrate using a 120 x 90 cm whiteboard, the smallest format that will support a small team board. Magnetic whiteboards make great task boards because the surface is so versatile: you can write on it, you can stick magnets, post-its stick and unstick very cleanly, so does Scotch Magic tape, and -most important for this case- so does electrical tape, which is what we will be using to make the lines. That means that if you make a mistake, you can just unstick and re-stick the tape, though it will never be as easy as the first time around. The downside, of course, is that they are expensive and/or not always available for hijacking in your office. That’s why I advocate building boards wherever you can: I have built boards on the back of closets, directly on walls, and even on windows (looks cool at first, but later it’s very distracting – your attention always ends up going to what’s outside).
What you will need:
- 1 ruler
- 1 roll of electrical tape
- 1 whiteboard marker
- 1 pair of scissors
Note:
if you don’t have a whiteboard, electrical tape might ruin your surface (for example it might peel off low quality wall paint). A good alternative is thin blue painter’s masking tape.
Step 1: This is how our whiteboard looks before starting. If you did not buy a new board, make sure it is clean of any old whiteboard marker ink, old pieces of scotch tape, etc.
Step 2: Make two small marks at 25 cm from the left side of the board, one should be around 5 cm from the top, the other almost at the bottom.
Step 3: Press the tip of the tape with your thumb on the top mark.
Step 4: Carefully extend the tape out and downwards, without touching the board, making sure you do not pull too hard on the tape. Electrical tape is elastic, and if you pull, you will stretch it and stick it in a stretched state. Later on it will contract to its original length, unsticking and curling upwards, ruining all your great effort. (It took me several cases of shouting “Who sabotaged my taskboard!” in vain to figure this out)
Step 5: With the tape still only touching the board at the point pressed by your thumb, carefully bring down the roll of tape onto the bottom point.The full roll should be resting on the bottom dot. The tape will now be touching the board but only lightly.
Step 6: Carefully pass your thumb upwards over the entire tape, which should stick cleanly and nicely to the board.
Step 7: Cut the tape at the bottom and voilá, you should have a perfect line.
Step 8: Repeat 3 more times, each line 25 cm from the one before it. You should now have 4 vertical lines.
Step 9: The horizontal lines should be placed in a similar way. First put the bottom line on the bottom of the board. Then measure upwards at distances of 15 cm. You should be able to place 6 lines.
Step 10: Add any additional sections you wish in a similar fashion. Then add little signs for the columns, status tags, nametags, team pictures, and you are ready to start scrumming!
For the electrical tape, I recommend 3M Temflex 1500. This tape is cheap and high quality and in Belgium can be purchased at the Brico for less than 1 euro the roll. Look for these packages of 10 rolls if you are going to build multiple boards for different teams: you get all kinds of colors.
Tags: Task boards, taskboard
This is my recount of my session at Agile 2009 Chicago. It was titled “Visual Management for Agile Teams” and was part of the Manifesting Agility stage.
The session went well, around 36 people came and left 27 session reviews. Many people found value in the practical, down-to-earth approach of the workshop, leaving comments such as “excellent hands-on demo”, “extremely applicable information”, “finally something hands-on practical” and “very helpful”. Review averages were: Met expectations 4.4/5; Would recommend 4.3/5; Presentation skills 4.1/5; Command of topic 4.6/5; Matched description 4.4/5 and Overall 4.4/5.
I changed the format and structure of the session a little bit. First I gave a short presentation to introduce the topic. I was nervous and it showed… I’ll do better next time. We quickly moved on to starting the workshop itself. Each team was given a bag of office supplies and a blank taskboard. They set themselves up around a table.
The format of the workshop is simple: teams have to build taskboards, following some guidelines such as “the boards must show who is working on what”. The first round gave teams 20 minutes to figure out what they were going to do and how to implement it. Here is the red team getting busy:
The blue team had a good idea: they did a rapid prototype on a paper on the wall, and only after that started building their taskboard.
More taskboard building:
After a first round of taskboard building, people spread out to review other team’s boards.
Some stayed behind to present and defend their boards…
Finally, we did another round of taskboard improvement with new requirements, and another review session. To close, I presented my own version of the taskboard that I had built the night before in the hotel room.
Results
These are the final taskboards of all four participating teams, with comments. Click through to see a larger version of each taskboard. My comments are meant to show how each team approached a certain problem, the idea is to point out to the reader the different ideas that emerged.
Blue team
- They found and put up some team
pictures. They used them to assign a color to each member and used colors as nametags. The only problem with this is that with a larger team you will run out of colors.
- They created an “URGENT” swimlane for expedited work. It is clearly distinguishable with a different color tape and a header. It is at the bottom, but they said during the workshop that if they would have had more time, they would have refactored their taskboard and put it at the top. Very good solution.
- They used red stars to indicate all impediments. I’m not so sure I would use this, as stars connote something good to me. But you can certainly see impediments clearly.
- They re-wrote their story cards in big blue post-it’s; other teams simply stuck up the printed stories.
- They put columns for “QA” and “Done Today”. In the QA column there is a single small yellow post-it that says “BUG”.
No idea where the bug is though.
- Each story has tasks of a different color. There does not seem to be any significance to this other than visually pointing out that tasks belong to different stories.
Red Team
- They put their project backlog on the leftmost column. From there, they can “pull” stories into the Sprint backlog. When an urgent story came in, they placed it on top.
- They have a column “WIP Blocked” and next to it “WIP”. Another column is called “Done today”.
- They have a calendar that shows at what moment during the week they have Planning, Retrospective and Release. This allows me to see that they do 1-week iterations.
- They used different colored post-its to indicate different types of specialist work. This is a very good idea (where it makes sense). In the bottom right hand corner is the color legend.
- They did not use the red electrical tape to make their swimlanes, instead opting to go for a blue masking tape. This makes it harder to identify them as the red team.
Yellow team
- I like how this team kept their board “clean”, in comparison with other teams. Also, they put the most effort into making sure their swimlanes were tidy.
- They have only 3 columns, yellow post-its and few elements, keeping the board clean and uncluttered. It is much more relaxing to look at.
- They used red stars as nametags. Each star has the name of a team member written on it.
- They used small green post-its as “DONE” tags. They put their DONE tasks on the Complete column, so during the daily standup all they will do is remove the green tag I assume.
- They move finished stories to the 3rd column together with all the tags. For some reason, they finished the least priority story first. They seem to be working on everything at the same time.
- Pink post-its indicate a special situation is happening with that task.
Green team
- The first thing you notice is that this team opted for no horizontal swimlanes. This makes the board lighter and cleaner, but might cause confusion as to where tasks belong. To compensate, they gave each story different colored tasks as we saw the Blue team did before. This is an interesting design alternative to consider.
- Another original idea is the use of Post-it flags as status indicators with a clear legend on the lower right hand corner. Some examples include “defect found”, “retest”, “urgent” and “blocked”. This is the first time I see it and I want to say that it is an interesting idea. The Post-it flags are unobtrusive and easy to detach. I will add Post-it flags to the Elements of Taskboard Design page.
- They also have the Product backlog on the left-hand column and pull stories into their WIP backlog like the Red team.
Xavier’s board
For completeness, here is my board. The only new thing if you follow my blog is that I decided to use pink post-its instead of yellow post-its for normal tasks, simply for effect. But I didn’t find any value in it and actually the pink color is too noisy. So I will definitively stick to yellow (there are economic reasons for using yellow for tasks too – yellow super stickies are cheaper)
Conclusions
I want to thank all participants for coming to my session. I think the session was a success, and each team left me with new ideas and lessons learned.
- From the Blue Team, I learned I can create a priority swimlane which is visually clear.
- From the Red Team, I learned to use colors to indicate the nature of work. This could be used to visually identify the need for more specialists for example.
- From the Yellow Team, I learned the value of keeping it simple and clean. Overloading your board with elements and colors creates visual saturation and is tiresome to the sight.
- From the Green Team, I learned to use Post-it flags as status tags. They are small, elegant and unobtrusive.
I also wish to thank the following friends who helped me out: Mark Levison for all the advice before and during the conference, Karl Scotland for helping me during the session and for motivating me, Dan Mezick, stage producer, who came to visit during the session and seemed to really care about the quality of his stage; Tobias Mayer for always supporting me; and above all my sweetheart Joke Vandemaele without whom I would not be able to do any of this.
Thanks to you all!
PS: If you missed this session and would like to attend, I will be doing a short version of it at the Agile Eastern European Conference in Kiev next week. Registration for the conference is still open!
It will also be presented at Agiles 2009 in Florianópolis and at XP Days Benelux 2009. See you there!
Tags: agile 2009, chicago, Kanban, Scrum, Task boards
The flagship conference of the Agile community has come and gone. I had a great time and I’d like to post a short account of my trip with some pictures. I will later follow up with a post specifically on my Visual Management session.
We arrived with Joke a couple of days early in order to visit the city before the conference. Chicago is an amazing city with an incredible skyline full of modern buildings. I especially love that red one!
We got a room on the 30th floor with a great view. I particularly liked it by night.
We walked to the Millenium Park near the hotel where they have this really cool “thing”
Then we rented bicycles…
and biked around the park area. This fountain is one of the most beautiful I have ever seen!
Apparently Segways are not as unpopular as one would think; especially with tourists.
Segway invasion! They even have pink ones.
We then went to the aquarium. Joke wanted to see and hear a Beluga whale while she’s pregnant. She got what she wanted. This guy kept coming out of the water and I caught him smiling at us:
The Shedd Aquarium is really nice. I would recommend it even to people without kids.
Watcha staring at? Never seen an ugly fish?
Or a smart one? The legend says this guy knows TDD and refactoring…
They have the oldest fish in captivity in the world. This guy was brought into the aquarium in 1933! It’s a lungfish, an ancient beast that actually has lungs asides from gills.
But of course the cutest of them all are the little Nemos swimming in the coral reef:
The next day we went to visit the work of reknown american architect Frank Lloyd Wright in Oak Park.
And we did a tour in his old house and study. They didn’t allow pictures of the inside though 
Ok, enough about fish and architecture. On to the conference.
The conference
This was my second Agile 200x and my first time presenting. Considering the crisis this year, I think both the organizers and us (as in “the community”) did a pretty good job of keeping our flagship conference healthy. More than 1350 people passed by the registration desk in an orderly manner…
and enjoyed well delivered keynotes from Jared Spool and Alistair Cockburn
A couple of visual management good ideas. Every day the conference program was presented in these big panels (that I later used for my session )
And individual rooms had a sign outside announcing the day’s sessions:
The printed program was also much better organized than last year (it was actually usable!) and the badges were the same as last year, very readable and of the non-reversible type. They also had RFID as a novelty.
Open jam was the place to hang out if you were into networking or just wanted to sleep. And even though it never works well in ths type of conference, there were still a couple of good open space sessions.
What didn’t go well?
Well, the food was where the organization decided to cut corners in order to meet the budget, something I don’t approve of. And Programming with the Stars suffered from a lack of public, because of where the actual competition took place (extremely far from where the food was, compared to last year). Still, the sign was great!
Gordon Pask Award
07/Sep/2009 Update: This section is new, the original
post has been edited. I had expressed some pre-judgements regarding the award that I wish to retract. I have re-written this part how to save money on car repairs of the post based on feedback and information I received and researched. Let’s keep the award and the community healthy.
This year the first Gordon Pask Award was given to somewhat less prominent figures of the agile community (compared to previous years). As JB Rainsberger, member of the award commitee explains: “We awarded the Pask to Simon and Gus [...] as an attempt to live up better to the stated purpose of the award: to shine a light on those great practitioners in the field who have something special to share and need exposure to do exactly that.”
Congratulations to the “no compromise, no excuses” zealots Simon Baker and Gus Power from the UK! They sound like people with high quality standards, something I appreciate. You can read their reaction over winning the award in their blog.
The second award went to renown and groovy David Hussman, who BTW is coming to the Ágiles 2009 conference together with previous award winner Naresh Jain this fall. Congrats to David who certainly deserves it!
Let’s start betting on who gets it next year…
Agile Alliance Board
The big surprise of the conference for me was that Cesar Idrovo, with a spectacular political campaign, managed to get elected to the Agile Alliance board! Kudos to him and I hope he gets to do lots of good work there. I will certainly be supporting and helping him (Cesar is also Latin American / European like me). Also congratulations to Henrik Kniberg for getting elected.
All in all it was another great conference. Almost as good as Toronto last year. I met and re-met lots of friends and community leaders from around the world. There were some great sessions, and I think everybody was generally satisfied with the event.
See you in Nashville next year!
Tags: agile, agile 2009, chicago, conference, gordon pask, programming with the stars
Recently, Portia Tung was reviewing my session proposal on Visual Management (with Laurent Morisseau) to the XP Days Benelux 2009
conference. She commented that it would be nice if I could give some scientific background for all this Visual Management and taskboard stuff that I write about. Since half my family and many of my friends are scientists, this is a challenge too tempting to pass. The only thing I ask of Portia is to understand that this is not something I can put together in a
couple of weeks! I will try to (slowly) start adding some scientific theory behind these writings. Iteratively and incrementally, starting today.
By coincidence, last week my friend Ariel Aizemberg sent me a TED Talk video that is spot on the topic and makes a good starting point. This video is short (6 minutes), informative and entertaining. Even if you don’t care about science too much, you will surely enjoy the presentation style.
Tags: science, video, Visual management
In Scrum, the “Scrum of Scrums” is a way to ensure alignment and coordination across different teams, or among different sub-teams of a large Team.
How big is the Team?
A Team is a group of people collaborating towards a common goal. Sometimes it’s not that easy to pick your goal, and thus figure out who the Team is, or who it should be. On one hand, small teams are good. Small is simple, small is beautiful. So maybe you should pick a small goal, and make a small Team.
On the other hand, you should try to look at the system as a whole. This could mean anything: a project, a department, the whole company… What is the ultimate system, but the Organization itself?
Your whole company is the Team, from the Systems Thinking perspective. Especially for small companies. So maybe you should think of a large Team.
Most likely, we need to strike a balance between these two dichotomic approaches.
I have found my comfort zone with a simple, practical definition: One Team, One Backlog.
Splitting it up
Let’s assume you found your definition of Team, and you have more than ten people in it. Since the ideal team size is 5 to 9, you probably want to split them up. But you don’t want to lose the concept of one Team. The recommended approach is to break them up into sub-teams. I will discuss some ideas for creating these sub-teams and for visualizing their work, while trying to keep and respect the spirit and vision of the one (big) Team.
Feature teams
Using the same logic regarding why it is interesting for team members to be as cross-functional as possible, the best strategy for making sub-teams is to create cross-functional feature teams, as opposed to ‘component’ teams or -god forbid- teams that specialize in a certain technology or skill (like ‘QA team’ or ‘.Net team’).
Feature teams are teams that work on features, i.e. stories. Pieces of business value. They are value-driven teams, whereas other sub-team splitting strategies (component, skill, etc) create function-driven teams that invariably fail to deliver business value and create local optimizations and waste.
You create your feature teams by spreading out the knowledge, skills and experience equally. The goal is that any team can do any story in the backlog. You should
stress that the “real” Team is the big one. Sub-teams are just created for communication and coordination purposes. In my opinion, they should not develop too strong a team identity. For example, I would not measure sub-team velocity, and I would make sure people rotate from sub-team to sub-team a lot.
You can then work with a single, large backlog and distribute stories in round-robin fashion.
Colored teams
I like to give sub-teams a color for a name. E.g “Red team”, “Blue team”, etc. Colors are very visual and we will be able to use this to our advantage. For example I use electric tape of the same color to create their taskboard, which gives them an immediate strong visual identity (see picture below). Another reason colors are good is that they are non-hierarchical, and people don’t attach themselves that much to a color.
The Black team
In large projects, particularly in transitioning organizations, there are always some people left floating around that are not doing any actual work at team/trenches level. I put them in the Black team. This is a pseudo-management team that mostly combines the responsibilities of Product Owner and Scrum Master (in the same team, not the same person!) and any other role that you either want to share across teams or that you simply can’t get rid of.
Typical examples of people who we have put in the Black team include:
- all the ex-Project Managers, who now had to remove impediments full-time (they also had a lot of administrative work to do: fake Gantt charts, fill in timesheets, useless reports, etc)
- the Agile Coach
- the Product Owner(s)
- an Architect from Architecture (we later convinced him to move into the trenches with the real teams)
- a QA Team Lead who didn’t want to test (we later got rid of him, once the testers he used to C&C were doing agile testing)
- a Release Coordinator, whose job was to beg to Infrastructure to deploy our app into production (this was a full time job)
- etc.
As you can see these were mostly roles that existed because we were doing Scrum within a traditional large organization. In any case, the idea is to group all these people into one “team” so as to not leave any loose ends. Ideally they will jell and work cooperatively, otherwise at least you can visualize their work by putting up a taskboard for them. For example on this picture below, most tasks are either impediments or things that have to be delegated to people outside of the Team. The horizontal lines are not stories but simply priority slots, i.e. High Priority, Medium and Low. If I would have known at the time, I would have put WIP limits, because nothing was ever getting done here. 
The Scrum of Scrums
Ok, let’s move on to the interesting part. Each sub-team has their scrumboard with the stories they have selected for the current Sprint, divided into tasks as usual. How do we visualize what is going on at Big Team level? How do we keep track of so much work? We need to change the level of granularity. In the Scrum of Scrums, you only visualize stories. You create the “Scrum of Scrums storyboard” where every story that is currently open is visualized, with the team that has it and the current status indicated. The picture below shows such a board at the beginning of a Sprint. Click on the picture for a larger version. Note: This is actually the same physical whiteboard as pictured above… you are just looking at the other side! The Scrum of Scrums side is pointing towards the hallway, so passer-bys can look at it.
There are only two columns: “Story” and “Status”. Story has a copy of the story card that is on the team board. Status is normally “not started, “in progress”, “done” or “done-done” (a curious distinction between “we think we’re done” and “we’re sure we’re done”). This last done-done was indicated with a red star. Each story has a little magnet indicating which team is working on it, but we also experimented with other visual elements like creating status tags of the color of the team. In this example you see both at the same time: a Green Team story will have a green “in progress” tag, and also a green magnet.
The mechanics for the Scrum of Scrums are simple: after the daily Scrums, each team sends a rotating delegate to give a brief status report on each of their open stories to the other delegates and the Product Owner. The delegate is then responsible for updating the rest of his sub-team members on what’s going on at project level (something that never happens, but oh well). Of course sometimes a lot more people show up during the Scrum of Scrums. Anybody who is interested in knowing what’s going on at Big Team level goes.
Note: The black and blue tape indicate nothing in this case, we simply didn’t have enough tape of the same color, and our boss was a fan of Club Brugge (whose colors are black & blue), so we made it for him.
This is how the board might look like towards the end of the Sprint, on a good Sprint where lots of stuff got done. (Click for large version)
Note how you can quickly visualize different types of problems.
- Several top priority stories are not getting finished. In particular the #1 top priority story.
- The yellow team seems to be in trouble. I see 3 yellow “in progress” and only red star with yellow magnet. Also comparing yellow to green, red and blue you can see the difference.
If you looked at the large version of the picture, you probably noticed those white horizontal lines that say for example “End of Sprint 9 Demo: 8/Sep”. This is a visual way of indicating what was the scope taken for Sprint 9. The point here is that this was a Team that was not delivering all they started, and was dragging along open stories. Some stories were blocked, others underestimated, some teams had sick people… for whatever the reason work wasn’t getting finished, and since it was not possible to limit WIP for political reasons, we just let the teams take more work, keeping existing stories open. But with this board at least the situation was kept clearly visible and the Product Owner knew perfectly well what was going on.
A last picture with some comments, in a style similar to my original “Scrum Board with Comments” picture:
Tags: agile, elements, Kanban, Scrum, Scrumboard, Task boards
Recent Comments