The case for separate ScrumMasters & POs
When you’re an optimistic person, you sometimes embark on challenges that ‘seem’ like a good idea; but unfortunately, the further you get into the fray, you realise there are reasons why other people do not do this thing. And they are good reasons.
A little while ago, I embarked on a Product Manager role, where I did not have the support of a ScrumMaster or a Project/Delivery Manager for the first time in my career. This seemed okay (on the surface), if you have a small team and the team assure you that they are self-motivated, self-governing people who can be responsible for themselves and do not need a Delivery Manager/Overlord to oversee their activities.
As right as they may have been that they did not need an overlord; there are other parts of a Manager’s role that are beneficial to subordinates. Our Managers give us support, they motivate us, they help us solve our own problems and they create a culture (hopefully) where we can do our best work. On the other side of this, they have our commitment that we will do our best for them, that we are trustworthy, that we will do what we say and we will try our best not to make their lives difficult in any way. A Manager’s job these days is less an overlord for personal productivity, and more of ‘helping us to get the best out our ourselves’ by leading us on the path to success. The ScrumMasters and agile coaches I have previously worked with have been incredibly committed to motivating teams and removing impediments for their teams to do their best work. And for this I have saluted them. (Often, embarrassingly for them, publicly.)
Ten years ago, agile was not very common in companies, especially smaller companies. We predominantly had Project Managers who were responsible for the list of requests from other parts of the business, who took these requests, worked with business leaders to prioritise them and worked with the delivery team (often design, developers, QAs and release managers) to get these requests turned into tangible developments released into the market place. Ten years ago, the ‘Subject Matter Expert’ (Product Owner) part of this production cycle was done by the a lead in the departmental unit (e.g. marketing) who needed the outcome to happen for other activities to follow. It was the Project Manager’s role to get this requested work done on time and on budget, so that those requests could be released and the follow up work, such as marketing the thing that was produced, could be managed effectively. (I realise I have simplified Project Management here to make my point and to colleagues/practitioners I apologise. It is a difficult job.)
When agile started to become a more popular methodology in tech teams, we continued to have fairly defined roles in the delivery team (design, development, QA,) but the Project Manager was replaced by the role of ScrumMaster and the ‘Subject Matter Expert’ became a designated full time ‘Product Owner’ role. This sometimes takes the form of ‘Product Manager’ in companies where they have other responsibilities (such as managing the full product lifecycle, working on validating the proposition to the business, taking on user research, UX activities in addition to the ‘Product Owner’ delivery mechanism within the scrum team).
So in 2001, when 17 independent practitioners wrote the agile manifesto, they agreed on four core values:
- We value Individuals and interactions over processes and tools.
- We value Working software over comprehensive documentation.
- We value Customer collaboration over contract negotiation.
- We value Responding to change over following a plan.
These are quite negotiable and arguable values. The idea, I suppose, was to empower the development team from their business overlords to do their work in an agreed structure, so that they could have some freedom to be creative and come up with good solutions.
I’m sure you all know about the 12 principles of agile development, but they are (briefly) as follows:
- The highest priority is to satisfy the customer through continuous delivery of valuable software.
- To welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to, and within a development team, is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity — the art of maximising the amount of work not done — is essential.
- The best architectures, requirements, and designs emerge from self-organising teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
There are three main principles that drive the ScrumMaster role — and these are numbers 5, 6 & 12.
Building projects around motivated individuals is hard. Giving them the environment and, moreover, the support they need to get the job done is hard. Bringing the team together to reflect on how they become more effective is hard. Getting the team to modify its behaviour based on feedback is also hard.
Giving these specific principles to a Product Manager to oversee is problematic and I am going to tell you why.
Product Managers/Owners are concerned with their product. We are predominantly concerned with the quality of our product. Are we building the right thing at the right time? What should we build and why? We are concerned with ROI (If we build this one thing, will we get a better return than if we build this other thing?). We live and breathe great products and we want the maximum gain from our investments. Yes, we want our products to be delivered on time, on budget and to the highest quality. (One ex-manager called this ‘The Pillars of Project Management’.) But our focus is generally on ‘the thing’, rather than the people building the thing.
Some of us (Product Managers) may be diplomatic folks, but we should also hold our hands up to some of our failings — the skills needed to be a great Product person aren’t necessarily the same skills needed to produce the happiest teams. If you are spending the majority of your time creating happy, positive environments with a lack of blockers for the team, you are not going to be able to spend the right amount of time on your product vision and this will suffer. If you swing the pendulum the other way, and concentrate on your product vision, the team will suffer because they have no one to stand up for them and their needs. It’s often a case of ‘Damned if you do and Damned if you don’t!
So you may end up in a situation where you either have a great product vision and a pissed of team, who you don’t spend enough time with, or a happy team and a product vision running off into the woods with no idea when it’s coming back! It is very hard to strike that balance and there is a reason, with these fast development cycles (especially in Scrum), why the Product Owner and ScrumMaster roles are separate.
As I also love to paraphrase agile Demi-God Mike Cohn (and his mountain goats), he says:
While a product owner is determining what to build, the ScrumMaster is helping the team work together so they can. — Mike Cohn, ScrumMasters should also not be Product Owners.
Determining what to build and enabling a group of individuals to work together as a team requires a very distinct focus.
As Brian De Haaf puts it, the Product Manager’s focus is on what is being built — the ScrumMaster’s focus should be on how the team work together to achieve that result.
The scrum master drives the team’s self-organisation and then removes distractions, impediments, or roadblocks to drive team progress. Impediments may be external to the team, like lack of support from another team, or they could be internal, like the product manager not knowing how to correctly groom the product backlog. He may also facilitate regular team meetings to ensure that the team is making regular progress. — Brian De Haaf, The Product Manager vs The ScrumMaster.
The product manager owns the product backlog and decides what goes into the product backlog and, equally important, what does not. She maintains the product backlog and orders the items in the backlog to deliver the highest value. She also works with the team and the stakeholders to continuously improve the quality of the product backlog and everyone’s understanding of the items it contains. She decides when to ship the product, with a preference toward more frequent delivery. — Brian De Haaf, The Product Manager vs The ScrumMaster.
As an industry, we need to realise and talk openly about the value of both roles and not cut corners. ‘Scrum’ was created to give the team more ownership than traditional waterfall development methodologies could at the time. Though the principles of ‘Agile’ do not have the ScrumMaster role etched in blood, the role came out of a need for the team to have a servant/master manager. They recognised that it was not always easy to self-manage and often promoted some of their more organised technical people into the ScrumMaster role to help with managing expectations around delivery. The role was created to give the team some structure, but ultimately to support and ensure the health of the team.
Coaching teams new to agile takes time and commitment, which a Product Manager would have to take a sizeable hit on quality to achieve. A Product Manager coaching a team to meet their standards for delivery is only going to be seen by the team as total control over their workflow — and it is reasonable for them to feel this way.
Add a ScrumMaster into the mix and things suddenly start to get a little more balanced. You have a voice for the Scrum team, especially in environments where teams aren’t experienced in agile or unable to speak up for themselves. A designated ScrumMaster (or an Agile Delivery Manager, where a Scrum methodology is not in use) is much better for the ‘health’ of the team — especially in coaching them to overcome impediments and encourage ownership and accountability of their commitments, as well as providing much needed encouragement and coaching on collaboration between team members. You have a person to work with the team to determine (honestly) what they can do within their sprint — and to feed this back to Product Manager/Owner for them to then decide what features to prioritise or bump back to the next iteration. Everyone is happy!
From the perspective of a person who has pitched for headcount for a ScrumMaster role, it is difficult for business leaders to understand the value of this person within the organisation. What are they accountable for? What are their objectives? How much money are they going to bring to their business?
So how can you quantify a role whose sole purpose is essentially to ensure the health of the technical team? What monetary value can be ascribed to this? As a business manager, how can you sell into your seniors that this is an essential role? What does the ScrumMaster do that a Product Manager or even a Project Manager couldn’t do?
I guess I can use the analogy of a coffee machine. A coffee machine is not an essential part of your office. But if you do not have a coffee machine, your employees will leave your office regularly to get a coffee. They may bring in their own machines from home. You will not know where your employees are and whether work is getting done because they are off getting their coffee and there’s no one around to ask. But if you have a coffee machine in your office and you need an update on progress, first thing in the morning, all you need do is walk to the coffee machine and ask. The ScrumMaster is that coffee machine that everyone centres around to discuss their work. The ScrumMaster, like the coffee machine, makes everything better for the team.
Product Managers are great and have immense value for organisations, but we should be honest enough with ourselves to admit that sometimes we are the impediment to the team. Sometimes the ScrumMaster has to manage us to get the best from the way we interact and negotiate with the team.
To leave on a Mike Cohn quote, once again, on a pirate ship, we don’t expect the Captain and the Quartermaster to perform the same tasks!
Star tasks (The Captain) –the strategic work of deciding which ships to attack, commanding the crew during battle, negotiating with other captains, and so on.
Guardian tasks (The QuarterMaster) –the operational work of distributing their pirate booty, settling conflict, punishing crew members, and organising care for the wounded.
So when you ask me how I feel about no longer taking on the ScrumMaster role, the above is why I’d be ‘Frankly, relieved.’ Because being a Product Manager takes commitment and you can’t do it at 100%, if you’re also trying to be the team’s ScrumMaster.
Thanks for reading! Feel free to leave me a comment with your thoughts!