MarkStringer.github.io

Commitment and Consistency

I commit to a transparent, empirical process.

It’s taken me a long time to get to this. For a long time, I was worried that as a Scrum Master I couldn’t commit to anything. I vividly remember going on Nigel Baker’s CSM course and taking part in a game where I was the chief elf and I was explaining to Santa that he couldn’t have everything that he wanted for his website in time for Christmas. And maybe I’ve filled this in later, but the man in the Santa hat was saying “But the children won’t get all their presents.” That’s right. They won’t. How do you feel now? Terrible right?

But the crucial thing to understand is that saying that the children will get their presents won’t help the children get their presents.

Refusing to commit in situations where I’m expected to commit gets me into a lot of trouble, way, way more than lying and making false promises would. I’ve had people throw the phone down on me, I’ve had complaints to my boss. I’ve been thrown off projects. I’ve had complaints from my boss.

I have real trouble with the idea of a Sprint commitment, and it’s my understanding that sprint commitment isn’t mentioned in the most recent version of the Scrum guide. Because for me, in an empirical process, no body has any business commiting to anything other than the empirical process.

Agile is a way of doing things which is better than what went before, and in order to be better, it has to be different. The actions have to be different. And the way that our actions are different is that we have to be transparent about what we’re doing, certainly about the results of what we’re doing, and then we have to change what we do next in light of what we see.

But there’s a problem with this. And it’s this:

A project is fundamentally a deceptive and dishonest endeavour.

I’ll write more about that next time.