One of the things I'm constantly preaching to our DevOps team is the need to approach Scrum pragmatically - as I pointed out in my post on Shu Ha Ri, the goal is to not have your team dogmatically follow a certain set of precepts or rules, but to learn how to use those as guidelines and improvise upon them to meet the requirements of your own particular situation. Recently, however, as we took a look at how the roles of functional manager and product owner were evolving with our teams, I realized how much I needed to heed my own advice, and how my own dogmatic perspective on the nature of these roles needed a pragmatic adjustment.
In pre-agile days, engineering managers were the hub of development activity. All requests for changes or new functionality went to a team's manager, and they in turn parceled out the resulting tasks to engineers. It was a very hub-centered, "push" type of process. Agile turned this world upside down. In Scrum, all requests go through a Product Owner, who decides which requests are important, and in what priority order they should be approached. The PO owns the what of a project - what gets done and in what order. Given these priorities, the team then decides how this work will be done, and by whom.
In "dogmatic" Scrum, there is always a very high, solid wall between engineering management, which provides command-and-control for the larger enterprise, and the product owner on the Scrum team. This is because the ultimate goal, as I have written before, is to have teams become self-governing. Functional management sets the development roadmap, but it's up to the teams to figure out how to implement it. In this situation, the Product Owner is there to advocate for the customer, and to determine when the Minimum Viable Product has been reached. The particular challenge for the Product Owner is to embody "servant leadership" that enables the team in its work, but isn't overbearing and directing.
The dogmatic approach works well in a more mature DevOps situation, where roles have been defined and in practice for some time, but at Sauce, where we have a lot of junior team members with less Scrum experience, I realized we had to step back and pragmatically assess how useful this approach is for us. One idea was to collapse the roles of Engineering Manager and Product Owner, but this put an enormous amount of work on that person's shoulders, as they are effectively having to serve two masters - one the one side, they have to manage their work and responsibilities relative to the larger goals of an enterprise, while also having to manage the activities of a team. There is also a considerable danger that combining these roles into one will make the person occupying it seem to be "in charge." In stand ups there is already the risk that team members will perceive themselves as "reporting" to the product owner, when in fact the purpose is for them to communicate among themselves. By combining the two roles, there is an even greater risk that the EM/PO will be seen as being responsible for directing the team's work. It's also very possible that, by stepping into a role that is perceived in this manner, the person taking it on will see it as a position of power, and once in the role, try to take on more. It's up to the Scrum Master to be aware of these dynamics and nullify them, but this is such a natural human tendency that it's not a matter of if it will arise, but when and in what degree.
Our solution was to recognize that, even if the goal is for all team members to be equal contributors and for the team to be self-managing, sometimes you need defined leaders who can coach junior team members, and who can provide input based on their experience to guide decision-making. So, contrary to all Scrum dogma, we have designated Team Leads who help "manage" the activities of the team. We still have Product Owners, who fill the classic requirements of that role, and we have Engineering Managers. Pragmatically, we had to recognize that while these roles are essential for integrating the work of teams into the needs of the user, and the needs of the enterprise, our particular situation required another role that would enable the teams to realize their highest potential within the team itself.
Joe Alfaro is VP of Engineering at Sauce Labs. This is the ninth post in a series dedicated to chronicling our journey to transform Sauce Labs from Engineering to DevOps. Start at the beginning and read the first post here, or read the next installment in the series.