Agile requires a culture of continuous change. In the real world change is difficult, even for great engineers and managers. To change a culture you need to change what is measured and rewarded. Too many times people count on a "If you build it, they will come" approach, which only works in movies like “Field of Dreams.” Instead, one should use the visible management technique in which the motto is "Make it visible and they will change."
Acme IT (a fictitious company) had set a goal of shipping an increase of ten times the end-user features to production. Aimee, the leader of Acme, was experienced in change management. Aimee and her leadership team used all of the traditional goal-setting techniques. They used SMART goals and even DUMB goals. Their primary goal was talked about every time the team members had a sprint review, but their retrospectives never identified an action item that addressed it.
Acme didn't have a quality problem and its sprints were short. Whenever the company released code, it was high quality. In fact, Acme had just implemented a continuous delivery (CD) engine. Still, there weren’t any noticeable increase in the number of features released. The problem was that Acme was rewarding people for completing sprints and not increasing the number of features released.
Acme's teams had plenty of reasons not to switch. Aimee could have used many approaches to make the improvement. Her choice to fix this problem was visual management. Her goal was to make it a “game,” and a visual one at that. She defined the rules of the game, posted a “real-time” deployment scoreboard, and let people opt-in.
The rules were simple: Any release using the new CD framework counted. The deployment scoreboard was not owned by any person or group; anyone could contribute to the overall goal. Once Aimee got an automated email from the CM framework, she updated the scoreboard with a simple post-it note. The board had three numbers on post-it notes: The total for the year, the total for this week, and the total for last week. Two scoreboards were posted in the hall, one by each door, so people had to see them whenever they came in, went to the bathroom, or went out for lunch. One of the scoreboards was right in front of senior Acme management, so management was able to see progress too.
Figure 1. Deployment Scoreboard
Now people took ownership of integrating applications into the CD framework. Remember, no one forced the team members to do it; in fact, one person took this as his personal mission to help others get into the game. He became the leader for migrating to the CD framework, and he created another scoreboard with its own game. This scoreboard had post-it notes for each application to migrate to the CD framework. The scoreboard was a typical kanban board containing the following: To Do, In Progress, and Done. There was also an implicit work-in-progress (WIP) limit on the In Progress portion of the board. The section In Progress was kept in a corner of the flip chart that held about three post-it notes. Since Acme didn't use WIP limits, one was not explicitly set.