PEARL XIII: Effective Visual Management with Information Radiators

PEARL XIII: 

Effective visual management with Information Radiators

Information Radiators

Information Radiators, also known as Big Visible Charts, are useful quite simply because they provide an effective way to communicate project status, issues, or metrics without a great deal of effort from the team. The premise is that these displays make critical, changing information about a project accessible to anyone with enough ambition to walk over to the team area and take a look.

“An Information radiator is a display posted in a place where people can see it as they work or walk by. It shows readers information they care about without having to ask anyone a question. This means more communication with fewer interruptions.”

Information Radiators are

• Is large and easily visible to the casual, interested observer
• Is understood at a glance
• Changes periodically, so that it is worth visiting
• Is easily kept up to date

“Information Radiator” is a popular term invented by Alistair Cockburn that is used to describe any artifact that conveys project information and is publicly displayed in the workspace or surroundings. Information radiators are very popular in the Agile world, and they are an essential component of visual management. Most Agile teams recognize the value of information radiators and implement them to some degree in their processes.

Information radiators take on many different shapes and sizes. Traditional implementations range from hand-drawn posters of burndown charts to coloured sticky notes on a whiteboard.

Many development teams create elaborate information radiators using electronic devices like traffic lights or glowing orbs to indicate build status. Most teams, including many at Atlassian, roll their own electronic wallboards to pull real-time data from development tools for display on large monitors over the team workspace.

Visual control is a business management technique employed in many places where information is communicated by using visual signals instead of texts or other written instructions. The design is deliberate in allowing quick recognition of the information being communicated, in order to increase efficiency and clarity. These signals can be of many forms, from different coloured clothing for different teams, to focusing measures upon the size of the problem and not the size of the activity, tokanban, obeya and heijunka boxes and many other diverse examples. In The Toyota Way, it is also known as mieruka.

The three most popular information radiators are

• Task Boards,
• Big Visible Charts (which includes burn downs and family) and
• Continuous Integration build health indicators (including lava lamps and stolen street lights).

Task Boards

MockedTaskBoard

The most important information radiator in visual management is the Task Board. (In Scrum, Agilists sometimes call task boards as Scrum boards). The task board has the mission of visually representing the work that is being done by the team. They are the most complex and versatile artifact: a physical task board is a “living” entity that has to be manually maintained. Tasks boards are being undervalued by most agile teams today. This might be because there has not been a lot of focus on their potential, or perhaps there are simply not many examples around on what makes a great task board. In any case, it’s time to take task boards to the next level.

In its most basic form, a task board can be drawn on a whiteboard or even a section of wall. Using electrical tape or a dry erase pen, the board is divided into three columns labeled “To Do”, “In Progress” and “Done”. Sticky notes or index cards, one for each task the team is working on, are placed in the columns reflecting the current status of the tasks.

Many variants exist. Different layouts can be used, for instance by rows instead of columns (although the latter is much more common). The number and headings of the columns can vary, further columns are often used for instance to represent an activity, such as “In Test”.

The task board is updated frequently, most commonly during the daily meeting, based on the team’s progress since the last update. The board is commonly “reset” at the beginning of each iteration to reflect the iteration plan.

Expected Benefits

• The task board is an “information radiator” – it ensures efficient diffusion of informations relevant to the whole team
• The task board serves as a focal point for the daily meeting, keeping it focused on progress and obstacles
• The simplicity and flexibility of the task board and its elementary materials (sticky notes, sticky dots etc.) allow the team to represent any relevant information: colors can be used to distinguish features from bug fixes, sticky orientation can be used to convey special cases such as blocked tasks, sticky dots can be used to record the number of days a task spends “In Progress”…

Common Pitfalls

• Many teams new to Agile rush to adopt an electronic simulation (“virtual task board”) without first getting significant experience with a physical task board, even though virtual boards are much less flexible and poorer in affordances
• Even geographically distributed teams for whom a virtual task board is a necessity can benefit from using physical task boards locally and replicating the information in an electronic tool

Origins

Sticky notes or index cards had been used for visual management of project scheduling well before Scrum and Extreme Programming brought these “low tech” approaches and their benefits back into the spotlight. However, the precise format of the task board described here did not become a de facto standard until the mid-2000’s.

• 2003: the five-column task board format is described by Mike Cohn on his Web site; at the time, as this photo gallery collected by Bill Wake shows, very diverse variants still abound
• 2007: the simplified three-column task board format (“To Do”, “In Progress”, “Done”) becomes, around that time, more popular and more standard than the original five-column version

