What’s Wrong with Agile Coaches and Scrum Masters?

Agile coaching and Scrum Master roles have proliferated like mushrooms after the rain. These positions seem alluring, sprinkled with buzzwords and the promise of transforming the workplace. But strip away the jargon, and we’re left with a troubling question: Do these coaches and Scrum Masters genuinely know what’s going on, and what they’re doing? The sad answer, often enough, is no.

Are Senior Managers Supporting Them?

Senior management’s support can make or break the efficacy of an Agile Coach or Scrum Master. Unfortunately, a lot of the time, the upper echelons of an organisation fail to back these roles, turning them into totally bullshit jobs. Without this crucial buy-in, coaches and Scrum Masters operate in an organisational vacuum, making their jobs impossible.

Why Are Teams Skeptical?

It’s not just senior management. Development teams themselves are often less than thrilled to interact with Agile Coaches or Scrum Masters. The reason is straightforward: They don’t see the value. When the so-called Agile experts cannot coherently explain their methods or bring palpable improvements, why should teams give them the time of day?

Confusion: Methods vs. Methodologies

Another concern arises when Agile Coaches and Scrum Masters confuse methods with methodologies. A method is a specific procedure for accomplishing something. In contrast, a methodology is a system of methods used in a particular area of study or activity. Knowing a few Agile methods doesn’t mean one understands Agile methodology. This lack of deep understanding reveals itself quickly, leading to flawed advice and a loss of credibility.

What’s the Way Forward?

The situation is hopeless. Even in the extremely rare case that developers and senior management both lend their wholehearted support, adopting Agile delivers precious few benefits.

Summary

In conclusion, it’s easy to assign titles and make grand statements about transforming work culture. What’s challenging is actually understanding the philosophy, methods, and methodologies that make such transformations possible. Until Agile Coaches and Scrum Masters abandon their game—and get redeployed into more productive roles—the empty promises of Agile will continue to seduce the ignorant and unwary..

I completely agree with the statement that Scrum Masters are a waste of time and money, and I don’t hesitate to say that we should get rid of them. While the Scrum approach can be somewhat effective when implemented correctly, the role of Scrum Masters often becomes redundant and futile when the culture of the organisation in which they operate is a blocker to progress.

Scrum Masters are supposed to facilitate the adoption of Scrum, invite the removal of impediments, and improve the overall effectiveness of the team. However, in most cases, the company culture and policies are too rigid to allow the Scrum Master to operate effectively. This results in the Scrum Master being unable to drive change, improve the team’s performance, or add any significant value.

Furthermore, the cost of hiring a Scrum Master can be exorbitant, and it is an unnecessary expense when a team can adopt the Scrum methodology on their own. Smart team members can learn the Scrum framework and apply it to their projects, without the need for a dedicated Scrum Master.

In conclusion, Scrum Masters are a waste of time and money if the culture or organisation in which they operate is not receptive to change (which is most organisations). Therefore, I strongly advocate for companies to evaluate their need for a Scrum Master based on their willingness to change their culture, and thus their ability to adopt and implement Scrum effectively, rather than blindly hiring one because it is the norm.

There’s no reason why these roles can’t rotate, overlap, or be shared.

*I try to avoid ever mentioning Scrum these days. I failed here. :}

Whatever they’ve been doing, most likely they’ll just carry on doing it – albeit under a new name.

Superheroine Scrum Master

The more your Scrum Masters know about Scrum, the more of a handicap they are, both to their teams and to the wider organisation.

I’ll acknowledge that some software development endeavours have been “successful”. Some of those have “used Scrum”. And some haven’t.

Of those that have “used Scrum”, what proportion have actually being doing “real Scrum” e.g. “by the book”, and what proportion have been doing “Scrum in name only (SINO)”?

And of those that have been doing “real Scrum”, and have claimed “success”, what proportion have been successful because of Scrum, and what proportion (irrespective of self-reported or externally-reported success) have been successful because of other factors, some connected with Scrum, and others more or less totally disconnected from Scrum? Factors that may have been overlooked, ignored or discounted?

In other words, where’s the evidence that Scrum, itself, is the core element of success?

I’ve never seen Scrum advocates address this elephant in the room.

– Bob

P.S. Much the same argument applies to Agile, in general. IME.

[Tl;Dr: I invented Agile in UK / Europe, independent of the USA / Snowbird folks, circa 1994].

I was running a project in Europe (Brussels, Belgium) when I first woke up to the value of “process” in delivering working software. It wasn’t the first project I’d been managing, but it was the first time in a corporate environment, with many stakeholders, and with developers and methods not of my own choosing. I have to say that the project was not an unalloyed success.

Upon completing my assignment and returning to England, spurred by my dissatisfaction, I explored the existing literature for ideas about how to do things better. And in my next few assignments I experimented with some of these ideas and began to evolve a coherent approach to software development.

