Where are the ScrumMasters?
WHERE ARE THE SCRUMMASTERS
On my work as an Agile trainer and coach I’ve met quite some good Agile developers: people that are able to collaborate with others, embrace technical excellence, spend time talking to customers and understanding their problems rather than ‘just coding requirements’, master state-of-the-art engineering techniques and stay open to new learning opportunities.
I’ve also met a few great Product Owners. Usually coming from a Project Management background, they foster communication between customers and developers, keeping a common vision of the product and navigating the perils of corporate politics when it comes to project portfolio management and backlog prioritization.
I’ve come to believe that a good Product Owner is sometimes all you need in order to make an Agile transformation succeed: if they can help your company build a proper, iterative and incremental, prioritized, tiny-sliced backlog, and then keep it clean and protected, it’s very difficult that you can’t be Agile.
Unfortunately, when it comes to ScrumMasters, we are talking needle in the haystack. The rare combination of technical knowledge, Agile lore and off- the-chart interpersonal and human skills has no precedent in the existing workforce. Developers trying to become good ScrumMasters usually lack the soft-skills needed to coach teams and support their people.
Project managers trying to become good ScrumMasters very rarely can coach their developers into better technical skills. Both developers and managers and are usually too short-term concerned to invest their team’s time into learning, growing, bonding, innovation, quality, creativity, motivation and other team-related aspects that have no immediate effect on sprint velocity or project performance.
It is no wonder that ‘ScrumMaster-less Scrum’ is one of the most common ‘Scrum-buts’ that I find when assessing Agile transformations. Considering that many companies obtain great benefits from this approach, it’s even tempting to consider ScrumMasters as ‘nice to have, although optional’. In fact, several Agile frameworks like Kanban, Cristal or Lean Software Development do not prescribe a ScrumMaster or Agile Coach role – and there is no mention of these in the Agile manifesto or in Nonaka and Takeuchi’s seminal article that inspired Scrum itself.
To make things worse, Scrum-bashing has become a major sport on the Agile community. With 75 to 80% of the Agile transformations based on Scrum, it never ceases to amaze me how people dismiss Scrum as ‘prescribed process’ ‘past practice’ or ‘one size does not fit all’.
Some of the people who dismiss Scrum have done Scrum for a long time up to the point where they did not need any framework at all to be Agile (ShuHaRi anyone?), but they expext other to arrive to this Agile nirvana without the years of practice they took.
On the other hand, most of the people dismissing Scrum, I’m afraid, might have never experienced a successful Scrum implementation. Anyway, as some big-names or just popular bloggers and forum participants encourage getting rid of frameworks, it’s easier for Agile wannabes to think that Scrum and ScrumMasters are dispensable.
Under my perspective, when Sutherland and Schwaber created Scrum they defined a core of practices that they considered the minimum to have a successful Agile transformation – not ‘implementation’, the goal here is not to pass a process checklist, but to be Agile.
There are indeed some practical things that you might get rid of – Alistair Cockburn call them barnacles, things that get attached to the Agile boat and, while some of them might be useful, too many of them will make the boat go slower. Some well known barnacles include user stories, point-based estimates, burn-down charts or (sorry for this one) Test Driven Development (yes, you can be Agile without TDD). But, again, Sutherland and Schwaber defined a Scrum core with just eight major practices:
• Cross-functionalself-organizing team
• Product Backlog
• Potentially shippable product increment (time-boxed iterations and iterative incremental development)
• Sprint planning
• Daily Scrum
• Product Owner
• Scrum Master
As I said, this is the Core, the bare minimum to claim a full-Scrum implementation. You would believe that, if ScrumMasters were optional, they wouldn’t have made it to the ‘top eight’ list. In very few ocasions – if ever – have I found people questioning the other seven items in the list. Even if you want to get rid of some of the most popular ‘barnacles’ like, for instance, the Team Board – which I’m a huge fan of – they will scream and cry as if you were reinstituting Waterfall.
How come that, when it comes to ScrumMasters, people are mild about the lack of proper ones? I think there are a few reasons for this.
First, there is the understanding of the ScrumMaster role. The job description is not very comprehensive: ‘does whatever it takes to make the team successful, such as removing organizational impediments, facilitating meetings or acting as a gatekeeper so no one unnecessarily interrupts the team’s work’. That’s pretty much it – few additional explanations on the Scrum core papers. The misunderstanding of this description leads companies to ask their ScrumMasters to ‘increase velocity’, ‘report project progress’ or ‘conduct performance review for team members’.
Another reason for the shortage of proper ScrumMasters might be the lack of appropriate candidates in the job market, or even the absence of mentor or role models. If you want your developers to excel, for instance you can direct
them to Uncle Bob, Ron Jeffries, Kent Beck or Martin Fowler. But who would be the authoritative source of ScrumMastership for your ScrumMasters? Sure, there are some coaching resources (I would definitively recommend Lysa Adkin’s work), but that’s just part of the job, and not the only way to address it.
Finally, it’s my belief that companies are having serious trouble to understand, see and even measure ScrumMaster value. Managers are asking ‘how do you measure a ScrumMaster’s performance?’. To this, I can only answer with Jurgen Appelo’s argument: tell me first how do you measure your own performance as a Manager. As for the benefits, I would quote Lao Tzu: ‘A leader is best when people barely know he exists, when his work is done, his aim fulfilled, they will say: we did it ourselves’. Unfortunately, this means that sometimes the contribution of great ScrumMasters can be obscured by the great, tangible performance of the teams they are coaching.
So, as a final advice, I would say that if you want to know where’s fire, you’d probably follow smoke, and in the same sense I feel that candidates for great ScrumMastership can be found where great teams are, usually leading them from behind, as Nelson Mandela described it:
I always remember the regent’s axiom: a leader, he said, is like a shepherd. He stays behind the flock, letting the most nimble go out ahead, whereupon the others follow, not realizing that all along they are being directed from behind.
Thank you so much for reading my post, if you want to follow my work you can find me here.
All the best,
Working with Evolution4all
evolution4all has developed the “Organisational Mastery” product. The aim of this product is to create a coalition that drives change and internal innovation alongside shared knowledge throughout the organisation. It’s extremely suitable for companies that want drastically improve the alignment between executive leadership and delivery teams.
We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.Take The Test