Let The Team Make The Difference

[Tl;Dr: Teams can be more effective by eschewing both Scrum Master and Product Owner – if they can count on getting the support they need when they need it.]

I’ve written before about Familiar and how we delighted both our customers and ourselves by the way we approached software development. And my recent observations on the role of Scrum Master seem to have struck a chord.

At Familiar, we had neither Scrum Masters – although using a Scrum-like approach to development – nor Product Owners. And we did just fine. Better than fine, actually. Our teams found their own ways of working, handled their own interfaces, and gained an effective understanding of customers and their needs, by themselves. With support from one or more extra-team specialists, when the team decided they needed it.

I have seen teams struggle when they have to go it alone in finding new and more effective ways of working, especially if they come from another place, like a batch-and-queue (a.k.a. waterfall), project managed, big-requirements-up-front past.

Yet teams of highly intelligent, reasonably motivated folks can exceed expectations when allowed to make their own choices, so long as they know how to call for help and can do so, quickly and often, whenever they feel they need to.

Perceived Risk

The idea that people have to be supervised is deeply ingrained in our view of work. The very notion of allowing teams their head without a Scrum Master or Product Owner to watch over them, keep them on track and generally boss them about seems highly risky. Despite all the evidence and advice, most organisations are still in no way ready to embrace self-organisation without the safety net of supervision. And with supervision, self-organsation offers hardly any advance at all.

Support

By support, I mean someone – or some number of people – that can help the team find ways past the obstacles they will regularly encounter. Some shared context is useful, so the helper(s) may have some longer-term relationship with the team, rather that just being called in “cold”. Some of the skills useful in such helpers will include Amanuensarian, coach, and therapist. I wrote a fuller list some years ago.

Given the wide range of skills that might be needed, only the very largest organisations are likely to have such people on staff.

Protection

Another often quoted aspect of the Scrum Master role is the protection he or she can afford the team, from interruptions and other disruptions. I wouldn’t want to downplay the value of this, but I would be much happier to see teams themselves more aware of the value of flow and the need to minimise interruptions – including those self-generated. Can teams handle interruptions themselves? Yes – with adequate awareness and support.

Why Not The Scrum Master

Apart from the Universal Scrum Master Failure, the very nature of the relationship between many Scrum Masters and their teams tends to an unhealthy power dynamic. Many managers – unfairly or unreasonably, in my view – hold the Scrum Master accountable for the results of the team. Naturally, then, the Scrum Master feels under some form of pressure (such as duty, self-interest, or similar) to push the team to do “better”. And, human nature and learned behaviour being what is it, oftentimes this pushing can be coercive and violent. Few realise the significant damage that such a dynamic wreaks in collaborative knowledge-work.

Undoubtedly there are (a few) Scrum Masters that avoid this dynamic. These folks appreciate the need to create an environment where the team can find motivation (to the extent they so choose) and learn. By learning, they become more effective over time. Unfortunately, the few enlightened Scrum Masters rarely find themselves in organisations where cultivating this kind of environment for their team is anything but excruciatingly difficult and painful for themselves.

Both of these conditions together – “enlightened” Scrum Masters and “fertile” organisations soil – are necessary to allow the Scrum Master role to deliver value. It’s so rare for both these conditions to exist at the same time in the same place as to mean that maybe less than 10% of situations would derive value from having someone in the Scrum Master role.

Why Not the Product Owner

The issue of power dynamics has less impact in the relationship between teams and their product owners. Although the nature of that relationship is very varied, more varied even than that of Scrum Master and team.

I reject the Product Owner role for different reasons. Specifically:

• Setting up a division of responsibilities increases the likelihood that the team will – in practice – relate less well to customers and users, and their concerns.
• Having a distinct Product Owner reduces the opportunities for emerging technical possibilities to inform the direction of evolution of the product. Put another way, teams often uncover opportunities for new, as-yet unthought-of features, and directions for the product, but for a host of reasons these opportunities go by the board.
• The Product Owner role allows for “absentee” Product Owners, where key customer intelligence is not gathered, or not passed on to the team. When the team is handling these matters, it’s less likely for such matters to get overlooked.

Summary

In summary, if I were on a development team, or responsible for one, i’d want neither a Scrum Master nor a Product Owner. I would instead take pains to ensure that the team had a wide range of skills and experience at its beck and call, and the know-how of how to pull such skills as it needed them. To reduce delays, this may mean having one or more such people on hand, close-by, at all times. This does not mean a Scrum Master.

– Bob