A visual control is a lean tool that has three primary purposes:

• It shows when there is some abnormality in the process including blockages, people being overcapacity, dates at risk, and more
• It provides an explicit workflow that the team is using
• It provides management a view of how work is flowing

A visual control can take many forms. Simple Kanban boards and complex product management systems are examples of visual controls.

In software development, there are two predominant levels of visual controls. One is at the team level, the other creates visibility across the technology group. Common team level visual controls are Scrum and Kanban boards. The following figure shows a technology wide visual control.

This visual control highlights three significant types of information:

• Milestones or events to be aware of (either a significant release or an event to prepare for such as a conference)
• MBIs being ready to be released. Depending upon the organization, MBIs might be released when ready or grouped into releases.  If the latter is the case then these releases should be marked in the Milestones/Events row if the release is organization wide or in the row corresponding to the team doing the release
• Dependencies any PBIs have with each other.

Consider releases, MBIs being ready, and dependencies as agreements about having them ready by the specified date. Making and keeping these agreements is one way of changing the culture of collaboration in an organization.

Visual controls across the enterprise

Although we mentioned the preponderance of team and technology wide visual controls, it is possible to have them across the entire organization.  Each control will have a different level of granularity and purpose.

Figure 2: Visual controls across the enterprise.

The above is just an example. Larger organizations will have more and smaller organizations less. Each control has a different purpose:

Potential Business & Systems Capabilities. This holds potential work, often in the form of initiatives.

MBIs. This board starts with MBIs that are not well-defined and ends with MBIs that are ready to be pulled.

Identify Dependencies / Architecture Review.  This board is sometimes integrated with the MBI board preceding it.  It is only required as a separate board if the MBI is going to be split up along the development group lines.

Team boards.  These are the teams’ Scrum or Kanban or Team-Agility boards.

System Integration and QA.  This board is only needed if integration and QA is done separately from the teams.

Deployment and Ops.  This board contains work that has been completed but not deployed.