As I have mentioned, systems development used to be simpler. But as the complexity of the systems in question and the environment in which they are being developed has increased, people and organizations have lost their way. We visited Service1st in Chapter 2 and Chapter 4. Service1st used a defined project management process that included Gantt charts, resource allocation, and time reporting to plan, initiate, and track project progress. Reports were sent to top management that indicated the critical paths, percentage of work completed, and other key project metrics. Management didn’t feel that was enough, however, and also required the vice president of development to report in person at a weekly executive meeting.
Service1st’s two top executives, Tom and Hank, had started the company and were among its first programmers. As Service1st grew, they realized that they had to give up day-to-day control of development and delegate authority to others. As a result, they were increasingly frustrated when releases began to slip more often and the product quality decreased. Everything seemed fine until the last two months of the release cycle rolled around. Then, without warning, everyone was working overtime to get the release out. The bug count kept climbing—often, it was all the developers could do to keep the bug count at a releasable, yet lamentable, level. Service1st decided to adopt Scrum and see whether the situation could be improved during the next release cycle.
Seven teams were sprinting; they concluded their Sprints on the same date so that their Sprint reviews could be simultaneous. The standard format for the Sprint review meeting was modified so that management could find out how all of the teams were doing at a given point in time. The teams took over a quality assurance (QA) laboratory for a day. Each team claimed a territory in the laboratory and set it up in preparation for the demonstration of their increments of functionality. The teams organized their presentation areas as though they were presenting at a conference, hanging signs with their team names from the ceiling and posting the Sprint goal and Product Backlog on the wall. Chairs were placed in front of the workstation, and evaluation forms were available for feedback. Essentially, seven vendors, or teams, were presenting their wares. Although this involved more preparation that I usually like to see with Scrum, it established an upbeat mood that raised energy levels and motivation.
The vice president of development brought all of top management to the Sprint review meeting in the QA laboratory. A member of each team stood and briefed management on the team name, its Sprint goal, and the Product Backlog it had selected and would be demonstrating and then summarized what had gone right during the Sprint, as well as what had gone wrong. This prepared top management for what they were about to see.
Management walked from team to team for functionality demonstrations. The teams then answered questions and recorded suggestions that they factored into the Product Backlog for their next Sprints. This collaboration between management and development teams went on for several hours. The teams then again took turns summarizing the work they’d done. Each team took about 10 minutes to report on what enhancements had been suggested to them. They asked whether they had missed anything, entertained further discussion, and then wrapped up.
The teams turned the Sprint review into a formal Sprint reporting mechanism. Because they really understood the value of face-to-face communication over documentation, they replaced reports with collaboration. By selecting a conference format, the team created an opportunity to collaborate with management for more than three hours. Management was delighted. Unlike a report, this collaboration wasn’t static and sterile. Instead, it was a vibrant demonstration of a reality.
After the Sprint review, some of top management gathered to comment on the Sprint review meeting. The vice president of marketing said, “I thought it was great. I was able to see exactly where you were. Can I get a demo of this to show customers? Can I bring customers to the next Sprint review meeting?” Most telling was a comment from Tom, one of the cofounders, who said, “When we were small, we used to have this all of the time. But as we got bigger, we lost the ability to keep everyone directly involved in our choice of direction. This is a way we can work together again.”