Motivation

I had already long been motivated by a need to see folks able to realise their innate potential. I had often been appalled by the waste of human potential I had seen time and again in places I had worked. I was convinced there must be a better way, and set about finding it.

Influences

Key influences during this time included:

• RAD (Rapid Application Development – James Martin, etc.)
• JAD (Joint Application Development)
• Evolutionary Development (Gilb)
• Rapid Iterative Development
• Risk Management (Capers Jones, etc.)
• TQM (Crosby, Juran, Shingo et al)
• NextSTEP
• Modula-2 (Wirth)
• Eiffel (Meyer)
• Objective-C (Cox)

The Roots of European Agile

By the time I came to work with the CFO of Barclays, running some internal projects at Barclays head office, I had the kernel of an approach that today we’d label “Agile”. This was 1994.

As you may see from the influences listed above, I was already leaving the waterfall / V-model camp and beginning to favour iterative and incremental approaches.

Even in these early days, the results were outstanding.

Continuing to apply and evolve the ways of working I discovered at Barclays, I then did a tour of some of the major merchant banks in the City, where proven ideas for improving their software development results found some favour.

A couple of years later found me at Sun Microsystems’ UK Java Center, bringing these development approaches to Sun’s major corporate clients looking to transition their development teams into the Java ecosystem.

At this time I began referring to my now well-formed approach as “Jerid”.

Note on the Name

Jerid grew out of two complementary initiatives I had been running for some years named “SPEAR” and “BEAR” – Software Process Engineering And Reengineering, and Business process Engineering And Reengineering. SPEAR consisted of many of the techniques I had found useful through years of experimentation and application, packaged into a coherent whole. But SPEAR was more an umbrella concept, with different flavours of specific development approaches underneath – most notably Jerid.

In case you’re wondering, “Jerid” is a kind of javelin (throwing spear) used in games played on horseback in certain Muslim countries in the Middle East. It was also a somewhat convoluted acronym for “Java Enterprise Rapid Iterative Development”. Jerid later evolved into “Javelin”.

The Heart of Jerid

Jerid was founded primarily on ideas from risk management and rapid and evolutionary iterative development. By 1997 it had evolved to a point where, with hindsight, it looked circa 80% like Scrum was to look some years later. Two-week iterations (time boxed), sprints, sprint goals, sprint planning, retrospectives, etc.. I had independently invented “Agile” software development in Europe some years before the name itself was chosen at Snowbird, USA in 2001.

The core difference between Jerid and e.g. USA Agile/Scrum was Jerid’s emphasis on risk management. Jerid projects ensured that the major risks were identified and controlled. For me, this is the essence of any Agile approach – managing and controlling the major risks – both those common to all software development projects and those specific to each individual project.

We continued to apply and evolve Jerid during the late ’90s, at Familiar and its clients, until my departure from Familiar circa 2000.

Since then I have worked with a large number of different companies, large and small, helping them discover the fundamental principles underpinning iterative and agile approaches, and evolving practices and ways of working from those principles.

Acknowledgements

I’m very pleased to be able to acknowledge the contributions made to SPEAR and Jerid by many folks along the way. Although none of this would have happened without my input, their help and support was invaluable to me in evolving my understanding of software development, and later, the intersection of software development and general business.

Disclaimer

I’m pretty sure other folks also invented their own takes on the Agile theme before it became known by that name. Maybe even before I did. I’d be delighted to hear from anyone who believes they fall into that category.

Also please note that many of the strands of the thing that has become known as “Agile” existed long before I even got started in the field of software development methods. We all owe a debt to those many pioneers who were pushing the envelope and challenging accepted wisdom back as far as the 1960s and 1970s, if not before.

– Bob

Teams doing Scrum “by the book” will have a Product Owner. The Scrum Handbook describes this role thusly:

“The Scrum Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

It goes on to say:

“The Product Owner is the sole person responsible for managing the Product Backlog.”

i.e. the Single Wringable Neck.

Outwith Scrum “by the book”, many teams, Scrum or otherwise, will find themselves with a Product Owner, almost always, in practice, outside the immediate development team itself.

One characteristic common to every Product Owner role I have ever seen has been “push”. The Product Owner pushes work (features, stories, or whatever the unit of backlog) into the backlog, and thus onto the team. The Product Owner generally dictates the priorities of the work items in the backlog, too.

Here’s where the dysfunctions creep in. If we accept that we’d like to encourage intrinsic motivation in the team, and that Dan Pink’s three factors of intrinsic motivation apply (Autonomy, Mastery, and Purpose), then we begin to see how the typical Product Owner stance sucks the motivation away from the team by undermining their autonomy (they’re expected to do what’s pushed on them, with the priorities dictated), their mastery (focus is on delivery not learning), and purpose (the purpose is that of the PO, often opaque or little shared, not a shared common purpose across everyone involved).

