Listen to this blog post as a podcast:
Is Scrum failing users?
There are six times as many Certified ScrumMasters as there are Certified Scrum Product Owners. So, is Scrum failing users?
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 stopped regularly communicating with users, who were probably consulted only during the initial requirements capture phase. So, more often or not, the decisions about what functions get dropped are taken by the project manager, either alone or perhaps in consultation with a senior stakeholder.
In my experience, the performance of a project manager is most likely to be judged on whether their project comes in on time and on budget, rather than on the project’s intrinsic quality or its ability to fulfil the needs of its users. So, what else can a project manager be expected to do other than to bring a project in on time and on budget by cutting or compromising functionality 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 the Userfication approach, which puts the needs of the user at the centre of all decisions about what a service or product should provide and how it should behave.
The promise of Scrum
The Scrum approach to software development promises to handle this time/cost/scope dilemma in a far more user-focused way.
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.
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.
And, if one of these roles takes precedence, the essential role in Scrum 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.
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 rather than a manager as such. (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.)
This rebalancing of roles seems to offer so much promise to those of us who wish to follow the principles of Userfication. 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 the 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?
A few weeks before Christmas, 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 best I’ve 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 extrapolating one’s own experience to the universal situation. After all, the behaviour of my friends and colleagues – hardly the largest sample size imaginable – might not be typical.
250,000 people have 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 subtly different question) genuinely shocked me:
- 250,000 people have received Certified ScrumMaster training;
- 43,000 people have 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. For example: at the time I write this article (the first week of January 2014) there are 35 ScrumMaster roles offered on the Jobserve website, but only eight for Product Owners; a ratio of four to one.
Wherever the explanation for these figures, there seems to be a real imbalance here, potentially signifying a widespread and real problem.
What’s going on?
There could be a lot going on here that would explain this.
Let’s look at those recruitment figures first. To recap – the Jobserve website currently has 35 ScrumMaster roles on offer, but only eight for Product Owners. You might think that this might be just a complete coincidence, a temporary aberration. But, take me on trust here – this is a trend I’ve observed for months now and the ratio is pretty constant.
So, why are there more roles for ScrumMasters than for Product Owners? There is, after all, surely, a need for an equal number of each role if Scrum projects are to staffed properly.
Remember, 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 in a single Scrum project, 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 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 is then never seen again.
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. And, thus, the traditional role of the all-powerful project manager is reborn in Scrum.
“Meet the new boss / Same as the old boss”.
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?
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 Userfication?
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 Userfication, 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?) And, software is often the cornerstone of the provision of a service – just think of your bank’s online account management, or the UK Government’s Universal Credit system.
Software is often the cornerstone of the provision of a service – just think of your bank’s online account management, or the UK Government’s Universal Credit system.
That is why I, with many others who had seen user requirements treated so badly in waterfall-managed projects, was initially so enthusiastic about Scrum. The Product Owner would 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.
Sadly, however, in its day-to-day application, Scrum seems often to tragically inherit and replicate the unequal importance allocated to the roles of project manager and business/requirements analyst (read ‘Product Owner’ in Scrum) evident on so many waterfall projects.
Those of us who want to see the user really put first need to look elsewhere for the fulfilment of our goals, for Scrum is currently failing users.
On projects where either the Product Owner is uncertified, 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 never being fulfilled. Those of us who want to see the user really put first need to look elsewhere for the fulfilment of our goals, for Scrum, on these projects, is currently failing users.