Wolves at MegaFund

MegaFund is one of the largest fund management companies in the world. Its innovative funds attracted investors more than the funds at any other organization. However, by 1997, Charles Schwab, eTrade, and other financial companies had revolutionized stock trading. Customers could now manage their own fund accounts, buy and sell stocks, and play the margins without personal assistance from professional stock brokers. The Internet and mobile technology had enabled Web, PDA, cell-phone, and voice-response unit functionality. Unfortunately, MegaFund had fallen behind this revolution. Its technology organization was large, bureaucratic, and cumbersome. To make matters worse, it had implemented Capability Maturity Model Level 3 practices over the last year. If incorrectly implemented, these practices can increase bureaucracy, as they had at MegaFund. MegaFund was now so bureaucratic that it was hard to get anything done.

MegaFund explored ways to enable new technologies that could access the legacy databases where all customer account and trade information was stored. After several false starts, MegaFund managers decided to do it the right way. Usually when managers say that they’re going to do a project “the right way,” that project ends up dying from excess overhead. Sure enough, after nine months the project was stalled while battles raged over what sort of technology to use. Should it be Solaris, Microsoft Windows NT 4.0, or AIX? Should MegaFund standardize on Intel technology? Were Sun servers more scalable than IBM servers? Was COM the way of the future, or was CORBA the way to go? While these wars were being waged, the competition surged ahead.

MegaFund finally decided to bring in Scrum to break the logjam and get the project moving. Terry Adams, who had been the project manager, had a strong technical background and an intuitive understanding of his new role as ScrumMaster. During the Daily Scrum, he listened carefully to each team member’s report. When someone had a problem with his or her equipment, Terry lent a hand. When people were stuck, Terry helped them access expertise external to the project. When purchase orders didn’t go through, Terry helped expedite them. He was able to remove impediments without ruffling feathers and without endangering his job.

The Wolves Strike

The team started a Sprint, and within two weeks it had made an impressive amount of progress. The team had selected and begun to use its tools and was implementing the first transactions. By the end of the Sprint, the team would demonstrate an approach to solving MegaFund’s technology problems and implementing a suite of competitive solutions.

Russell Hunter, a senior vice president in MegaFund’s systems company, was at a cocktail party about this time. After months of trouble, Russ was finally able to brag about some progress. Russ boasted to the head of the electronic funds retail unit, who commented that he had some significant competitive problems that he would like to see solved by this team. Russ, spotting an opportunity to garner some good will, offered to demonstrate a key electronic funds retail transaction at the Sprint review. The next morning, Russ got to the office early and approached one of the systems engineers on the team. The engineer didn’t report to Russ. He reported to someone who reported to someone who reported to Russ. Russ was a legend to him, someone who could influence his career with as little as a sidelong glance. When Russ asked him to look into implementing this transaction as part of the Sprint, the engineer couldn’t say no.

Something strange happened during that day’s Daily Scrum. Terry was listening carefully as usual, so he immediately noticed that this particular engineer reported progress in work that wasn’t part of the Sprint goal or selected Product Backlog. Terry asked the engineer to meet with him after the Daily Scrum, at which point the engineer confessed that he’d been asked to do a favor. The engineer was accustomed to senior managers telling him to do something on the side. But Terry knew that this practice was a violation of a fundamental Scrum rule: the team is left alone during the Sprint to accomplish the goals to which it initially committed.

Terry was an intuitive ScrumMaster. He went to Russ and asked about the work that Russ had asked the engineer to do for him. Russ was immediately defensive, knowing that he had violated one of the rules of Scrum. Russ said that it was as though he’d seen a $20 bill on the ground and he couldn’t help but pick it up. Instead of criticizing Russ, Terry struck a sympathetic posture. He made it clear to Russ that he understood the importance of this opportunity. However, he said, since Scrum was new to MegaFund, he was sure that Russ was unaware that Scrum had mechanisms for dealing with opportunities like this one. In a case like this, whenever an opportunity arose that was more important than the work selected by the team for the Sprint, management could abnormally terminate the Sprint. The Team, the Product Owner, and management would then conduct a new Sprint planning meeting. The new opportunity would be selected if it truly was the top-priority Product Backlog.

Russ thought about it for several seconds and realized that he didn’t want to cancel the Sprint. Everyone would know that he was responsible for halting progress on the project for this minor opportunity. The Sprint planning meeting would make his act highly visible and provide his peers with an opportunity to ask why his pet project was more important than their needs. Russ thanked Terry but demurred, saying that he would meet with the Product Owner and get on the Product Backlog in the next Sprint planning session. Of course, he never did so.

Lessons Learned

Terry used the Scrum rules and practices to keep the project on track. Scrum offers many opportunities to make changes and to respond to new opportunities. Scrum also keeps everything highly visible. The Product Backlog and its prioritization are open to everyone so that they can discuss them and come to the best way to optimize ROI. The Daily Scrum keeps all team activities visible so that the ScrumMaster can enforce the rules and help the team stay on track. By keeping everything in full view, the type of backroom politicking and influence swapping normal in most organizations is minimized. These mechanisms are useful in bureaucratic organizations as a way to get particular things done. But when Scrum is already getting things done, these behind-the-scenes pressures are counterproductive.