Go Pull

I’ve seen clients where this push-oriented Product Owner role has served no one well. Not the Product Owner, nor the development team, nor the product, nor the customers. The Product Owner is worn to a frazzle trying to herd the developers, like cats, towards the outcomes he or she thinks the customers want. It’s most unlikely the Product Owner will know what features are valuable, and how they should work, before stuff gets in front of the customers anyway, and the delays in the “push” model just exacerbate this dysfunction.

Further, in the push model, developers have little opportunity to experiment and innovate. They’re often far better placed than the Product Owner or even the customers to spot opportunities for breakthrough innovations, both large and small, yet the push model basically precludes them from contributing in this way.

So why not turn it around? In my career, I’ve seen all the best products come from development teams that directly own the product. And, consequently, directly own the relationship with the customer. Often, not the whole team, as this might irk the customers – at Familiar we had one member of the development team act as “customer liaison” – a role which could rotate between team members if it started to become a chore for the person in question.

It’s unlikely the Product Owner will wish to do themselves out of a job, so how can we arrange things such that everyone has a better time than with the “push” model? And so we make even better use of the most valuable things the Product Owner has – product domain expertise and customer nous?

In the service (call centre, etc.) sector, Vanguard introduced the idea of front-line call staff taking all the calls, with limited (brief) training to handle the most common types of call, and with experts and specialists on hand to help them through handling the less common types of call as they arrive.

Transferring this idea to the Product Owner role, why not have the development team own the product, take all the decisions about features, stories and priorities – by pulling information from the customers – and whenever the development team has some questions they can’t answer themselves or in conjunction with the customers, have the Product Owner (now Product Domain Specialist or some such renamed role) on hand to pitch in and provide the missing knowledge or expertise.

I guess the Analytic minded organisations out there will feel uneasy about no longer having their hands around the Single Wringable Neck, but learning about Team Accountability might go some way to compensate for this?

So, let the teams suck (pull), instead of having the Product Owner push.

– Bob

PS Note that the above suggestion – to hand over core elements of the Product Owner role to the development team – assumes the development team owns the scope for the whole product, not just the software, and can collaborate and coordinate with other people and groups to ensure the whole product is delivered (whether incrementally for not). See also: Obeya.

Further Reading

The Transformation of O2 – A Vanguard Case Study in Reengineering Call Centres (pdf)

[Tl;Dr: Is it more, or less, effective for coaches, etc. to have technical (non-coaching) abilities?]

Over the years I’ve heard every kind of opinion on whether technical expertise is an asset or liability for coaches, Scrum Masters, and the like. Some folks, mainly executives, have sworn they would never hire a Coach or Scrum Master with technical expertise. Others, mainly coaches and Scrum Masters, have held much the opposite opinion. Those being coached have rarely expressed an opinion (although I suspect that’s because they don’t get asked, or think it won’t count, and not because they’re indifferent on the subject).

Personally, I tend to the opinion that, if it were down to me, I’d look for folks with excellent and demonstrable coaching skills, and not worry about the presence or absence of technical abilities unless they seemed intrusive and likely to interfere with the coaching dynamic. I recognise the argument that technical people lend more credibility to like-minded (i.e. technically capable) coaches because they find it easier to respect and identify with such folks. I also believe this argument to be a red herring, at least in the case where the coach or Scrum Master is effective and capable in the Coaching or Scrum Mastering skill-sets.

This is probably a good place to mention the Inner Game, and the suggestion by one of its founders, Sir John Whitmore, that “technical” knowledge and experience is a decided handicap for coaches and the coached, alike. In his book “Coaching For Performance” he tells several stories about this phenomenon, in particular that of the tennis group who, deprived of their regular tennis coach (and tennis expert) improved much more quickly under a substitute coach (with much coaching and skiing experience but no tennis experience).

Given that opinions on this topic seem all over the map, and many (mainly fruitless) discussions continue, I wonder if you have any experiences you’d be willing to share here?

– Bob

Further Reading

Coaching For Performance ~ Sir John Whitmore

When interviewing for a new Scrum Master or similar position, we can often intuit much about the position, the team and the company from those many little clues which offer themselves. But one thing often less obvious, and so, worth asking about is:

“How does the blockers’ pipeline work here?”

The key role of the Scrum Master is to facilitate the escalation (and to some extent, resolution) of blockers a.k.a. impediments – problems noted by the team but not actionable / fixable by them because the root cause lies outside their span of control.

Some organisations will already have a pipeline or process for escalating such “blockers”. Many more will not, not often understand the need for one and the role of non-team people in that process.

The prospective Scrum Master may want to see how the land lies before committing to a position in an organisation that is not ready or able to institute an effective blockers’ pipeline.

– Bob