The book Toolbox for the Agile Coach - Visualization Examples by Jimmy Janlén can be used by agile software development teams to visualize and improve their collaboration and communication.
InfoQ interviewed Janlén about what made him decide to write a book with visualization examples, the strengths of visualizations and how teams can use them to track progress and deal with blockers, using visualization to celebrate successes and to find ways to improve, the traps and pitfalls of visualization, and where to find more information about visualization.
InfoQ: What made you decide to create a book with visualization examples?
Jimmy Janlén: Several reasons. When coaching teams I’m constantly amazed how strong of an impact good and useful visualization has on teams’ ability to collaborate and find creative ways to improve. Wherever I visit companies, I always carry my pocket camera with me to be able to take photographs of interesting whiteboards. I’ve build up quite a collection so far, and it’s still growing. I knew I would find a good use for them someday. When teaching and giving seminars, the things people seem to connect best with, and remember best, are the concrete examples of how abstract agile concepts can manifest themselves physically in the shape of post-its on a whiteboard. All of the above became thoughts brewing in the back of my mind until early 2015 when the idea surfaced to my conscious brain; to write a book about visualization and share my collection beyond the teams I’m working with to a wider audience. And I’ve always loved to draw. This gave me the perfect excuse to draw even more.
Once I had figured out the format, the book almost wrote itself. The list of examples to include just grew and grew. The printed version contains 96 examples, but I think the list contained more than 130 items last time I looked. I needed to draw the line somewhere. Who knows, maybe there will be a new version in a year or two called 166 Visualization Examples.
I decided very early on to write the book publicly online in order to get faster feedback. I created a public google drive document. Up until August 2015 people were able to read the book as I wrote it, page by page. I got tons of valuable feedback in the shape of grammar corrections and more suggestions of examples to include. At any given point there were between ten to forty people reading the book. I will definitely write the next book the same way.
InfoQ: Can you mention some of the strengths of visualization?
Janlén: The act of creating the visualization in itself is immensely valuable. When done collaboratively as a team, the exercise of visualizing the process onto a whiteboard invites great discussions. How should the process be visualized? What is our process? Where does it start? Where does it end? How do we visualize work? What are the criteria for moving post-its? How do we balance different kind of work? Long term? Short term? Chores? Urgencies? You will discover that members’ assumptions on how work should be done varies greatly, and the discussion will surface a lot of differences in opinions. The discussion, and the resulting visualization, creates a common view and shared understanding within the team that strengthens their ability to collaborate and to hold each other accountable for honouring agreed upon policies and rules.
The first version won't be perfect (well it will actually never be perfect), but if given love and care, and if continuously evaluated and improved, it will grow into a valuable and useful tool for the team.
A great visualization is one that…
- Provides an overview of ongoing and upcoming work
- Describes how work is done, i.e. how work flows from idea to done
- Helps the team to focus and collaborate on work in order to reach goals
- Reveals bottlenecks and dependencies
- Surfaces improvement opportunities
- Provides transparency to other teams and the wider organization
But the core purpose of a visualization in my view, is to shape behaviors. Even though it actually only boils down to lines, text and post-its on a whiteboard, those lines and post-its encapsulates behavioral expectations between team members. Teams tend to emphasize aspects of their working agreements that they want to get better at honoring, to turn into habits. For example: A team that wants to encourage pairing and collaboration might greatly reduce the number of lanes (i.e. develop fewer user stories at a time). A team that wants to be better at helping out if someone gets stuck might start putting a dot on post-its for each day that task is in doing (to reveal how long it's been “stuck”). A team that wants to be better at knowledge sharing done work might add a column “Internal technical demo” before the “Done” column.
InfoQ: Do you have some examples of how teams can use visualization to track their progress and to see what is blocking them?
Janlén: One of the overarching purpose of a visualization is to show planned work, and progress of ongoing work. The simple approach of having one lane per user story, and tasks related to that story on the same lane, reveals an overview of how the team is doing with regards to their sprint goals. But many teams decide to enhance the visualization of progress.
For example:
- Confidence smileys - Instead of having a sprint burndown, the team votes daily on how confident they are that they will be able to finish each user story on the board within the sprint. They either place a green confident smiley, yellow nervous smiley or a red unhappy smiley next to the user story. When the smiley for example changes from a confident green to a nervous yellow, the team discusses how they can help out, or if they need to alert product owner and stakeholders about changes in the forecast.
- Sprint goal progress bars - Next to the sprint goal (or goals), usually captured in text at the top of the whiteboard, draw a progress bar ranging from 0% to 100%. Each day, the team fills in the progress bar to reflecting their sense of overall progress towards completion of that goal.
- Release confidence - Many times teams find themselves working towards a fixed deadline in time for a specific release of deliverable. As a compliment to a release burnup (or release burndown) some teams do weekly confidence votes on the likelihood of them making the deadline. Each member votes with their fingers, 5 fingers signals total confidence, 1 finger means “no way, we won’t make it”. The average is captured in a table and visualized in a graph.
Confidence Smileys
Techniques for spotting blockers and impediments:
- Dotting - Every day, at the start of the daily meeting, dot each post-it in the “Doing” column with a marker. This will quickly reveal if a task is stuck, if someone needs help or if the task was more complicated than first expected.
- Blocked note - When progress of a task is blocked, add a red note to it that explicitly describes why it is blocked and what needs to happen for it to become unblocked. Write the date of when it became blocked. Discuss what you as a team can do today to remove the blocker, every day until the impediment has been resolved.
- Paused note - Sometimes a person working on a task needs to change focus to something of higher importance. When that happens mark the task as paused, along with a comment on how was working on it and a short description of why it is currently being paused. When anyone finishes their task, they first search the board for paused tasks they could resume before starting work on a new task.
- Blocker culprits - When a blocker has been resolved, move the red blocker post-it to a special area of the whiteboard. Group the blockers into categories. When there are 10 or more post-its, analyse the root causes and make plans for resolving the root so that less work get stuck in the future.
These are just some examples. I have included tons more in the book.
InfoQ: Are there ways to use visualization for teams to celebrate their successes? And to reward behavior from team members that helps the team to be successful?
Janlén: I’ve stumbled across many interesting ways teams celebrate success. These are two favorites:
- Release Credits - One team I was working with created a poster after each sprint, listing and crediting the team members. Each poster depicted a space mission. The poster was framed and hung on a wall in the team area.
- Achievement Posters - Many teams I’ve met create a poster at the sprint review, capturing the achievements they felt they accomplished. The prouder they were, the bigger the post-it. Some teams have used different colors as well. One color for features, one color for team events, one color for process improvements, one color for technical infrastructure improvement, and so on. Within 10 minutes a full sized poster is usually filled and a great sense of pride is celebrated with applause.
- When it comes to rewarding behaviors, these are my favorites:
- Reward Jar - Get a glass jar and lots of marbles. Team agrees upon a scoring chart. For example: Pairing for 3 hours - 1 marble, Retrospective action done - 2 marbles, Mob programming day - 5 marbles, Urgent lane emptied - 2 marbles. When the jar is full (or reaches a certain level), reward ourselves as a team with a treat or a joint dinner.
- Race Track - Instead of punishing late-comers to the Daily Stand-up, why not reward those that are on time by allowing them to move their figure one step forward on a race track? The person that has come the furthest on the race track by the end of the sprint wins applause and a group hug.
- Discipline high score - Example: Every day you manage to start the daily meeting on time, draw a tick. If you fail to start on time, restart the counter from zero. Next to the counter, keep track of your high score so far.
Reward Jar
InfoQ: Any suggestions on how visualizations can support retrospectives and help teams to improve?
Janlén: When it comes to supporting retrospectives, I see two aspects to it. One is providing input to the retrospective itself, the other one is supporting the team to follow up the decisions and outcome from the retrospective.
To gather input, why not try one of the following:
- Retro input inbox - As soon as something happens or when a thought pops into your mind, capture it, write it down and put it in the “Retro Input Inbox” area of the whiteboard. When it is time for the retrospective, simply bring all the Post-its from the area.
- Interruption buckets - Do you suspect that most of your interruptions have a common origin and source? To turn that frustration into a data driven insight and data driven decision to change something, collect your interruptions on Post-its and sort them according to category. When there is five or more notes in any given category invite the relevant people to a workshop to discuss how things could be improved.
- When it comes to transforming decisions from the retrospective to real change, I would recommend to try these techniques:
- Kaizen board - A super simple kanban board of two columns, Todo and Done. Here you capture the actions decided upon from the retrospective. Some teams have a dedicated lane instead of a separate board. Walk the Kaizen board as a normal step in your daily meeting routine.
- Team Habits - Not all output from a retrospective is in the shape of an actionable piece of work, more often it’s a decision to change some policy or adhere to a new value. Write down the agreement on an orange post it and put it in the Team Habits square. When you’ve managed to convert the agreement into a habit that you don’t need to remind each other of, rewrite it on a green post-it. The Team Habits board is typically reviewed as part of the retrospective.
- Discipline track record - Some new habits are harder than others to adopt. To raise awareness of the agreement keep a daily track record of it. Print out a calendar. During the daily meeting, ask yourselves, did we honor the agreement yesterday? If yes, draw a green circle. If you broke the agreement or cheated, draw a red cross. If you managed to get ten green circles in a row, you discuss if you want to continue tracking you discipline of honoring the agreement, or if you want to burn the piece of paper in a celebration ceremony.
InfoQ: Can you elaborate about the traps and pitfalls of visualization? How can you deal with them?
Janlén: One pitfall new Scrum Masters often walk right into is failing to include the whole team in creation of the teams Scrum or Kanban wall. If you as a team member weren't invited to design the wall you will feel less (if any) ownership of the visualization. You won’t connect emotionally to it, you might not understand the different aspects of it, and the chance that you won't care to update it increases. See to it that you create and make changes to it collaboratively, together.
I’ve also seen some teams go bananas, creating extensive and complicated visualizations that are cumbersome to update. If it’s too time consuming to maintain the wall you risk that people will refrain from updating it. And once you start suspecting it’s not up to date, you will update it even less. Eventually you will stop trusting that the wall depicts reality and abandon it all together. Keep it as simple as possible. Focus on the important behaviors you want to honor. Continuously clean the wall and remove aspects that no longer provide value.
Always ensure that the wall is highly visible and positioned close to the team where everyone can see it. I’ve seen teams having whiteboards in a separate room. These become obsolete very fast and provide little value for the team. The effort to walk up to the wall for a conversation needs to be minimal.
Digital tools are great, but can never replace the power of a physical representation. With a digital tool you can add attachments, screenshots, comments and tons of other details that don’t fit on a post-it. Digital tools can produce reports and graphs. But I’ve yet to find a digital tool that can provide the same overview as a whiteboard, one that invites to conversation the way post-its do. If you are using a digital tool, spend time creating a wall that provides a meaningful overview, and that visualizes your process and working agreements. Don’t just duplicate the digital content to post-its.
Each element of a visualization emerges from a specific need. If a portion of your wall doesn’t feel as if it adds value any longer, perhaps it has served its purpose. Perhaps the behavior you wanted to change has become a habit. Don’t be afraid to remove, add and change you wall. As your problems and behaviors change, so should your visualization.
InfoQ: If InfoQ readers want to learn more about visualization, where can they go?
Janlén: I’ve created an accompanying website for the book. Here I will add more examples that didn’t make it to the book. I also share pictures of visualizations from other people than me. There are also some book suggestions. If you want to, you can like the facebook page. Here I publish news related to the book, and my intent is to share good articles and blogs on visualization in general. My book can be bought on LeanPub, and if everything goes as planned it should be available on Amazon by the time you read this.
One of the few blogs that cover physical visualization is Xavier Quesada Allue’s Visual Management Blog. Lots of great articles, photos and examples on visualization.
I know there are tons more visualizations out there, waiting to be shared. If you have a photo and description of your visualization, please leave a comment and link here so that I and others can enjoy it and be inspired.
About the Authors
Jimmy Janlén (@JimmyJanlen) is currently a member of Nomad8, a boutique consultancy based in New Zealand. He has been working as an agile coach for many years and is an experienced trainer and conference speaker. Before moving to New Zealand he was a member of the Stockholm based consultancy Crisp. Recently he has worked as an agile coach with companies such as Spotify (Stockholm) and Plain Vanilla/QuizUp (Reykjavik). Currently Jimmy is helping Westpac (Auckland) on their courageous agile journey as an agile enterprise coach.