in-flight, and allowed transparency into what was being worked in real time. Although resistant to the discipline to maintain the boards, teams and managers soon began to value the safety that the transparency afforded--if they were in trouble, management could help, instead of interrogate.
Figure 1: Visual Controls: In one of many agile spaces, rolling whiteboards display work-in-process for each program and planned work for future iterations so that anyone can see up-to-date status.
It should be mentioned that this conversion was harder for some than others. There should be an expectation set that asking managers to forgo efficiency at the individual level ("keeping people busy") is a hard move for some to make. Lean guides us to look at efficiency at the enterprise level (optimize the whole). Efficiency at the individual level is mis-applied, and often creates more work-in-process and hides delays. It seems paradoxical that using SME's to complete work outside their area of expertise can improve enterprise efficiency, but it does because it keeps the amount of opened work in check. By utilizing cross-functional teams to help complete small increments end-to-end, the chance for discovery of errors later is greatly reduced. Overall architecture and integration is maintained with each additional increment, as opposed to legacy thinking that SME's should only do work within their area of expertise. The hidden waste in this thinking is revealed later because keeping people busy delays integration until late in the life cycle, which is where most projects uncover hidden problems too late to recover. The PMO took this principle to heart, and created visual controls to show efficiency of completing work at higher levels (done from the point of view of the customer). This visible flow became the focus, and this helped guide the transition so that completing small releasable features trumped keeping individuals efficiently tasked in their specialty.
As more teams were transitioned to the new process, the PMO began to collect and manage standard work that Project Managers performed on a daily, iteration, and release basis. This new process documentation outlined activities that require attention during various Lean-Agile iteration activities, such as visual control practices, facilitation and agenda for sprint demonstration, sprint reviews, and sprint planning sessions. As the group matured, a standard set of dashboard items began to emerge that each program made visible to the entire organization. These charts began to appear outside LaPorte's office and his executive dashboard was born.
Figure 2: VP’s dashboard. The view outside of Bob LaPorte’s office. LaPorte is VP of Corporate IT Application Development. Each program in flight updates these charts which show daily progress for each iteration, and progress against each release plan. From this view, the flow of work through the entire organization can be viewed, as well as any bottlenecks.
The dashboard view soon migrated to Sharepoint, and the PMO began driving their bi-weekly program status by reviewing each team’s velocity and flow, with a goal of working to clear bottlenecks as soon as they were discovered. In early sprints for the C-Suite Dashboard team, they struggled to achieve a solid velocity because they had yet to breakthrough their thinking on swarming and stories were left incomplete at the end of the sprint. They were effectively splitting team focus on two priorities, one to complete a maintenance release which was primarily test tasks and development of the next new feature. It was a tough sell to the product owner, but the team eventually put their full focus on the highest priority - completing the maintenance release. They stopped working on Release 2 and all hands were