Software projects often find themselves running behind schedule or over budget – or both.

And often, when time, cost and scope need to be adjusted to bring a project back into line, it’s the scope that gets cut, rather than the budget or timescale getting increased.

But, who decides what functions get dropped?

By the time many projects get into trouble, they have ceased to regularly communicate with users, who were probably consulted only during the initial requirements capture phase in any case.

So, more often than not, the decisions about what functions get dropped are taken by the project manager, either alone or perhaps in consultation with a senior stakeholder, and with little regard to the consequences for the user. After all, the user is rarely around to give the project manager a piece of their mind.

It’s the very antitheses of a user-centred design approach, which puts the needs of the user at the centre of all decisions about what a service or product should provide.

The promise of Scrum for user-centred design

The Scrum approach to software development promises to handle this time/cost/scope dilemma in a far more user-focused way.

While the traditional approach to project management vests by far the lion’s share of power with the project manager, the Scrum framework makes it clear that there are two leadership roles in Scrum; the ScrumMaster and the Product Owner.

Surely, the essential role in Scrum is that of the Product Owner, the person with ultimate authority over what product features are developed and in what order; the constant champion of the needs of the user.

And, if one of these roles takes precedence, in Scrum it is surely that of the Product Owner, the person with ultimate authority (through the maintenance of the product backlog) over what product features are developed and in what order; the constant champion of the needs of the user and what is of most value to them.

The role of the ScrumMaster, on the other hand, is deliberately subverted in comparison to the traditional project manager, instead being cast as a facilitator to the work of the Product Owner and rest of the Scrum team. (During an aside at one Scrum training course, I heard the role being described as a “subservient project manager” which seemed to me quite accurate.)

The iterative, short-run cycles of development used in Scrum (its so-called ‘sprints’) should cast light on project performance problems much sooner than usually happens on a waterfall project. And, when decisions need to be made about time, cost and scope at the next sprint planning meeting the Product Owner is there to ensure that the most valuable functions for the user (with which he or she should be in regular contact) are not sacrificed for want of a champion. The needs of the user – theoretically – should always come first.

It all promises so much. But, does Scrum deliver?

Where are the Product Owners?

Some while ago, an erstwhile colleague of mine let it be known that he’d become a Certified ScrumMaster (CSM).

I was glad for him; but, I was also a bit surprised. In my time working with him, he always seemed a natural requirements analyst – in fact, possibly one of the most promising I’d ever come across. His commitment to ensuring that the best possible product was built for the user was obvious and admirable. So, I’d always imagined that, should he take a Scrum certification, it would be to become a Certified Scrum Product Owner (CSPO).

It got me thinking about other people I know who have Scrum certifications. All of them are ScrumMasters. None of them are Product Owners. In fact, I’m the only CSPO that I know of in my circle.

A widespread problem?

There is always a danger in thinking that one’s own experience is universal. After all, the behaviour of my friends and colleagues — hardly the largest sample size imaginable — might not be typical.

By 2014, 250,000 people had received Certified ScrumMaster training, while only 43,000 have received Certified Scrum Product Owner training.

So, I contacted the Scrum Alliance to find out how many certified ScrumMasters and Product Owners there were. Its answer, albeit to a slightly different question — how many people had received training in each certification since their joint introduction — genuinely surprised me:

• 250,000 people had received Certified ScrumMaster training;
• 43,000 people had received Certified Scrum Product Owner training.

That’s a ratio of almost six ScrumMasters to every one Product Owner.

Surely, there should be a roughly equal number of ScrumMasters and Product Owners – shouldn’t there?

Recently, I’ve seen the same phenomenon on job recruitment sites, where the number of ScrumMaster roles on offer seems to be far in excess of the number of Product Owner roles on offer.

Whatever the explanation for these figures, there seems to be a real imbalance here, potentially signifying a widespread and real problem.

What’s going on?

Even if a project uses many Scrum teams, and adopts a ‘Scrum of Scrums’ approach, each and every Scrum team is meant to have a ScrumMaster and a Product Owner, so we shouldn’t be able to explain away this imbalance by stating that the adoption of Scrum on larger projects, using many Scrums, means more ScrumMasters are needed than Product Owners.

Here are some better possible explanations:

Product Owner opportunities are filled much more quickly than ScrumMaster ones, so they are advertised for less time.

Unlikely. Remember, there are six times as many certified ScrumMasters than Product Owners out there, so, the very opposite should be expected, with a large body of certified CSMs chasing each advertised ScrumMaster role, and a dearth of CSPO chasing the Product Owner roles. In any case, I have found no evidence on the recruitment websites that the ScrumMaster job adverts are re-advertisements for previously unfilled roles.

Product Owner vacancies are filled internally by organisations, while ScrumMasters are recruited externally.

Much more likely. After all, the Product Owner needs to be knowledgeable about not only the product, but its users, its market, and its stakeholders. He or she also needs to act as the main communications link between the project, its stakeholders and its users. Accordingly, it is perhaps likely that in many cases the best candidate will be an internal one.

But, I feel that the situation is rather more complex that this simple hypothesis suggests. Remember that there are far fewer certified Product Owners than certified ScrumMasters. So, how confident can we be that these internally recruited Product Owners are going on to become trained Certified Scrum Product Owners? And, furthermore, how many of these internally sourced Product Owners will come to their role unencumbered by a multitude of existing responsibilities – will they be able to devote all or the majority of their time to being a Product Owner to a single Scrum team, the same way a fresh recruit could do?

Scrum teams don’t have Product Owners.

It’s depressing to contemplate, but apocryphal evidence suggests that this is, perhaps, much more likely than might be commonly realised. Remember, a real Product Owner needs to be a regular, committed member of the Scrum Team, not just a figure who articulates some nebulous and insubstantial ‘product goal’ at the start of the project, and then is never seen again.

The danger is that the traditional role of the all-powerful project manager is being reborn in Scrum.

However, just that might be happening, with, usually, a senior manager acting as a Product Owner but only in the most fleeting and superficial way, while delegating the day-to-day product ownership duties to someone else — most often, the ScrumMaster. The danger is that the traditional role of the all-powerful project manager is being reborn in Scrum.

So, finally, how do we explain the fact that almost six times as many candidates take the ScrumMaster certification compared to the Product Owner certification? Well, surely the answer lies in the recruitment figures. Is it surprising that if people see that ScrumMasters are in much greater demand than Product Owners that they should work for the certification that will best equip them to get a job?

What does this have to do with user-centred design?

In the introduction to his classic book on software development, ‘The Mythical Man-Month’, Frederick P. Brooks offered the following observation about what is the most crucial element of a successful software project:

“I believe the critical need to be the preservation of the conceptual integrity of the product itself.”

At Required Experience, we agree with this analysis, particularly if the “conceptual integrity” of the product is seen as its ability to successfully meet the needs of its users (why else would you develop a software application in the first place?)

That is why I am, with many others who have seen user requirements treated so badly in waterfall-managed projects, so enthusiastic about Scrum. The Product Owner should champion the needs of the user within the Scrum Team, with the ScrumMaster acting as an effective and efficient facilitator, rather than an all-powerful wielder of arbitrary rule.

But, on projects where the Product Owner is uncertified or unfocused, or, even worse, where the role is left unfilled or is taken up by the ScrumMaster, all the promise for the better treatment of user needs promised by the Scrum approach is in danger of not being fulfilled.

Unless we all take the role of Product Owner more seriously, Scrum will be failing users.

Share this post