I just ended my biggest coaching assignment in my career. So far. It started in January and aimed to roll out agile in a organization of 120 (and then some) people – 60 on the business side and 60 on the IT-side.
I first thought of writing about how it all went down and what we did, but I then realized that I would reveal way too much about the customer and it’s organization.
So instead I’ll write about a couple of things that I’ve experienced and thought of. Hopefully you can learn something from this - i know I did learn a lot.
Let me first state that not everything in this article is based from experience from this one client. If you read this and work there; not all of this happened at your place. Know this - it’s the same at a lot of places where I’ve coached.
You need a WHY
An agile roll out in the whole organization is a big change. It’s a change of the business strategy. It will affect a lot of people. It will affect the way they work, the name and meaning of their roles.
WHY should we do this? What’s the reason for us/me to change?
In order to succeed with all this changing you need a reason. A why - sometimes referred to as a “sense of urgency”.
Not only that - the WHY need to be known in the whole organization. If the WHY isn’t known it will be very hard to change people. In fact - you may end up trying to force the change on them and that will never work, or at least not produce a good result.
In my experience there’s a pattern that happens when you try to force change upon people that don’t see the WHY; they are very focused on the HOW and you end up in a lot of discussions on how to adjust their current way of working (a little) so it fits in the new world.
Introducing agile is in essence introducing a new why of thinking. You need to see this need and really want to get to the new place to be able to do this. Compare:
“We cannot not do this the way we work today” vs “We need to work that way - what should we change?”
Finally - the WHY cannot come from the outside. You cannot bring an urgency to change with you as an outside consultant - it must come from within the company itself. An outside coach/change agent can be a very good thing to help you on the journey but the actual need must come from within the company.
I’ve heard that Toyota sensei:s (TPS/Lean gurus) often are requested to go and help other companies. They hang up the first 99 calls. On the 100th call they respond - now they know that the company is really desperate to get their help and ready to change.
It’s not so that I as an agile coach get a smoother journey with a company that is ready to try “anything”. But it’s just a waste of effort and time to try to force change upon an organization that don’t see the need or WHY they should change. We all have better things to do.
Use experience based learning
I’ve done a lot of different presentations, courses and educations as an agile coach (for example this on user stories). Although I think coaching in real practical situations are the best thing to learn in, quite often you need to lay a common foundation, to establish some common understanding in the whole group and for this ordinary presentations might be just fine.
You should aim to inspire and get people interested rather than to explain every little detail. The inspired people will automatically find more information as needed.
Focus on the concepts and ignore details… for now. It’s better that they grasp a couple of basic concept fully that they get out of the class with a toolset to use but don’t know how.
The best way to get concepts to stick, in my experience, is to use experience based learning. In my case it’s often some kind of game or simulation (call it simulation if people think games are silly) followed by a discussion. It’s the best thing I know to run a game and suddenly see the penny drop for people. I’ve never seen that happend from one second to another while doing a presentation.
The games I’ve used lately is the Dot Game (link requires free registration) to establish core agile concepts, Learning to count (see this post) and Lego4Scrum that is a introduction to Scrum (duh!). Make sure that you have plenty of time for discussions after each game. If you get a good discussion going taking a stance from the game and discussing the client actual environment, I’ve found that a lot can be learned in a short time.
Whenever possible try to use examples from the client environment. I cannot count the number of times that I’ve been asked to be “more concrete” or have “more examples that we can relate to”. That include the times when i’ve picked items from their backlog.
Roll out in agile fashion
Very often in my experience the “big agile roll out” is a waterfall project. We first do all the education, then we coach all the teams and then they are on their own.
I would suggest that a better way is to learn as you go and start small. Now where have I’ve heard about this before… - yeah that’s right; it’s agile. The very concept we are trying to roll out.
Start with one team. Help them to be great. This will both give a positive push for the organization (hey - if they can so can we) and it will generate feedback to learn from. Also it will start the learning and sharing among the peers in the organization.
That last part is super important - you want to establish a culture of learning and sharing. Make everybody aware of that we will and should learn from each other - especially from the mistakes we make. We WANT to know about them. Please!
A simpel thing that Håkan and I “did” in this last assignment was to arrange Agile Coffee. It’s modelled after the Lean Coffee concept;
- get people who are interested together
- put together a short agenda for the meeting by asking people what they want to talk about. Anything goes here but related to agile or lean is a given
- talk for time boxed period of time (7 minutes) and when it’s up vote if you want to continue or not
- make a mind-map of what you talked about
We created this as a knowledge sharing room for the people in the organization involved in the agile roll out. It’s open for anybody interested, it’s not scheduled and it’s you free time. The reaction was very positive with a lot of great discussions taking place.
Coaching
Only offer coaching when asked to. Never place a coach in a team that don’t see the use of it. This goes hand in hand with the first point but is worth stating over again. You need to establish a need, a WHY and then let the teams themselves ask for a coach. Otherwise the coach will end up being a silent person in the corner with nothing much to do. Or, if you like me, someone that is trying to change people to what he thinks is better.
None of these are good. Coaching must be requested and wanted to have effect.
Coaching is more a less a must to continue to evolve in my opinion. At first the need for coaching might not be seen or known. But have patience here - they will come around and ask for it. And it’s better to wait for that than to force coaching upon teams that don’t see the use. Much better.
Conclusion
An agile roll out is a change of business strategy. We’re changing the way we do work. From large stuff seldom to small stuff often. This is not easy and for many a major mind shift.
You cannot accomplish that without a well known and in-the-whole-organization-resounding WHY.
With that estabilshed a lot of things will be smoother. Still I would suggest using experienced based learning to teach, roll out in an agile fashion and finally use coaching to continue to help the teams to learn.