"You're doing it wrong"

How often do we hear or read that phrase, when discussing how adopting an Agile approach hasn't quite worked as advertised for a team?

Very often.

"You're doing it wrong."

The implication being that someone has missed a complex, subtle piece of Agile Lore that means, obviously, that their processes are not delivering the goods.

The thing is, the second part of that conversation, where we learn How To Do It Right, is often vague or lost in the emotional compost of online commentary.

You're welcome

To remedy that for the whole world, I'm going to offer some insight and advice from my many years on projects that often didn't quite do-it-right.

Let's talk specifically about your imaginary team adopting Scrum, as it's what many of us know best.

Sometimes, doing it 100% right is not going to happen.

At the risk of being cast into the exterior darkness by the Scrum zealots, I will say that with Scrum methodology, you can lead the horse to water, but you cannot force it to contribute thoughtful feedback during the retrospective.

Humans behaving as they do, if they don't fancy playing your silly planning-poker game every second Tuesday, they won't.

Or, they can't split their demands down to Sprint deliverables because actually, it is a big piece of work and they're not here to play with Jira all day.

The Boss cares in principal, usually, but in practice maybe not enough to back you with incentives to get people to follow the new process. You risk becoming a martyr to a methodology.

The Burnt-out Remains of Scrum

Usually, the daily standup survives, as it has obvious teamwork benefits for the cost of 15 minutes.

But after weeks of half hearted estimation and missed goals, your sprint planning ends up being 50% rolling over demands and 50% scoping new ones.

The retrospectives write themselves, which is lucky, because no post-it notes are appearing on your sailing boat any more.

Teams run like this and still deliver software regularly. In fact in many large organisations, this is normal. The nature of the team, or the product, the support environment; all contribute.

It is quite depressing though and it's not how the online Scrum training said it would be. We're not seeing much upside.

Why is this happening?

(It's because you are doing it wrong.)

At this point, I'd usually nominate someone else in the team to take over as Scrum Master.

Seriously though, the way out of this swamp is not through more vigorous flogging of the horse.

We need now to identify what the problems are, not with the adherence to the methodology, but with the quality of what the team delivers, how the team interacts and how the team plans work.

Once that's been done honestly, you might choose to revisit how you implement the Scrum adoption, or you might not.

I'll describe some ways out of this maze next time.