Just finished reading Dan Olsen’s book “The Lean Product Playbook”, after hearing him speak at the Leading the Product conference in Melbourne last week (his book is now firmly on our Luna Tractor MBA and available to borrow if you’re that way inclined). Other than being a damn fine guide on how to do “good product”, he made a good point early on in the book about learning a process and then customising it to make it your own.
Bruce Lee, philosopher and butt kicker (from: goodwp.com)
He used the words of Bruce Lee to make his point:
“Obey the principles without being bound by them.” and “Adapt what is useful, reject what is useless, and add what is specifically your own.”
Firstly, quoting Bruce Lee is super cool. But beyond that, who’d have thought that us 21st century worker-bees could gain wisdom from a man most of us only know as a butt-kicking, strong and silent, hero type?
Olsen likened the learning of the process he had created to be similar to karate drills that students learn and practice on their path to a black belt. Once learned, it’s possible to move things around, “mix, match, and modify” to create something more your own.
The idea of learning something and then building on and improving it to make it your own resonates for me when introducing methodologies like Agile or Lean into an organisation.
My first introduction to Agile was via Scrum Master training, many, many years ago. We went through the theory, the steps in the Scrum process, and then did the standard Lego exercise of building something within a sprint process. I walked away with a certificate and an idea of how Agile could work, but definitely didn’t own the ins-and-outs of the process at that point. I understood it theoretically, knew the “what” and the “how” of Scrum, could recite the steps, but I hadn’t yet understood the “why” beyond the theory, i.e. understanding it in the context of real world experience and practical application.
And so, I worked on my first, and then second, Agile project. Which we called “FrAgile” because; large organisation, old school waterfall processes constructed all around us, doomed to fail before it started (sure to be many of you who have been through something similar).
I became more adept at running things. I started to see and understand the “why” in doing things that way and could see the benefits — I got into the swing of things, became adept.
But here’s what I realised. As I became more in tune with the process and saw it implemented in various good and not so good ways, I saw that you can start with a baseline process, learn it and get a feel for it within the context you’re in. But to have it truly work it has to be customised and tweaked to fit that context. You have to make it collectively your own. It’s no use adhering to a set of rules and ways for the sake of it, there has to be a reason for doing it — and value derived from it — that everyone involved can see and articulate.
This means that the format you use for something, the “how”, changes a little to better fit the team and the project or program and the needs of the organisation. And that’s ok, because if you have people who have practiced and learned the baseline process then you’re well set up to be able to improve and build on it.
Understand the basics, build on them to fit the purpose and the context.
If you don’t follow the exact stand up format dictated by the process you’ve introduced, or it runs a little over the allocated time, that’s ok. If you change up the demo part of the end of sprint to be more like a show-and-tell session, that’s also ok. If you’ve modified the way you write your stories or structure your epics and backlog, again, that’s ok. As long as everyone involved collectively agrees that the new way provides value to the overall process, then it can only be seen as an improvement.
But there are risks in this approach. Too often you see Agile processes in organisations that have been built over time and have become set, almost like a part of the furniture. They were originally modified and customised to fit the team at that time but the evolution stopped at some point, became fixed. People had moved on, new starters joined, and yet the process, the “how” was continued…even though the “why” had gotten lost a long way back.
This is bad. If your team can’t explain why they do particular things and why the process is how it is, then they don’t (collectively) own it. The value originally derived from putting the process into place has been lost, and it has become the equivalent of rigidly adhering to a defined process like Scrum, “just because”.
The method you and your team use to run a project or program needs to be kept fresh. You need to keep adapting so it remains useful, keep rejecting the bits that are useless, keep adding what is specifically your own. Because over time, things that worked well previously stop working so well. Things change and processes must evolve to accommodate this.
Understand the baseline, build on it to make it better. This is the very definition of continuous improvement, you collectively hone the “how” and make sure everyone can explain the “why”. This is how you and the team continue to make it your own, just like Bruce Lee.
Recent Comments