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
• Retrospective
• 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,
Angel
Excellent post! Thanks for sharing these thoughts with us.
Thanks for your comment :)
Angel is a great guy ;)
Luis
Great post! I’ve recently became the Scrum Master and your post describe exactly what about companies how companies are currently dealing with the Scrum Master role. I would see the SM as much more than a guardian of the process. I like the concept of the SM being a coach focused on building a team with great performance. For me, being a SM is not about management, it’s about empowerment.
Great post! Thanks for sharing.
I think it’s important to establish what comes under the umbrella of ‘Agile methodologies’ and what is Scrum, one particular brand of agile methodologies, once you’ve understood that things get a lot simpler.
I blogged about this some time ago: http://www.aaronhammond.net/2014/09/this-isnt-scrum-team.html
Very good article.
Luis, do you have any statistics? It will be interesting to see correlation between pattern for SM role, company size and years of practicing Agile within the team.
Hi Vladimir, it was Angle who wrote the article… I do not have any statistics for that :(
Fantastic article long overdue. From a Servant Leader/Scrum Master’s point of view anyway…:) Thank you.
Angel,
I have a good idea where Scrum Masters might come from in the future. Imagine an excellent developer who is also a “people person” and also wants to move up the management ladder (as the technical ladder leads nowhere typically, at least in our country). These people typically get the title “team lead” or “project manager” after maybe 2 or 3 years in the organisation. Fast forward 5 years - they are maybe up the ladder and happy with their responsibilities, but in the back of their minds they regret “having lost their technical edge”.
If they were coached to become Scrum Masters instead of “team leads” or “project managers”, they would really, really do great - and they would avoid one important frustration in the future.
What do you think?
Interesting note about Kanban etc not requiring a scrum master role, I’ve worked with kanban implementations that opted to use a Scrum Master style empowerment agent / facilitator / coach and also adopted many of the ‘scrum’ ceremonies i.e. regular cadence of stand up / grooming / planning etc. Clearly there are people who value the facilitation, coaching, mentoring and guiding that a good scrum master can bring :-).