A visual control is a lean tool that has three primary purposes:
- Show people on the team and elsewhere to see the state of the work being done and to identify abnormalities in the process such as blockages, capacity issues, or dates at risk
- Provides a way for a team to better discuss what their process should be
- Provides a way for management to see if the team is following their own process
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. Figure 1 shows a technology-wide visual control.
Figure 1. Planning Board Builder
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. If they are grouped into releases, then these releases should be shown in a Milestones/Events if the release is organization-wide or else in the row corresponding to the team doing the release. 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 MBIs have with each other
Putting a release or an MBI being ready or a dependency on the board represents an agreement about the date they will be ready. Making and keeping these agreements is one way of changing the culture of collaboration in an organization
Visual Controls Across the Enterprise
The above is just an example. Larger organizations will have more and smaller organizations less. Visual controls should always be used at the team and technology levels. They can also be used at the organizational level. At this level, different types of controls will be used depending on granularity and purpose. Here are some examples.
- 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
- These are the teams’ scrum or kanban 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