✥ ✥ ✥
Without a frame of reference you can unknowingly drift.
Our current goals strongly influence our behaviors, such as where we turn our attention. ,  Focus and direction can limit our attention as shown in a well-known video experiment where an observer is asked to count the number of ball passes between people, and totally misses someone in a gorilla suit walking through the scene.  Scrum provides both direction and opportunities to focus on our work, but doing so may inherently prevent us from observing important changes in our work or work products. For example, members of the Development Team may be so focused on their current Sprint Backlog Items so as to not notice an increase in defect rates, or equally the Product Owner may be so focused on the Product Backlog for the next Sprint that he or she misses important changes in sales results.
Although Scrum is a team sport, each person views the product and team’s status through their own frame of reference. Some developers may see everything is going well whereas others may see a crisis coming, but without consensus the team will not change how they are working.
Using Information Radiators to maintain transparency is important for a functioning Scrum Team. When the information does not create action, team members may passively accept whatever information is being radiated. An example from our community is where one of us was working with a company where at the end of the Daily Scrum the Development Team would look at the computer generated Sprint Burndown Chart and no matter the shape of the burndown they did exactly what they had already agreed during the Scrum, even if the burndown was a straight, flat line. This is like a service message on the car dashboard that we ignore for months, but we also need information like the oil warning light that makes us stop the car straight away.
Create a status overview that demands action when outside acceptable tolerance. Information Radiators help to maintain the transparency for empirical process control but there is some information that cries out for immediate action. Use red lights, or emotive words like DANGER, or work environment lockouts on product and process state changes that disrupt the team’s anticipated work plan or sequence of actions that needs immediate attention. It needs to get people's attention and let them know something is not in a normal state. And it is necessary for the team to discuss what “normal state” means to them. When the Visible Status is no longer used for improvements the team should agree to remove it.
The status must be presented in a way that makes it easy and fast to grasp the meaning of the measurements. The indicator must communicate whether a given property of the process is within an acceptable range of tolerance (and requires no immediate action) or outside the range. In the latter case the team needs to know what measures to apply (by an explicit notice on the indicator, or from prior training) to bring the process back within tolerance. Keep the information simple and clear by showing only the most important information. Visual information is highly recommended as it is easily broadcast. To avoid unnecessary distractions the Scrum Team should maintain the least number of status indicators as possible.
Posting status is all about transparency, information sharing, and motivation.
✥ ✥ ✥
Maintaining Visible Status ensures that there are no surprises that come in the way of delivering a Regular Product Increment.
Use monitoring tools to gather data on all of the important metrics for your product and process and make them visible to the whole Scrum Team. Note that some metrics can be generated directly and automatically from the product or related processes. There are many toolkits available for this, but you may also have to build something yourself. In either case, the final presentation to the team should be simple and obvious. Examples we have observed in the wild include:
The call to action must be unambiguous. The change from no-action to action must also be clearly shared. This avoids losing time when the team is trying to make the decision, or worse, is not taking action because they are so used to ignoring the status.
Whatever you choose, it is important that the team clearly understand (from context, from a display on the status indicator itself, or from training) how much time they have to respond. For example, the traffic light could turn yellow if 24 hours is fast enough, or it could turn red when things need immediate attention. If high reliability is crucial to the business, the monitoring system may contact the team directly via their mobile phones.
The action needed can also be pre-defined. For example product defects require the team to Whack the Mole or when the reality of the Sprint has drifted too far from the Sprint Backlog the team executes Emergency Procedure. Use the Daily Scrum to re-plan and respond effectively as a team.
The Scrum Team needs to collaboratively develop the Visible Status. This will help to build greater understanding of the status indicators and the cross-functional work of the team.
Product health has many components, including the ongoing operations of the current system. There are many service level indicators that may be monitored continuously — CPU load, memory utilization, network utilization, application errors — far more than can be seen at-a-glance. Google’s Site Reliability Engineer recommends alerting the team only when problems are affecting end-users, and then making the details available for easy drill-down for further investigation.  Note that monitoring ongoing operations of the current system itself is not part of Scrum.
How widely should information from the visible status be shared? There is no call to hide anything in Scrum. Use common sense: share as much as possible but don't bother everyone with something that affects people only locally. If you walk the gemba (factory floor) and see an indicator that is active then find out if you can be of any assistance. Reflect carefully when faced with the temptation to compare indicators between teams that one might feel is facilitated by use of this pattern. If you do conclude to compare teams, please reflect again.
Of course, make sure that the status data collected and displayed is both accurate and relevant.
When accurate daily data is made visible to the Development Team, the team gets a better idea of where they are. They are in a position to make in-course corrections during a Sprint to help them achieve the Sprint Goal. They often do this of themselves, with little or no overt prodding from the ScrumMaster.
This pattern has origins in the Toyota Production System (TPS). TPS has Information Radiators, such as a large overhead board that tracks production measures in the factory. These are the system metrics. But more importantly, the TPS factory floor also uses indicators that flag the need for immediate attention. An engineer can signal that a defect has arisen in a product or in the process by pulling a clothesline-like cord called the andon cord (literally, “lamp cord”). This sets a small flashing lamp into action and initiates background music to draw attention to the problem. The Chief Engineer and others may come to help resolve the problem; they resolve most problems in seconds, and the lamp is extinguished and the music silenced. If the car starts to cross the line into the next work cell, a more global factory indicator is activated and the line stops because the defect now threatens the production of that car and the entire line. It is a signal that begs immediate human intervention. The idea in turn took inspiration from an invention by Sakichi Toyoda, who ran the loom manufacturing company from which Toyota Motor Corporation would spring. His invention caused a loom to shut down and ring a bell when it detected that either the warp or weft thread had broken so a person could intervene, fix the problem, and set the machine back into motion. He sold the invention to the British for £300,000, and with the money, started the Toyota Motor Corporation.
Isao Endo states in his book about mieruka (visualization) that it is needed to make people aware of the situation and change their behavior and actions and it also must show how the situation changes after they take actions.  It is said that mieruka is the core concept of gemba power.
 Don VandeWalle and Larry L. Cummings. “A test of the influence of goal orientation on the feedback-seeking process.” In Journal of Applied Psychology 82(3), 1997, pp. 390-400.
 Edwin A. Locke and Gary P. Latham. “Building a practically useful theory of goal setting and task motivation: A 35-year odyssey.” In American Psychologist 57(9), 2002, pp. 705-717.
 Daniel J. Simons and Christopher F. Chabris. “Gorillas in Our Midst: Sustained Inattentional Blindness for Dynamic Events.” Perception 28(9), Sept. 1999.
 Niall Murphy, Betsy Beyer, Chris Jones, and Jennifer Petoff. “Sharding the Monitoring Hierarchy.” In Site Reliability Engineering: How Google Runs Production Systems. Sebastopol, California: O’Reilly Media, April 2016, Chapter 6.
 Isao Endo. Mieruka (Visualization). Tokyo: Toyo-Keizai-Shinbun-Sha, 2005.
Picture from: https://commons.wikimedia.org/wiki/File:StackLightInstall1.png (license: CC BY-SA 3.0).