This is another post in the impromptu series “Marcus explains his tweets in more detail”.
In this post I wanted to talk a little realisation that I’ve grown into the last couple of years
There are no best practices is knowledge work.Only good practices and context when they apply. Learn principles-adjust and develop practices
— Marcus Hammarberg (@marcusoftnet) September 23, 2016
It might sound obvious at first (or not) - but I see many signs of that we, especially in the agile community, do the opposite. Let’s see if I can explain my thinking or if I make a fool out of myself - that alone might be worth reading this. Lets go!
Principles over practices
I often get thrown into meeting about “help us to become agile” or “teach us how to do scrum” or “should we do scrum or kanban?”
Before I started in that end and often ended up in another - but nowadays I just say it out loud from the outset:
Scrum is not the goal. It’s much more important that you understand the principles behind it and then you can tweak whatever practice you like to suit your need.
Creativity
Principles are more powerful since they unlock the creativity and innovation within an organisation and also every individual. If you teach someone a practice (without or little focus on principles) their perception of reality and even language will be formed by that practice.
I’m sure you have team that is not, by any measure, are doing Scrum and still refers to their board as the “Scrumboard”. It’s not. It’s just a visualisation of your work. On a board. And that’s perfectly ok - Scrum is not as important as the principle of making work visual so that we know what is going on.
If you understand that visualisation is the thing maybe other, better suited, ways of doing the visualisation will emerge. A board might not be the thing. Maybe, in our context, shelves with boxes are better? Only you know and can find it, if you get the principle.
Are we even in the right box?
With a strong focus on best practices and “doing X” (TDD, Specification by example, Scrum, SAFe - choose you poison) we lock in our thinking into that box, as I said. What’s interesting to note, I think, is that sometimes that practices and thinking is not even appropriate for the problem at hand.
One way to describe this is by using the Cynefin framework that helps us to see what solution might apply to a certain problem.
I’m by no means an expert and I’ll leave it to others to explain this framework in detail.
However we can talk a little bit about what Cynefin tells us, and that is that you should not use an Obvious solution to solve a Complex problem. Nor should you use a Complex Solution to solve a Complicated problem. It’s either overkill or doesn’t solve the problem. Just the right tool for the job.
By applying, for example, SAFe to a few teams we lock ourselves into SAFe-thinking. By applying a rigid view Specification By Example we have those practices that we need to follow. Should we need them or not.
Show me the way
What if the practice needs to evolve? I remember when RUP (Rational Unified Process) was the way to do things. It failed, since it builds on the notion of long feedback loops which has turned out to be really hard to implement.
Or did it… No it didn’t, because it stated clearly that you should only use the part of RUP that supports you and your organisation. But everyone (that I saw) still implemented everything of it. Just because it was there and, more importantly, because no-one knew where we going;
- This big SAD document feels so stupid - should we stop doing it, do it better, do it in iterations, AAAAH - what is it?
- We really should change the way we write these sequence diagrams, it doesn’t gives me value most of the time. “Ap ap ap - that’s not RUP. RUP tells us to …”
- All these meetings are wearing us down. There’s no time to work. But which one should we stop doing? If we stop doing one, why not stop doing all? Which is the more important.
You can of course replace RUP above with XP, SAFe or Scrum. Remember the term Scrum-but that was thrown around a few years back? “Sure we are doing Scrum but we have no iterations”.
Well that’s only a problem if you are selling a package called Scrum (tm) - because then people that are not following what you said should work will blame your process. Indeed that’s how the official Scrum guide (aka “The Rules of the Game”) end.
For the rest of us - we don’t need to care. We need to understand the principles and then change the practices to suit our needs. In fact by understanding the principles well we are in a position where we know what, when and how to tweak the practices. Or ditch them and try something else.
“We cannot fail - we can only learn”
One of the principles that I’ve built my career and professional life around is to always be learning, always changing my ways. Check the subtitle of my blog for example
By applying that thinking I feel perfectly safe stealing and trying practices from different methods and processes. I’ve made some cross-overs that no-one tried before and even I thought would not work.
Right now in my team we are stealing the interesting practice of Product Increment Planning from SAFe. We need better alignment among our teams, stakeholder and groups around us and we want to try and see if that is one way that will give us that.
It’s the only thing we steal from SAFe. We have no ART, no roles from SAFe, no Strategic themes session and enterprise portfolio planning. And we even tweaked some properties of the PI planning itself.
The other day I got a question from someone well acquainted with SAFe.
“When is the PI planning, Marcus?”
“It’s on Monday”
“Whoa - that will be super-though to get everything into place until then…”
No, it will not.
In fact it will be just right. Because we are not doing SAFe. We are just “getting people around our teams all together into a room for a day to plan the next period of time”.
In doing so we will probably get a better view of whats ahead, how far we can come and challenges in reaching our goals. The worst thing that could possible happen is that we learn a lot. And that’s a big win in my book.
If I was implementing a PI planning from SAFe, I’d be very nervous. Because there’s a lot of things that is not in place. But we are not. I only know that we have a great team, in the same room and a list of things that we are supposed to work on. And that fills me with peace.
I trust the principles of short feedback loop, learning and letting people be great far more than I trust any practice.