What makes a great Task Board
A good task board should be carefully designed with readability and usability in mind, and the project methodology should actively rely on it. This implies that the use of the task board should be standardized and form part of the process. If task boards (and other information radiators) are not an integral part of the project methodology, maintaining them might be perceived as overhead or duplication of work. This results in boards not being updated and becoming out of sync with the work actually being done. An incomplete or stale task board is worthless.

A task board is a living entity and should be kept healthy.

You have a great task board if…

• Team members never complain about having to use it.
• The daily standup happens against it.
• Random people that pass by stop to look at it, expressing interest and curiosity.
• Your boss has proudly shown it to his boss.
• You see team members updating it regularly during the day.
• It passes the hallway usability test: a person who has never seen it before can understand it quickly and without explanations.
• You catch a senior manager walking the floor and looking at it.
• It just looks great!

Information Radiators are useful quite simply because they provide an effective way to communicate project status, issues, or metrics without a great deal of effort from the team. The premise is that these displays make critical, changing information about a project accessible to anyone with enough ambition to walk over to the team area and take a look.
Information Radiators are also good ways to remind the team of critical items, such as issues that need to be addressed, items on which the team is currently working, key models for the system on which they are working, and the status of testing.
Depending on the type of information tracked on the Information Radiators, these displays can also help the team to identify problems early. This is especially true if the team is tracking key metrics about their performance where trends in the information will indicate something is out of whack for the team. This type of information includes passing and failing tests, completed functionality, and task progress.

Using Information Radiators

As a team, determine what information would be very helpful to see plastered on a wall in plain sight. The need for an Information Radiator may be identified at the very beginning of a project, or as a result of feedback generated during a retrospective. Ideally, it will communicate information that needs to go to a broad audience, changes on a regular basis, and is relevant for the team.
Decide not only what you want to show, but the best way to convey it. There are a variety of methods to choose from, including a whiteboard and markers, sticky notes, pins, dots, or a combination of all of the above. Anything goes, as long as it is not dependent on a computer and some fancy graphics software. Unless of course you are working with a distributed team; see suggestions for that situation below.
Grab the necessary tools and get to work, but don’t forget to have a little fun with the creation process. Remember to make the Information Radiator easy to read, understand, and update. You want this to be a useful, living display of information, so don’t paint yourself into a corner at the beginning.
Remember to update the information radiator when the information changes. If you are using it to track tasks, you may change it several times a day. If you are using it to track delivery of features, it may be updated once a week or every two weeks.
Check in with the team regularly to find out if the Information Radiator is up to date and still useful. Find out if people outside the team are using it to gather information about the team’s progress without causing an interruption. Find out if there are possible improvements, or if the information radiator is no longer needed. Whatever feedback you receive, act on it.

Traffic lights , lava lamps

Information radiators can take a variety of forms, from wallboards to lava lamps and traffic lights.

A wallboard is a type of information radiator that displays vital data about the progress of the development team. Similar to a scoreboard at a sporting event, wallboards are large, highly visible and easy to understand for anyone walking by.

Traditional wallboards are made of paper or use sticky notes on a wall. Electronic wallboards are very effective since they update automatically with real-time data ensuring that people check back regularly.

Common information radiators used in Scrum environment includes

• Product Vision
• Product Backlog/release plan
• Iteration Backlog
• Burn Down and Burn Up charts
• Impediment List

In lean environment , information radiators are of specialized type which is called as Visual Control . In lean environment, visual controls are used to make it easier to control an activity or process through a variety of visual signals or cues.

The visual control:

• Conveys its information visually 
• Mirrors (at least some part of) the process being used by the team
• Describes the state of the work‐in‐process
• Is used to control the work‐in‐process
• Can be viewed by anyone

Visual controls should be present at all levels: business, management, and team. That is, they should help the business see how value is being created as well as assist management and the team in building software as effectively and efficiently as possible.
The visual controls used in Lean‐Agile include

• Product Vision : Every Agile team should have a product vision. This provides the big picture for the product: what is motivating the development effort, what the current objectives are, and the key  features. We have seen teams who were flailing about, trying to figure out what they were  supposed to be doing, suddenly gain focus when the  Product Champion produced a product vision statement
• Product Backlog / Release Plan / Lean Portfolio
• Iteration Backlog – simple team, multiple teams
• Story Point Burn‐Up Chart
• Iteration Burn‐Down Chart
• Business Value Delivered Chart
• Impediment List

