Fixing the Problem of XFlow at MegaFund

I used to refer to Geoff, the product manager of the XFlow workflow system that powers all of MegaFund ‚ s business operations, as the ‚“shadow Product Owner. ‚½ We first met MegaFund in Chapter 3. Geoff used Scrum at MegaFund, but no one knew it. Here ‚ s what Geoff had to say about his experience as an undercover Product Owner:

A big reason for my success this year was my involvement with Scrum through you and Jack. It must have been November of last year when both of you told me to meet with customers every 30 days. That monthly meeting has become the model for successful organizations at MegaFund. All of the XFlow customers rave about how involved they are with engineering and how they know exactly what we are working on at all times, as well as about our on-time delivery. Other organizations are now trying to put together these types of meetings to bolster their communication with their customers.

How did Geoff manage to implement Scrum without telling anyone ? For that matter, why did he do so? I ‚ ll answer both questions in this section.

XFlow was developed internally by MegaFund from the licensed source code of a commercial workflow product. As the XFlow engineering team customized the product to MegaFund ‚ s needs, it became the arterial system for MegaFund ‚ s information and workflow. The engineering team, located in Salt Lake City, enhanced and maintained XFlow for MegaFund companies worldwide. Emboldened by the internal success of XFlow, the engineering team planned to market it externally and begin selling it to other companies. Unfortunately, this decision created a tension between the engineering group and the internal customers. The engineering group prioritized enhancements that made XFlow more commercially viable , while the internal customers prioritized enhancements and bug fixes that solved their operational problem. Over several years , the two groups grew deeply distrustful of each other. Several of the larger business units of MegaFund started investigating the possibility of replacing XFlow with new commercial products. These internal customers felt that external vendors might be more responsive to their needs than the internal XFlow engineering group had proven. This was a potential catastrophe. If the internal customers implemented other workflow systems, interfaces would have to be built to accommodate them. The MegaFund workflow would become less than seamless. Furthermore, losing some internal customers would hurt the remaining internal customers by decreasing the funds available to enhance and sustain XFlow.

The politics heated up as individual companies escalated their causes. It seemed that a solution would be very difficult to find. The MegaFund ScrumMaster, Jack, and I sat down to brainstorm with Geoff. Did Scrum offer anything that could help him and save XFlow? We focused on the Sprint review and Sprint planning meetings. Would it help if Geoff facilitated a meeting like these for the engineers and customers? Neither the engineers nor the customers had given Geoff the authority to create or prioritize a Product Backlog ‚ and they weren ‚ t likely to, either ‚ but perhaps he could facilitate a session where this would naturally occur.

Addressing the Problem

Geoff set up an all-day meeting for XFlow engineering management and internal customer management. He told everyone that the purpose of the meeting was to get everyone ‚ s concerns aired and to see whether a common ground could be found. He did not mention Scrum. Everyone was so riled up that they were looking for a scapegoat, not a process. Geoff set the agenda: first, engineering would present the product as it had been recently enhanced; second, the internal customers would present their most pressing needs; third, engineering would present its enhancement plans; and fourth, the two groups would see whether there was a common ground.

The customers watched with rancor while the engineers presented their updates to the product. Surely, the customers assumed, the engineers hadn ‚ t done anything that would be of use to the customers! But they were surprised; some of the updates were not only useful, but they were also ones that the customers had themselves requested . Then each customer presented his or her most urgent needs. Geoff recorded these on a whiteboard, eliminating duplicates and keeping the wording clear. When the engineers presented their planned enhancements, Geoff factored these into the list on the whiteboard, again eliminating duplicates. As the presentations went forward, it became clear that there was indeed some commonality between the customers ‚ and the engineers ‚ respective agendas .

Geoff told everyone present that he didn ‚ t know whether a long- term solution was possible, since the two groups had such conflicting interests. However, he noted, if the engineering team met some of the needs of the internal customers, XFlow would be more commercially viable. These internal customers could potentially be references for external prospects. He then noted that some of the enhancements that the engineering team had presented represented desirable functionality that external workflow vendors were pitching to MegaFund.

Geoff then used a key Scrum tactic. He asked whether the list represented everyone ‚ s most urgent needs. He reminded everyone to focus on the immediate future and see whether a near-term game plan could be devised. He asked everyone to help figure out what could be done over the next 30 days that would help everyone the most and do the most to solve everyone ‚ s problems. After an hour of mostly collegial discussion, the two groups together selected seven items to develop and some critical bugs to fix. Geoff asked if everyone could wait 30 days to see whether developing these features and fixing these bugs would improve the situation before doing anything rash. Everyone agreed to give it a try.

A month later, the engineering team presented its work. It described the technical problems it had encountered and the way it had worked around them to implement the desired functionality and fix the troublesome bugs. The customers questioned the engineers and asked them to demonstrate various other parts of the functionality. The customers were impressed that the team had done so much work in just 30 days; the team had built completed functionality, not just internal models and other stuff of no interest to these customers. The customers were also pleased that the work done was what they had prioritized; the customers felt that the engineering team had really listened to them. The engineers were pleased that the customers were pleased and no longer out for blood. They had built something that advanced the product commercially and yet satisfied their internal MegaFund customers.

Geoff then handed out the list of most urgent functionality from the prior meeting. He asked for updates from the engineering team and customers. Had anyone ‚ s needs changed? Had the external product requirements changed? Had any critical bugs arisen? Geoff led the discussion and then helped the two groups prioritize the list of functionality to develop and bugs to fix and then to select the work the engineers would do during the next 30 days.

Lessons Learned

Geoff wasn ‚ t a traditional Scrum Product Owner: he didn ‚ t write up a Product Backlog, prioritize it, and meet with the development team at a Sprint planning meeting. Geoff had taken the Scrum expression ‚“the art of the possible ‚½ and facilitated direct collaboration between the internal customers and the engineering teams . It turned out that when they met face to face, their needs and problems had significant overlap. All Geoff did was help them get together to explore these needs and problems and then develop a plan for action. Because the plan was to last only 30 days, there was no point bickering over whose problem was to be top priority. Everyone could see that the work to do was being whittled away and that everyone ‚ s problems would eventually be addressed. The regular delivery of functionality every 30 days reassured them that their needs weren ‚ t being deferred indefinitely.

By applying some of Scrum ‚ s practices and philosophies, Geoff was able to resolve a most difficult situation within MegaFund. His evaluation of Scrum, made after two years of experience applying these Scrum techniques at XFlow, reflects how well this commonsense approach worked at MegaFund.

When people don ‚ t get together, face to face, and talk to each other, they often project their problems onto each other. The engineering team and internal customers hadn ‚ t met for over a year, and their normal mode of communication had devolved until it consisted merely of e-mail messages from one group to the other. When they got together, with Geoff as their facilitator, they were able to set aside their differences and find a common ground. Simple courtesy and good manners is often the grease that makes these meetings work.