A visual control is a lean tool that has three primary purposes:
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:
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.