I attended a Scrum Master course at Crisp last week. These are some of my reflections from that course (which I recommend by the way).

But first: why would I take a course on something I’ve been using for at least 5 years? I think it’s because I’ve seen so many shapes and sizes of Scrum/Agile that I’ve lost track of what was the idea from the beginning. Sometimes I feel that something is missing in our Agile processes at AB. I wanted to know: Are we doing it wrong?

The short answer to that question was: “Define wrong”. Darn! I knew it. The more elaborate answer has more to do with which level you’re on. Henrik Kniberg (course leader) drew on his Japanese background when defining levels of Scrum/Agile:

Shu = Follow the rules
Ha = Adapt the rules
Ri = Ignore the rules

That means that Scrum/Agile itself is not important. If you’re delivering the right working software every couple of (or three) weeks and you’re constantly improving – then you need not to worry. You are probably doing it right. However, if you completly suck at these things, perhaps the best for you is to apply Shu – Scrum by the book. But it will come a time when some parts of Scrum is beginning to feel like unnecessary overhead. Then move to Ha and start shedding those practices. Now it’s becoming trickier. The improvement curve is flattening out and it’s becoming increasingly difficult to identify waste. It’s time to throw Scrum overboard. You start focusing on what you deliver, not the process – because now Agile is in your DNA. But how do you take that last step? Nobody can tell you exactly. No rules, remember? Perhaps at your orginisation it’s building a culture that supports delivering the right thing at the right time, while enjoying it.

Ok, so how do we build a culture? Well, I see Scrum as really a culture builder. It imposes constraints on your process that promotes failing fast and delivering what’s needed when it’s needed using self-empowered teams that cherish improvement. Sometimes you need to apply a constraint that’s outside Scrum, like continuous delivery. Kniberg talked about how they began using release trains at Spotify. They decided to release every week – no matter what. If you have something to release, fine. Otherwise there’s always the next release train the following week. This takes the drama out of the deployment cycle, but it also has some interesting side effects. For example, you cannot have a release train with a monolithic product that every team is working on. It would be scary unstable. So they divided their product into independent components. It also made feature toggles necessary. If your team’s component could be released at any time, its’ new features would have to be disabled for the users until they’re ready.

So, back to AB and the question: Are we doing something wrong? Yes! One thing I was reminded of last week is that it doesn’t matter how advanced you are, you can always do 10 times or even 100 times better. We did a simple exercise divided in teams at the course that illustrated this. Before doing the exercise we were asked to guess how much we could improve the simple task given to us. After 5 iterations of doing the task and holding a retrospective to improve the process we had surpassed our wildest guesses at least 100 times. One interesting observation is that the real breakthrough came when Kniberg said to the team: “I know teams that improved X times!”. The team suddenly realised it’s really possible and we made radical changes that made the improvement rate jump up considerably. What would happen if we all had that feeling at work?

Want more Kniberg? Slides from a keynote in Paris 29 September 2013 (PDF)

Feedback is always welcome on Twitter @ocklund