A backlog is the accumulation of work that has to be done over time. In Lean‐Agile, the product backlog describes that part of the product that is still to be developed. Before the first iteration, it shows every piece of information that is known about the product at that time, represented in terms of features and stories. As each iteration begins, some of these stories move from the product backlog to the iteration backlog. At the end of each iteration, the completed features move off of both backlogs.
During “Iteration 0,” the features in the product backlog are organized to reflect the priorities of the business: higher‐priority features on the left and lower‐priority features on the right.

 

The entire enterprise (business, management, and development teams) also need line of sight to velocity (points/time), which, after the first few stories are done, should begin to represent the velocity of business solutions delivered. This is a clear representation of the value stream (from flow of ideas to completed work) and is mapped to the number of points that teams can sustainably deliver in a release.

We can use two visual controls working as a pair to give management a dashboard‐type view of work . The release burn‐up chart tracks cumulative points delivered with each iteration. This can be broken out or rolled up based on program, stakeholder, and so on. The feature burn‐up chart is created by using the initial high‐level estimate to calculate the percent complete after each iteration and plotting this with all features currently identified in the release plan.
This view gives the enterprise a clear visual control of current priorities, along with what work is actually in process. A Lean enterprise continuously watches out for too many features being worked on at any time—this indicates process problems and potential thrashing.

The Impediment List :  A foundation of both Scrum and Lean‐Agile is that continuous improvement includes continually removing impediments. One of the purposes of the daily meeting is to expose impediments, to make them explicit. The Scrum Master or Agile project manager must maintain a list of current impediments so that progress on resolving them can be visible to all. Entries on this list should include:

• Date entered on list
• Description of impediment
• Severity of impediment (what its impact is)
• Who it affects
• Actions being taken to remove it

The impediment list should be maintained on an ongoing basis as impediments are removed, added, or modified in some way.

Kanban Board

In the context of Agile teams where the “Kanban method” of continuous improvement (or some of its concepts) has been followed, the following adaptations are often seen:

• Such teams deemphasize the use of iterations, effort estimates and velocity as a primary measure of progress;
• They rely on measures of lead time or cycle time instead of velocity; and in the most visible alteration, they replace the task board with a “kanban board”:
• Unlike a task board, the kanban board is not “reset” at the beginning of each iteration, its columns represent the different processing states of a “unit of value”, which is generally (but not necessarily) equated with a user story.
• In addition, each column may have associated with it a “WIP limit” (for “work in process” or “work in progress”): if a given state, for instance “in manual testing”, has a WIP limit of, say, 2, then the team “may not” start testing a third user story if two are already being worked on.
• Whenever such a situation arises, the priority is to clear current work-in-process, and team members will “swarm” to help those working on the activity that’s blocking flow

Also Known As

The term “kanban” is Japanese  with the sense of a sign, poster or billboard, and derived from roots which literally translate as “visual board”.

Its meaning within the Agile context is borrowed from the Toyota Production System, where it designates a system to control the inventory levels of various parts. It is analogous to (and in fact inspired by) cards placed behind products on supermarket shelves to signal “out of stock” items and trigger a resupply “just in time”.

The Toyota system affords a precise accounting of inventory or “work in process”, and strives for a reduction of inventory levels, considered wasteful and harmful to performance.

The phrase “Kanban method” also refers to an approach to continuous improvement which relies on visualizing the current system of work scheduling, managing “flow” as the primary measure of performance, and whole-system optimization – as a process improvement approach, it does not prescribe any particular practices.

Common Pitfalls

Kanban boards are generally more sophisticated than “mere” task boards. This is not a mistake in and of itself; however, it is not advisable that the kanban board should serve as a pretext to reintroduce a “waterfall”-like, linear sequence of activities structuring the process of software development. This may lead to the creation of information silos or over-specialization among team members.

In particular, teams should be wary of kanban boards not accompanied by WIP limits, not only defined but also enforced with respect to demands from managers, customers or other stakehoders. It is from these limits that the kanban approach derives its effectiveness.

Expected Benefits

In some contexts, measuring lead time rather than velocity, and dispensing with the regular rhythm of iterations, may be the more appropriate choice: for instance, when there is little concern with achieving a specific release date, or when the team’s work is by nature continuous and ongoing, such as enhancement or maintenance, in particular of more than one product.

At the risk of oversimplifying, a “kanban board” setup can be considered first for efforts involving maintenance or ongoing evolution, whereas a “task board” setup may be a more natural first choice in efforts described as “projects”.

Origins

