Chris Lukassen — November 26, 2019 
What is a Gatekeeper?
The Gatekeeper is the single point of contact between the Scrum Team and the outside world. The Gatekeeper tends to block all connections between the Development Team and its stakeholders; all communication goes through him/her. The Gatekeeper may be acting as or really being an important Product Owner, because (s)he has to answer all the Development Teams’ questions, but really not having much time for the team. Also, the Gatekeeper typically wants to sign off on all the requirements. There’s nothing wrong with “protecting” the Development Team from the outside world. There’s nothing wrong with helping the Development Team to stay focussed. However, if you’re the single point of contact between the Development Team and the outside world… then you’re missing the point of being a great Product Owner.
A gatekeeper is a person who controls access to something, for example via a city gate. Various figures in the religions and mythologies of the world serve as gatekeepers of paradisal or infernalrealms, granting or denying access to these realms, depending on the credentials of those seeking entry. Acting in this capacity these figures may also partake of the status of watchman, interrogator or judge. In the late 20th century the term came into metaphorical use, referring to individuals or bodies that decide whether a given message will be distributed by a mass medium.
— Wikipedia, Oktober 2019 —
The Gatekeeper is also referred to as the protector, guard, shield, gateway or single point of contact.
The Product Owner as a Gatekeeper
With the many Product Owners and Product Managers we have trained and coached in their daily practice, we’ve observed the following patterns in Product Owners that we would classify as Gatekeepers:
- One way of being the Gatekeeper is to block all interactions with the outside world. The Gatekeeper has learned that more work can be delivered when the Development Team can focus and focus is what the Gatekeeper can offer them. The Gatekeeper is great at keeping stakeholders away from the Development Team and blocking all communications. The agreements made between the Gatekeeper and the Development Team(s) is that all questions are posed to the Gatekeeper.(S)he will consult with the stakeholders if it is neccesary. No questions are asked to users, stakeholders or — let alone — customers, directly.
- Another typical Gatekeeper pattern is that all the ideas, wishes, demands and work should be asked to the Product Owner directly (preferably in a User Story format of course). All new ideas and wishes from the stakeholders to be addressed to the Product Owner and (s)he knows about every single idea before the Development Team does. There is not even a single, little, tiny and small bug that will go to the Development Team, without the Gatekeeper knowing about it.
- Besides gatekeeping work, there is also the Gatekeeper that blocks feedback from the stakeholders to the Development Team. These Gatekeepers tend to find it a waste of time when the Development Team spends 2–4 hours on a Sprint Review, because that is time they could have written more code… And so the Gatekeeper decides to host the Sprint Review by him- or herself, ask for and receive the feedback from the stakeholders, users and customers him- or herself and afterwards share that feedback with the Development Team(s).
- Although the previous Gatekeeper type is written about the Sprint Review as an example, the same goes for the Gatekeeper who never lets the Development Team talk to customers, because “They’re developers… They don’t know how to talk to customers… I’ll talk to customers instead and I’ll translate the information for them…”
- Another great way of being a Gatekeeper, is to make sure the Development Team doesn’t know (at all) who the customers, users and stakeholders are. “With great power comes great responsibility” and “knowledge is power” are two quotes that suite this Gatekeeper well. By keeping all the important information (about the company, stakeholder needs, market, customers, user needs, personas, etc. etc.) to him- or herself, a Product Owner might become (a bit too) important. Or as we actually see it: become a bottleneck in the development process…
- The last great pattern of being a Gatekeeper is to make sure that you have to sign-off on all the requirements and deliverables that the Development Team produces. There should be nothing that is delivered or shown to customers or released/deployed to production without the Gatekeeper signing off on it first!
- Other associated behaviors with the Gatekeeper type of Product Owner are: acting as a go-between (carrier pidgeon) between the Development Team and the stakeholders, acting like the tester who has to approve everything delivered, Focussing on delivering all the requirements (instead of the most value), Being an information blackhole, managing via spreadsheets, being a people utilizer, maximizing output and being a team coordinator.
The results/effects of acting like a Gatekeeper
Obviously, not all (Product Owner) Gatekeepers are the same, and not all the results/effects may be visible in your context. That being said though, what we typically observe when Product Owners act like Gatekeepers is:
- Focus on short term results;
- Little to none focus on long term outcomes (TCO, ROI, P&L, etc);
- You are slowing the Scrum Team down;
- The Scrum Team remains to be dependent on the the Product Owner, which will eventually slow the team down;
- The Scrum Team isn’t learning and obtaining more business, domain, customer and product knowledge. This prevents them from making better, faster and more informed decisions and herewith increase self-organization;
- Being the carrier pigeon leads between the Scrum Team and the stakeholders transforms the original feedback and message from the stakeholders, which gets delivered to the Scrum Team differently. The most valuable feedback for the Development Team, is the feedback they receive from the stakeholders directly. Don’t be a filter between them;
- The Development Team isn’t learning to be self-organizing their own work, they won’t be taking ownership (over planning, results, quality, etc) and controlling everything will cost you a lot more work and time yourself (which you can’t spend on more important things);
What you can do to move away from this stance
If you are a Product Owner or product manager, and you’re experiencing that you’re being held accountable for delivering projects or output (instead of value and outcome), then here’s what you can do (besides giving us a call of course):
- Use existing (governance) structures, such as the Steering Committee meetings, to move towards Scrum. For example, what has worked well for us in the past is to (without telling them) start doing the Sprint Review during the Steerco meetings. At first, you do it yourself and instead of using the traditional Steerco agenda, you start showing the product, showing the roadmap, start talking about the vision, start talking about value delivered and feedback. Later, you can slowly start inviting more people (Scrum Master, Development Team, other stakeholders) to the ‘Steerco’ which has actually become the Sprint Review already. In many organizations, it’s easier to change the governance afterwards, when people got used to the new way of working, instead of changing the governance upfront, when the least is known…
- Start talking about different things with stakeholders. Stop talking about progress percentages, about deliverables and about the expected release dates of new features. Instead, start talking about the goals that you want to achieve. Start talking about the product vision and what you think contributes most to achieving the vision. Take initiative and create your own roadmap for the product, explain why you’ve put goals and features in a certain order. So basically, start taking ownership of the product and create your own plan! If you don’t make your own plan, you will become part of someone else’s plan…
Business & Finance Articles on Business 2 Community
(82)
