MegaBank was introduced in earlier chapters. The MegaBank Information Technology (MBIT) organization manages all MegaBank operations, technologies, and infrastructure. The individual banks develop the software for themselves and their clients and are collectively required to follow the decisions and use the operations of MBIT.
MBIT is the technology brain trust for MegaBank. Advanced technologies such as biometrics are researched and progressively rolled out under its auspices. Since the late 1990s, MBIT had used a Web site, MBITWeb, to store, post, and host discussion groups as new technologies were investigated. MBITWeb wasn’t user-friendly and had been the subject of many complaints. Its usage was also rather low. To address these problems, MBIT funded an upgrade project. Developers from one of the banks and MBIT technologists jointly composed the team. Scrum was selected as the development process. The individual banks had successfully used Scrum, and MBIT wanted to see what it was all about. Tom, a MegaBank employee who had previously used Scrum, was made ScrumMaster. Andy, an MBIT manager, was the Product Owner. Both Tom and Andy were team members as well.
MBIT management had learned to live with task-based reporting. It had devised other ways of learning what was really going on. Sometimes it asked for demonstrations. Sometimes it called for project reviews, at which it grilled the team. Scrum posed a problem for these executives. The ScrumMaster protects the Team from predations during the Sprint. The ploys management had traditionally resorted to aren’t allowed in Scrum. When Scrum is first implemented, sometimes this frustrates management, and this frustration boils over until a mechanism for satisfying it is devised. In the worst cases, management withdraws and says that Scrum has cut it out of the loop. Jim, the MBIT vice president who had funded the MBITWeb project and the Product Owner’s manager, had tried such a predation, asking for a demonstration in the middle of the Sprint. He boiled over when Tom and Andy told him to wait until the Sprint review meeting at the end of the Sprint.
Jim demanded a meeting with Helen, the IT director of the bank supporting the project. Jim was acerbic by nature, initially putting people on the defensive rather than collaborating with them to get information and work out solutions. He demanded that Helen tell him what sort of strange process Scrum was if it required that all progress be hidden for 30 days. He didn’t have time to attend Daily Scrums, so how was he to know if things were OK? Tom and Andy had shown him the Scrum reports, but they were meaningless to him. This was a deep technology project, employing a number of advanced IBM technologies. How could he know whether these technologies were working effectively? How could he know to what degree the different parts of MBITWeb were developed every Sprint? How, how, how? By the time Helen left Jim’s office, she felt as though a hurricane had just passed through her!
Helen regrouped with Tom and Andy and told them that Jim was dissatisfied with the current reports. They simply did not satisfy his technical curiosity about the details of the development. Furthermore, Jim worked in an intellectually aggressive organization: at MBIT, anyone could question you about your projects, so you were expected to have the details at your fingertips at all times. If Jim didn’t understand what was going on in his project, he would wind up looking bad.
Helen, Jim, and Andy understood that Jim was different from the usual project stakeholder. The user functionality was only a small part of what he cared about. He also cared about the technologies being explored by the project. His boss was more likely to question him about portlet technology than user functionality. Jim required reports containing information about both. Because Jim was busy and impatient, these reports would have to be easy for him to grasp, assimilate, and use to track project progress.
Helen, Jim, and Andy presented the problem to the team. Together, they devised a management view of the project’s technology architecture, as shown in Figure 7-5. This view was simply a cleaned-up version of the system architecture diagrammed on the wall of the team room. They divided the technology into layers of services: presentation, application, and data. The team then assigned colors to the milestones for this project. The milestones were simply arbitrary dates when management wanted certain product capabilities. These were later synchronized with Sprint review dates. Blue represented the first milestone. When the services were partially completed, they were colored light blue. When they were completed, they were colored dark blue. The same progression was devised for the second milestone, with green representing progress, and so on. As the team began working on a service, they used the light shade of a color. When they had finished with a service, they changed the light shade of the color to the darker shade of the color.
The technology progress report was posted on the door of the team room, where it was visible to anyone walking by. A copy was delivered to Jim weekly, keeping him up-to-date on progress more frequently than once a month. When Jim met members of the MBITWeb team in the hallways and asked about progress, the conversation was held in terms of the services and service names on the technology progress report.
At the Sprint reviews, the team started by discussing the progress made on the various services. When the team demonstrated a transaction that threaded services together, from presentation through application to data services and back, it showed the progress of the transaction on the technology report.
After several Sprints, most managers are more than satisfied with the visibility Scrum provides them into the project and its progress. The trick is how to get over these first few Sprints. My customers and I have had to devise any number of ancillary reporting mechanisms to Scrum to do so. This could potentially be viewed as a weakness of Scrum. But keep in mind that Scrum represents a major shift in thinking and acting, and many people don’t really understand Scrum until they have experienced it. In the meantime, these interim reports bridge the gap between when the first Sprint starts and when management feels comfortable with the visibility it has into the project through Sprint reviews and Scrum reports.
During the transition to Scrum, these ancillary and customized reports are necessary. You don’t want Scrum rules to be broken and the team to be disrupted. On the other hand, you don’t want management to withdraw or boil over. As ScrumMaster, your job is the Scrum process and its adoption by the organization. You are responsible for figuring out and delivering these interim- reporting mechanisms whenever they are needed.