By Geoff Watts
Scrum is very explicit in its clarification of roles and responsibilities. Scrum has only three roles; together they cover the responsibilities needed to ensure a successful project. The Product Owner represents the customer and sets the vision, goals and priorities of the project. The PO then works collaboratively with the team to determine the details during each sprint, accepting work as it is completed. The team members are responsible for determining what can be done within a sprint, making a commitment for a sprint’s worth of work and then organizing themselves to deliver the functionality needed. The ScrumMaster guards the team and its process, keeping an eye out for Scrum smells and removing impediments to productivity.
Almost anyone who has been on a Scrum project has noticed the issues that can arise when one Scrum team member wears two hats (for instance, when one person plays both the role of ScrumMaster and the role of developer or when one person plays Product Owner and developer). Doubling up injects a certain amount of implied hierarchy into a self-organizing team and increases project risk by significantly escalating the difficulty of planning and removing some of the checks and balances inherent in a Scrum team. While neither of these dual-hatted roles is impossible to incorporate in a Scrum team, by the same token, neither is ideal.
Another less-than-ideal scenario is having one person play the roles of ScrumMaster and Product Owner. In that case, the same person is responsible for guarding the team and its process as is responsible for the direction and profitability of the product. While this has even more explicit potential for a conflict of interests, the outcome depends on which of those hats is the more dominant. For example, when a ScrumMaster assumes the role of Product Owner, the lack of someone pushing business priorities can result in technology-focused indulgences or a team pace that is too comfortable. In contrast, a Product Owner who assumes the role of ScrumMaster can go too far the other way seeing this as an opportunity to take direct control of their very own development team, foregoing the technological needs of the project and pushing for a very aggressive, and possibly unsustainable, pace. In both cases, being both product owner and ScrumMaster is likely to be a big draw on one person’s time, leading to possible sacrifices in either their stewardship of the team or up-to-date information on the product.
While none of the problems in the above scenarios is insurmountable, arguably the most anxiety-inducing and uncommon dual-role is the combination of ScrumMaster and Product Owner. Ben Johnson of Man Investments knows about filling this inherently oppositional dual role first hand. He had some very interesting experiences from his time filling both roles on a Scrum project. In his case, the dual role was never intended to be a permanent one, but it did provide him and the team with insights into their responsibilities and processes they might not otherwise have attained.
Working within the Product Management department of Man Investments, the world’s largest hedge fund, Ben’s group’s primary function is to ensure that clients get the correct level of exposure to the underlying investments that their funds promise. In order to do this, Ben’s group undertakes weekly or monthly rebalancing of client funds. Though this rebalancing process involves several systems distributed among Man Investment’s global divisions, one key database system is used to determine the actual transactions required to gain this promised level of exposure. These transactions total billions of dollars each month.
Not only is Ben part of the team responsible for the day-to-day running of this system, he also assumes the role of Product Owner with respect to its ongoing development. As Product Owner, he spends a significant portion of this time collocated with a Scrum team that consists of four full-time developers and two part-time analysts/testers. The team used to develop using a waterfall approach, which did not fit well with their fast-changing business requirements. Now, Scrum allows them to wait to capture the more intricate business requirements until the point that development actually starts, making the entire development process less wasteful. A combination of sprint planning sessions and burndown charts has made their work much more visible to the business. This visibility, coupled with the increased throughput of work, has forged bonds with various business stakeholders and has changed the business perception of the development team from “can’t do” to “can do.”
To enhance awareness of the scrum process, the team’s development manager suggested that each team member should take a turn as ScrumMaster, so the team members rotated the ScrumMaster role around the Scrum team. Ben had not been in the Product Owner role for long, and thought taking a turn as ScrumMaster would be a good opportunity to get more involved with the development team, so he included himself in the rotation. If nothing else, he thought, it would force him to be involved at every daily Scrum meeting!
The developers were happy for Ben to take on the role (perhaps because none were too keen on being ScrumMaster themselves!) and Ben feels they made sure he had plenty to do throughout the sprint, as they raised plenty of impediments. At the same time, the developers did express some concerns about the idea of a Product Owner also playing the role of ScrumMaster. They spoke of their worry that the team could be left exposed without anyone neutral guarding the process and that this could lead to the ethos of Scrum dissolving. Ben talked with them about ways to mitigate that likelihood as well as possible warning signs to look out for. They also decided that they would review how it went at the end of the Sprint so that, as a group, they were comfortable with the experiment.
Initially, Ben’s main concern was how to manage the planning meeting. How could he get the best value for the business without pushing the team too much? Would he be able to allow the stakeholders to decide upon the priorities without unwittingly influencing their decisions? In fact, the planning session went better than he expected. As Product Owner, Ben introduced the high value user stories as he normally would, while, as ScrumMaster, he facilitated the meeting itself. Ben invited a second attendee to the planning session who could represent the business in another Product-Owner-type role to ensure there was a business interest looking at the overall picture in the event that his role as ScrumMaster prevented him from seeing something. In addition, the business was well represented by all of the stakeholders, so it wasn’t necessary for Ben to represent those stakeholders himself, allowing him to function more as a ScrumMaster.
What Ben hadn’t envisioned was the amount of re-planning necessary during the sprint. As Product Owner (and with the stakeholder’s trust), Ben is typically able to make decisions on what to add/remove from the sprint but, since this time he was acting as ScrumMaster as well, Ben didn’t feel comfortable making these decisions himself. As a result, the team had more than one formal re-planning session, which increased the burden on the many business stakeholders.
Time was an area generally that Ben struggled with in his dual role. Being Product Owner is not 100 percent of his remit and, as such, there is a certain amount of juggling he must do, even in a “normal sprint.” With the additional admin work (such as updating the burndown chart and chasing up impediments) that the ScrumMaster role required, this juggling became more difficult, and had a detrimental effect on Ben’s day job. For example, he fell behind in responding to queries and, as such, became somewhat of a bottleneck in another process.
This particular sprint threw up an unusually large number of impediments, many of which revolved around the setup of new PCs, and these were not dealt with as efficiently as Ben felt they could have been. This was partly because Ben was stretched too thin and partly because he didn’t have the same level of contacts in the technology department as the development team did (as these impediments were mainly IT-related).
There were times during the sprint when the team was able to take on extra user stories. With a series of future sprints vaguely planned, Ben would have normally made the call himself as to which stories to add. However, he was conscious of the temptation to cherry-pick his personal favorites and, as such, called more than one formal re-planning session with the business stakeholders. While this ensured the correct result, it was at the expense of considerable business time.
From this experience, Ben learned that formal re-planning sessions should not be organized unless absolutely essential. If you have planned for future sprints, the Product Owner can usually identify the best user stories to bring into the current sprint. At the same time, Ben also became very aware of the importance of having a release plan covering future sprints, both to give the an indication of the future direction and also to give the Product Owner something concrete to work with when an opportunities arises for the team to bring more user stories into a Sprint.
Ben believes his experience as a ScrumMaster gave him a better feel for what is required of a ScrumMaster and how time consuming that role can be. For anyone playing both roles in a Scrum team, Ben recommends that they build out a release plan of future Sprints and time box rigorously. Having people around that can act as both technological and business consciences can be very useful, too, in order to avoid becoming one-sided.
Being successful in this dual role does require a Product Owner who is mindful of the Scrum process at all times. One of the developers, commenting on the success of the dual role, said, “I think it depends on the Product Owner. If they were hard-nosed and didn't care about process, then it would have been a very different matter.”
While it is definitely a less-than-ideal situation, playing both roles is possible and even has some advantages. It was certainly a learning experience for both Ben and the team. Although there is still a doubt as to whether the inevitable conflict of interests could continue to be avoided long term, all were glad that Ben took his turn in the rotation. In the end, both the team members and Ben felt that he gained an appreciation of their frustrations and challenges that he otherwise may have been blind to in the sole role of Product Owner.