• 2001: Mary Poppendieck’s article, “Lean Programming”, draws attention to the structural parallels between Agile and the ideas known as Lean or the “Toyota Production System”
• 2003: expanding on their earlier work on Lean Programming, Mary and Tom Poppendieck’s book “Lean Software Development” describes the Agile task board as a “software kanban system”
• 2007: the first few experience reports from teams using the specific set of alterations known as “kanban” (no iterations, no estimates, continuous task boards with WIP limits) are published, including reports from Corbis (David Anderson) and BueTech (Arlo Belshee)
• 2007: the “kanbandev” mailing list is formed to provide a venue for discussion of kanban-inspired Agile planning practices
• 2009: two entities dedicated to exploring the kanban approach are formed, one addressing business concerns, the LSSC and a more informal one aimed at giving the community more visibility: the Limited WIP Society

Flow of Work

After visualizing the work, you will be able to watch how it moves across the board. Kanban teams call this observing the Flow of Work. When there are bottlenecks in the process, or blocking issues that prevent work from being completed, you start to see it play out on the board.

Stop Starting and Start Finishing!

Kanban’s primary mechanism for improving the flow of work is the Work-in-Process Limit. You basically set a policy for the team, saying that we’ll limit how much work is started, but not finished, at any one time. When the board starts to fill up with too much unfinished work, team members re-direct their attention and collaborate to help get some of the work finally finished, before starting any more new work.

On a Kanban board, you visualize the flow of work. You can visualize how the work is flowing during the sprint through the very fast iterations of design, develop, and test that happen within each sprint.  Or, you can let the flow of work be governed by the kanban board and replace the sprint container with a regular deployment cadence instead. It’s a minor difference on the surface, but it can have a major impact.

With the sprint approach, you spend time at the beginning of every sprint trying to estimate and plan a batch of work for the entire sprint. Then you work on it and push hard to have the entire batch completed, tested and deployed by the end of the sprint.

When you’re focusing on flow and using Kanban, you could still deploy completed code every two weeks. But instead of going through the whole cycle of planning, estimating and moving a batch of work through to completion, you can move work through the system without batching two weeks of work at a time. Planning and estimating, designing, building and testing can happen for each individual item as it reaches the top of the priority list in the backlog. When there’s capacity on the Kanban board for more work (WIP limits are being honored, and people are available to do more work), they pull the next item to work on. When the two-week cadence comes around, you simply deliver whatever is ready to deliver.  This encourages members of the team to take each item all the way through to completion individually, instead of focusing on having a two-week batch of work completed at one time. You ensure that each item is Done. With a capital D. “Done-Done”, some people call it. And you get it to “Done-Done” before pulling the next item available for you to work on.

The Agile practice of iterative delivery is a huge improvement over old waterfall or stage-gate project management methods. Focusing on Flow using Kanban can sometimes be even more efficient, resulting in shorter lead times and higher productivity. It can lessen the feeling of always “starting and stopping” without abandoning the value of having a regular cadence to work toward.

Parking Lot Chart

“Parking Lot Chart” is used to provide a top-level digested summary of project status (not to be confused with a “Parking Lot List,” a tool facilitators use to capture unresolved issues). It is first described in Feature Driven Development (FDD) [Palmer02], and is widely used in agile projects today. It is sometimes also called a “Project Dashboard”.

Niko-niko Calendar

The team installs a calendar one one of the room’s walls. The format of the calendar allows each team member to record, at the end of every workday, a graphic evaluation of their mood during that day. This can be either a hand-drawn “emoticon”, or a colored sticker, following a simple color code, for instance: blue for a bad day, red for neutral, yellow for a good day.

Over time, the niko-niko calendar reveals patterns of change in the moods of the team, or of individual members.

Also Known As

The Japanese word “niko” means “smile”; following a common pattern of word doubling in Japanese, “niko-niko” has a meaning closer to “smiley”.

The term “mood board” is also seen. It is an information radiator.

Expected Benefits

The value of this practice lies in making somewhat objective an important element of team performance – motivation or well-being – which is generally seen as entirely subjective and thus impossible to measure and track.

This may be seen as an illustration of the Gilb Measurability Principle: “anything you need to quantify can be measured in some way that is superior to not measuring it at all.”

In other words, a measurement does not have to be perfect or even very precise, as long as your intent is to get a quantitative handle on something that was previously purely qualitative; the important thing is to take that first step toward quantifying.

Common Pitfalls

As with other activities, such as retrospectives, where team members are asked to report subjective feelings, self-censorship is always a risk. This could be the case, for instance, if team members who report poor days are blamed for “whining”, by management or by team mates.

Origins

• 2001: among the visualizations described in Norm Kerth’s “Project Retrospectives”, the “Energy Seismograph” can perhaps be seen as a forerunner of the niko-niko calendar
• 2006: niko-niko calendars are first described by Akinori Sakata in this Web article