It isn’t always necessary to make a big deal out of the role of Product Owner. Sometimes it makes sense to low-ball the whole thing and propose something casual instead, like getting together and talking about what to do next. People are often suspicious of new jargon and new methodologies—and not without reason. This section’s example will highlight the importance of talking to business people in plain language—or at least in business language!
MegaBank is one of the largest financial institutions in the United States, with nationwide branches and enough capitalization to affect monetary markets. MegaBank transferred $39.6 trillion last year within and between its own operations and with other parties. The system that performed these transfers, maintained audit logs, ensured the security of the transactions, and successfully completed all transactions is called Fund Transfer System (FTS). When I arrived on the scene, the FTS project team was gearing up to start work on the second release of FTS. The team’s project manager, Pat, wanted to use Scrum. She had heard that Scrum had helped other customers become more involved in development projects; the FTS project needed similar help.
Since the first rollout of FTS, the customers at MegaBank had changed. The manager who had directed the first release of FTS, Henry, had been promoted to another job. Henry’s next in command, Mary, had taken over his position, but she found managing bug fixing and enhancements to be time-consuming and of less importance than her other responsibilities. Mary had delegated this work, along with communications and coordination of the project, to her next in command, Laurie, a sharp manager with very limited understanding of MegaFund’s FTS functions. Laurie was having a hard time directing project activities. MegaFund FTS management had established a release date of October 15, and it was already May. How could the FTS team get some solid direction from its customers and collaborate with them about alternative release contents during the interim?
Henry, Mary, and Laurie came to a meeting that Pat set up. Pat told them that the FTS team was going to use Scum, which had already been used to successfully manage other joint projects at MegaBank. Henry, Mary, and Laurie didn’t know what this meant to them and how much time was involved. They just hoped that Scrum would help them work more closely with the FTS development team. I was asked to start the meeting by presenting Scrum to Henry, Mary, and Laurie. I made the presentation quick and low-key. I told them that we used a prioritized list of things that they wanted done to drive development cycles of one month. Every month, we’d show them completed functionality, we’d review the list of what to do next, and we’d figure out what the team could do next. Henry, Mary, and Laurie were very pleased; Scrum seemed simple, easy to understand, and it required only a formal meeting every month. They could certainly handle that. They had been concerned that a new development process would involve training, new forms, new reports, and a lot of overhead. In contrast with their expectations, Scrum seemed very straightforward.
We spent the rest of the morning with the development team, reviewing the list of functionality requested for the second release. We created rough time estimates for the development of each item and grouped the items into possible Sprints. “Sprint” was a new term for Henry, Mary, and Laurie, but they relaxed when they learned that it just meant one month. This exercise relieved everyone; Henry, Mary, Laurie, and the development team felt that the workload was known, under control, and potentially achievable within 30 days. They had collaborated and reached a tentative plan in language common to both sides. We had set aside the entire afternoon to figure out what to do in the next Sprint. However, the team, working with Mary and Laurie, was able to select the Product Backlog in an hour. The team then got to work building the Sprint Backlog, while Henry, Mary, and Laurie went back to their offices, comfortable that progress was being made on the next release.
I downplayed Scrum to the FTS team and management. They needed to learn to talk to each other in a common language. Product Backlog requirements were the language in question, and everything fell in place once they began speaking in that language. Neither side needed to learn the Scrum language and process; they started using it only as a way of describing how they were going to collaborate. A Product Backlog was just their prioritized list of requirements. A month was the time between meetings, and it didn’t really matter whether they called it something funny like a “Sprint.” The FTS team has been using Scrum for over six months, delivering releases and collaborating with its counterpart teams. Downplaying Scrum simplified this collaboration by reducing the overhead of learning something new and the apprehension of a strange new methodology.