Empowered Scrum Roles
When Ken and Jeff invented Scrum in the 90s, they weren’t working for small IT oriented startups. They were working in medium to large enterprises with all the issues of legacy and scale found in similar companies today. When you read the Scrum Guide, you notice a few things. There are no project managers, because Scrum is about developing products in a way that has nothing to do with project management or even projects. You notice there are stakeholders mentioned, but they do not have much of a role in actually developing the product beyond providing their wishes to the Product Owner and feedback in the Review.
There are no complicated management structures outside the team, but the stakeholders could be internal or external to the organization. There are no product managers or business owners in Scrum. The Product Owner is the one that does whatever these guys might do in other non-Scrum contexts. The Scrum Guide says quite clearly: “For the Product Owner to succeed, the entire organization must respect his or her decisions.” It is indeed a very senior, very powerful role. They are the single person responsible for product related decisions and the main way they ensure the financial success of the product is by owning the Product Backlog. Please keep in mind each product has just one product owner who is business rather than technically oriented.
The Scrum Master is also supposed to be equally empowered. He needs to be perceived by the organization to be at least at the same level as a project manager in equivalent non-Scrum approaches to product development. However this seniority is expressed very differently when compared to traditional managers. They adhere strongly to a notion known as servant leadership. They provide services to three different parties: The Development Team, the Product Owner and the organization. In order to provide these services, they need to be empowered by the organization to do this. They need to be seen as the main contact person in a management type role related to the team. There cannot be anyone “above” the Scrum Master making decisions about the process or the system within which the team does their work. These decisions can only be made by the Scrum Team with the support of the Scrum Master. Essentially the Scrum Master should be involved in all activities that are not explicitly Product Owner or Development Team activities.
Just as the Product Owner finds it hard to do his job if there is some distance or some type of wall between him and the true stakeholders (here I mean actual end-users, rather than some type of product management group), the Scrum Master relies even more on the connections and relationships he develops with others in the organization, in a variety of departments, and at a variety of levels. If there are any meetings related to the process or system of development affecting the team, the Scrum Master has to be there. This includes especially discussion related to the budget (one good approach is to make the PO responsible for money coming in, as they are responsible for maximizing ROI after all, and the Scrum Master responsible for monitoring costs), contracts, pricing strategies, hiring and HR policies in general, prioritization at the portfolio level (which may also involve the PO), and anything related to the culture of the organization. All these things are done differently when an organization decides to adopt Agile product development so the Scrum Master is essentially crippled when he is not involved at these levels. The team will not develop self-organization or the capability to improve. If the Scrum Master is prevented by providing the above-mentioned services to the organization, then it will not see the advantages expected of introducing agile.
I was asked by a colleague the other day if I could describe the PO role as he might expect it at one of our customers. Now he had done the CSPO course and passed the test but hadn’t had much experience on Agile projects. Normally one would expect the role as defined in the Scrum Guide to be more or less what he could expect, and I think for the most part it is. However there is actually a lot of variation in how the Scrum roles are actually lived. Some legitimate, some not. For one, the context imagined by the authors of the Scrum Guide has to be considered and compared to the context found at the typical company using Scrum.
Some enterprises claim they are different or special, and find it necessary to take actions that either deliberately or inadvertently disempower the PO or SM role. For example, I explained to the colleague I mentioned above that in the organization he will be working with, his role will likely be very different to the description found in the Scrum Guide. Quite often a Product Owner will join an already started “project” and find that his main job is already done. Someone else, possibly a product manager or business owner, has already developed a product vision, and significant amounts of design documentation may already exist including screen shots. The only thing left to be done is for the product to be typed in as source code by the programmers. But because the company has picked Scrum, they need a PO, and his main task will be to convert this documentation into “User Stories” and put them into some tool like Jira. Even the priority of the features is probably already decided. This is complete waste. In this context it is too late for a Product Owner, User Stories and even Scrum itself. Scrum would have been relevant for the guys that wrote the design documentation; the group that actually developed the product. In fact they should have saved that effort by putting these guys in the same cross-functional team as developers, as Scrum and Agile always intended, to get turned directly into software without needing to write all this design documentation! It is also too late for user stories. User Stories would have been relevant somewhere between the vision and the creation of this design documentation. Turning this documentation into user stories is essentially throwing away information or jumping back a step. The developers should work directly from this documentation if it already exists; converting it into user stories brings no extra value at all. Even Scrum itself is too late for this context. The product is already developed. The developers should just type it in, feature after feature.
Such organizations are also likely to add roles like project manager or “IT-PO” to the team to handle e.g. end-to-end process responsibility, compliance and governance functions or cost controlling. These roles will be seen as the main management role that people outside the team will interact with, cutting the Scrum Master out, and reverting him to a sort of team assistant role, known for not much more than organizing the meetings.
Scrum is designed for very complex, highly creative, market facing product development efforts involving both business-oriented and technical people. That is why you need highly empowered Product Owners and Scrum Masters. But if you aren’t using Scrum as intended, like the example in the previous paragraphs, then you really don’t need either role, nor Scrum itself. All the complicated, creative stuff has already been done!
To be fair I think the Scrum community might have underestimated the skills that Scrum Masters truly require to do their jobs properly. I notice a lot of them shy away from discussions about money, or feel uncomfortable dealing with people, especially managers, outside the IT. Sometimes the Scrum Masters themselves are a bit too focused on the general guidelines in the Scrum Guide, and think their role is not to do much more than plan meetings, and have endless sticky-note based discussions with the programmers about values and principles, or play games with Lego. Don’t get me wrong there are all important things for a Scrum Master to do. There are definitely times and places for all such team-oriented coaching work but I think the Scrum Masters should in general do a better job of knowing when such things, and how much, are appropriate. I think this is one of the reasons why organizations can lose trust in Scrum Masters and feel it necessary to make up strange structures and extra roles, to perform the tasks that Scrum Masters tend to avoid. This temptation has to be resisted though, as the organization will not see much benefit from Agile or Scrum if these two critical roles remain disempowered and the team will never achieve self-organization.