Background

I've been working in and out of the world of Agility since 2011. Either as a Scrum Master or in some capacity as a consultant for various teams and companies looking to improve their way of working, I've always found a baseline in the Agile Manifesto and a path to some concrete implementations.

Scrum is one of those implementations and I used to be a great advocate of it. What happened? Well, starting from Dave Thomas' famous presentation and the realisation that of all those involved in the Agile Manifesto, the only ones still supporting it are those that have managed to turn its implementations into a business, it's impossible not to notice how good intentions have been corrupted by parasites that don't just syphon dollars off the gullible but at the same time promote counterproductive mindsets or oversimplifications.

With that in mind, here are some of the most toxic ones - so hard to dismantle that I've decided to stop trying.

1. Language

One thing that either of the two entities in charge of Scrum as a framework definition (scrum.org and scrumalliance) have tried to hammer in during their trainings is that language matters.

Language is a way of underlining changes and to help drive new mindsets, which makes using the correct terminology (all the new words that Scrum introduces) under the meaning defined by the framework - to make sure we all speak the same language and to have a baseline of understanding.

Aside from people always assigning a slightly different meaning to the same terms, a poisonous use is that plenty of people use cheap analogies to explain new terms. Example: a Product Owner is like a Product Manager but mixed with a Project Manager and some other things. This approach leaves people with the impression that not much is really changing, it's same old just very slightly different - something that they will in turn perpetuate.

2. Stakeholders

One thing that people ignore is the definition of stakeholders. In the vast majority of cases I've seen, people tend to think that stakeholders = customers. Which in turn makes the definition flexible and different depending on your time of business (outsourcing, product company, consultancy, etc). This is dangerous because it always results in some people going out of alignment with everyone else on the project.

Some common stakeholders:

• the entire scrum team: it's easy to forget that the team is the first and foremost stakeholder. All team members have an obvious stake in the project since it's about their career and livelihood.
• business customer: by business customer I understand the people that have a business use for the product. Usually these people also have a hand in its design, features and usually act through the PO in some capacity.
• end users: the most obvious stakeholder, they perform some beneficial activity through the product and usually pay in some form for making use of it.

The team has a very obvious and important stake in the project success. Though they may have other drives, interests and constraints, team members must go with the fact that they are also stakeholders, as much as anyone - which gives them a seat at the table.

In many cases I've seen, the generic attitude towards the stakes of the development team can be summarized on the customer's side by this stance: I'm paying you so shut up and code.

In my experience, the most successful projects are those where the alignment includes the development team as stakeholders and their contribution includes much more beyond coding.

3. Product Owner role

By far the most toxic misconception is the one that claims that the Product Owner is a "representative of the customer" (sometime literally).

This is dangerous because it induces the mindset that the PO is (as per #1) nothing more than a Manager there to push the team and to represent the customer's interests.

However, this is a symptom of a lack of alignment and poor stakeholder definition. Everyone's interests should be the same: a quality product on the market. In addition everyone should be aligned to their roles in the customer needs to acknowledge that the team is always doing their best to deliver, that the only global commitment is to the product and so on.

In that, the PO should only enable the team with respect to product knowledge. The PO is a team member, aligned with the team and "owning" the product, which means they act as a proxy between the team and external stakeholders as well as being the central decision point for all things product related and the "face" of the product to the outside world.

When I was consulting, my favourite check for this was to ask:

Who is showcasing your sprint output (increment, features, etc) to the stakeholders?

If the answer is anything but "The Product Owner" then there's a clear disconnect between the PO and the team. The PO is the one responsible for the increment in the eyes of the stakeholders and it's the PO that should be on stage to hold demos to outside stakeholders.

4. Scrum

A lot of people like to take the terminology and say they're doing Scrum.

If you have Sprints, but nothing else, just give people some titles (Scrum Master, everyone likes to be "master", PO and so on) and you have Scrum.

Make a Sprint into a rigid structure, code freeze a few days to make time for QA and basically kill any ability to adapt. It's still Scrum, right?

Thing is, Scrum (even applied to the letter) isn't some magic solution to anything. Frankly, speaking from experience, a bespoke process that adheres to the generic principles is better than a framework. Also adapting Scrum isn't necessarily bad.

Just ... please don't call it Scrum. There's really no need to. In fact, if you've created an adaptive process (starting from Scrum, or not) please name it and own it. Unless, of course, you're not really proud of what you've created.

Agility should be as simple as "Pragmatic Dave" describes it. But it's obvious that many of those feeding on the "scrum industry" forgot a simple truth: the whole idea of "agile" was created by developers for developers, to streamline the development process and not to stroke the ego of management or to provide roles for outsiders.