A year ago I had the great pleasure of speaking at the inaugural Agile Islands. Åland (as it’s written in Swedish) is a small group of islands between Sweden and Finland. It’s kind of independent but a part of Finland. They speak Swedish with the most beautiful accent you can imagine.
The reason there’s an agile conference in a society of about 29000 people (two stop lights on the entire island) is that they want to make the whole society aware and using agile practices. Sharing and cooperating around agile methods is one of the ways that they actually can compete and be attractive. It’s a very inspiring and lofty goal
Now I got invited back. The last year was a kick-off for agile practices (even some articles in the news there) and it left people wondering;
This all sounds awesome - but how do I get started
Agile Islands now asked me if I would be willing to help a company get started with agile. Zebrabil - a car dealership of 7 people. On stage in front of others. In 3 hours.
That sounded super scary and challenging, so I naturally accepted. I learned a lot by doing this and I wanted to share a few things.
Masterclasses as teaching method
First of all, I think that approach of helping/coaching an individual or team on stage in front of others works really well as a teaching method.
In music schools, this approach is often used and is called a master class. The idea is simple; a teacher teaches a specific student in front of others. By doing this the instructions will be concrete and directed to the particular student on stage, but questions and suggestions might appear from the entire group.
What I especially like about this is that it means that everyone understands that the practices described needs to be adjusted to other contexts. In my case, I had a car deanship to help get started with agile, but other people in the room were doing software development, call center work or legal clerical work.
Without me saying a word about it they naturally understood that the practices I suggested needed to be tweaked to their context. They, hence, focused more on understanding the principle behind the practice rather than the practice.
It’s solving my pet hate; focusing on best practices. We don’t need the cargo cult of blindly copying a practice that was best in one company, in one context at one time (which is all a best practice is). We can, however, learn a principle through an example.
Teach principles — exemplify with practices
Yes, exactly what I said in the paragraph above. I’m very much into teaching principles over practices but in a practice first approach. This creates a problem for me since it’s so easy to focus on practices.
I heard a story about the Willow Creek Church, arguably the most successful church in the world when it comes to attendance. They went from a few people to several thousand (26000) people attending services each Sunday. Naturally, other churches wanted to know what they did, so they had a lot of study visits from other churches.
After one service the pastor, Bill Hybels, saw a group of people that behaved very strange - they were crawling around on all fours in the back of the church. Mr. Hybles went down there to ask them if he could help them.
“Oh - we are so impressed with your work here. We want to be just like you”, they said from their position on the floor.
“Great! But what are you doing now?”, the confused pastor asked.
“We are measuring the distance between the last bench and the wall. Because we’re going to build a hall just like this. We want to be just like you”
[Space for reflection on the focus on the wrong thing]
Exactly! That was probably not the reason the Willow Creek was so successful. Right?!
Still, here I am blindly recommending people to do standup, TDD, boards etc. I’ve heard about people, in the IT-industry, selling new titles, roles, documents, meetings and organizational structures as part of a whole package that you … shrugs implement. It’s called RUP, or Scrum or XP, or SAFe.
</ Irony, since I have been one of them >
Nowadays I always and only focus on the principles - the WHY we are doing something. However, that becomes very hard to digest, so I also always start in the practical. And this creates a balancing problem for me, since I don’t want to sell best practices, but I can’t sell principles only.
I’ve found that always bringing the practice back to the principle is helpful and needs to be repeated. I’ve also found that asking the team (or person) you coach to invent the practice is even better.
For example, let them draw a structure for their workflow, gently nudging them by asking them coaching questions about how you would see the status, responsible person or value in the work created. We might end up with a board, with columns like every other board - but now they at least understand WHY.
This topic is probably a whole book. Maybe one that I haven’t read. But principles over practices is all the way for me.
Start where you are, gives me confidence
This was a car dealer- and repair-shop. I have no experience in what that kind of work entails or what is hard within their profession. Through some questions before we met I understood some of their challenges and that they wanted to work more together than as individuals. And I could figure out what their customers appreciate.
So how did I dare to jump in and give them advice? Because of the first principle of the kanban method:
Start where you are
The kanban method is a process improvement method. It can be used on any (sic. I’ve tried it in IT, on hospitals in Indonesia, my kids tv-watching-times, and now car dealerships on Åland). I dare to do that since kanban is an evolutionary approach to process improvement. The first step is to not change anything.
This gives the people involved in the improvements calm since we will together discover the improvements needed to make us better. It’s also respecting the fact that we (me, them or no-one) knows what will work best for us in the future.
When they explained cost of delay to me
One of the best things that happen when you presenting, I think, is when you start to learn deeper by explaining a topic. That happened a few times during the coaching session I had with them. I will relate two of those things here.
The first time was when we talked about metrics. This was at the end of the session and we had talked a lot about focusing on flow effectiveness over resource utilization (having the manager scrapping the Gantt scheme, he made the day before, for the autumn in one break).
I suggested some pretty ordinary things to measure, such as lead time, throughput and queue length. We also talked about balancing these metrics out with measuring revenue.
Then I saw one of the guys looking a bit distant and he said:
How about if we measure the time our customers are without their cars?
I just went silent and got that hair-on-your-arms-standing-on-end-feeling. Because that is brilliant. And it proved that he (and the others got it).
It’s basically just another way to view lead time, but the focus is totally different. It’s focusing on the need of the customer.
This is an advanced measurement, called “cost of delay”; how much does it cost our customers not to have this completed.
How much money will we not make from now until this feature is in production?
How long can our users cope without this feature?
How much more value would it be for them to have this in production earlier?
There are more things to consider around Cost of Delay calculations, but I will forever use the phrase and metric for Zebrabil to explain to my clients what cost of delay is.
When they explained classes of service to me
As I had collected myself they went on and asked a question:
What about the yearly car inspection? How would the cards work then?
Once a year everyone goes into the car shop to get their car inspected and ratified for use another year. Some simple remarks that you get in such inspection mean that you can still drive the car but it needs fixing later.
I suggested that it would be two cards in on their board; one for the inspection and one for the follow-up work. And then it happened again:
Or … we could offer them to fix the minor things straight away for a higher feel.
That would shorten the time they are without their car, and give them the option to choose so.
(In all honesty, I’m abbreviating the discussions here - hope you appreciate it in this long-enough-post)
Yes! That’s another class of service as it’s known in the kanban literature. This is a set of policies that help us to prioritize and handle a specific type of work. It’s pretty advanced, in that regard, that most teams I’ve seen never reach this level of kanban-maturity.
Now these guys… they got it straight off the bat. Here’s an opportunity for a client to pay a little bit extra and get better service. It helps them to plan and prioritize. For example, all small-inspection-fixes-within-the-day is written on a blue (for example) card and is always prioritized over other, normal work. There can never be more than 2 of the blue cards on the board on a given day, and their blue notes can never take longer than 1 hour each.
All of the above policies are just examples, of course, but it could prove very helpful for the team to know how they would/could cooperate and interact.
Summary
Zebrabil trusted a guy that they never met before to give them advice on how to work. That’s gutsy but also shows great interest in being a better version of themselves. Give them a shout-out on Twitter and wish them luck
I had such a blast coaching Zebrabil in this setting. It was enriching and I learned a lot from it. As I do with almost every new team I meet. My hope is that they got a lot out of this too. We promised to keep in touch so I hope to tell even more stories from this small, great company.