Agile Transitions: Good things …

Sharing: facebook, twitter

Metamorphosis

Observations and thoughts

Some observations and hints (opinions?) how your „agile transition“ might not end like this Dilbert. If all ends badly, no one would tell you anyway. You’d have to listen to water cooler conversations.

Exposition: A half marathon in 90 minutes – for once!

Once upon a time, I had the goal to finish a half marathon in 90 minutes. When picking the goal (in a rush?), I thought I was already close. Out of no apparent reason. To test my abilities, I participated in some competitions, mostly with crushing results:8km, 10km and so on. And then, finally – no excuses – a half marathon. Here the harsh truth, the raw data: 1:43 – roughly 13 running minutes and several years of training separated me from reaching from my goal.

A few years later I got it done, I had it in – as they say. But: getting there was cumbersome. Quite cumbersome. The first steps of progress looked promising. But then again – I came from „nothing“: 1:43, 1:38, 1:35, … but then: 1:33, 1:32, 1:31, back to 1:32 … And now I need to start measuring more exactly to really see any progress: 1:32:05, 1:31:38, 1:33:23 („really hot that day“ the notes say in excuse ;), 1:30:42 („complicated course, many corners, benefits smaller runners“ ;). You see: the reasons why it „couldn’t happen today“ are also becoming more detailed.

Some important context to all this: At the time I was running 3 to 5 times a week – depending on the „training phase“. That’s what you have now, at that stage: different phases of training. Not just „running“. The training also got more detailed: long runs, long runs with accelerations, sprints, 400m repetitions (with or without accelerations), 1000m or 1500m exactly timed repetitions with or without 20 mins along the aerobic threshold, or slightly above … you get the picture.

Getting there took me some 5 or six years overall (I would have to look it up). I guess some 3 years alone for then finally getting from 1:33 to 1:29:46 (what a close shave!). I was a nerve wreck of in that race until the last meters, not being sure if I’ll finally get that time in. And I was looking for a pretty easy race course and and and. And then I died of happiness and joy. (Years later I cried, because I only mad 1 1:38 or something). Whatever. Other surely get there faster.

What I actually wanted to say: That’s how much effort and time it can take to improve. And that was just running and it was just me. No other people involved.

I’m getting there, because this podcast, I recorded with Stefan Roock und Henning Wolf (sorry, German only)reminded me once again of how complex, time – and effort – consuming the transition of a company towards more „agility“ normally is. Since now more and more companies are trying this, one could think that there is now a known industrialized approach to this or that someone found a recipe for it. People who just do that on the side. The impression that we could „order agile“. „How long will it take“ is the question we get, shortly after the transition program has started, just like the „Ma, when will we get there#2 from the backseat on our car, still a full 8 hours from our destination. Both questions being completely understandable, the answer still is: „It’ll take some time (, honey)!“ And that is just not to say „a really long time(, honey)!“ We won’t exactly know, also we don’t know which monsters and dangers we’ll meet. But once we understand that it’s a journey, and that it isn’t supposed to be easy („Life is not supposed to be easy!“ Michael Foley says in my podcast with him) it can actually be fun!

„You simply can’t expect that people get to a stage in some weeks that took us 12, 15 years to get there“ – Henning Wolf

Success factors (boundary conditions, not recipes)

Some points made explicit by Stefan and Henning in the podcast as supporting a successful transition:

„Transitions“ work better if

  • purpose and motivation are clear and explicit
  • the commitment to the transition is unshakeable and can not be put into question – even if the „how“ is not yet clear
  • There are internal employees that will really have a fire burning for the transition get the necessary space and time to to what is needed. Amongst what’s needed: raising nagging questions again and again and pinpoint candid discussions.Otherwise, improvement won’t be possible.

Reality Checks

(A) One shouldn’t even start thinking about quick changes. nothing like this works in a rush. Even worse: The urge for a rush kills all movement.

(B) One has to own the (software development) process selber besitzen. One has to think on his own and do the work. (Henning Wolf)

(C) One should only use the tools required and only as long as they are required.

Agile Frameworks do provide great marketing and that leads to some simple explanations that travel well. Having said that, the simple statements also come two dangers, though:

  1. Willingly or unwillingly, reader and liegt get convinced of some sort of images of ease and speed of implementation of changes on organizations. And that simply is not true, see (A), (B) und (C).
  2. To create clarity, things get dumbed down, decontextualized and recipes are created and presented. But, there are no recipes for changing companies. See: (C).
  3. People show some kind of complex behaviour individually. Large groups of people even more so. Thus, to motivate many many people is really incredibly hard (although I like the challenge:)

Boundary conditions: Do’s & Don’ts

This blog post ist way too short to really go deep on every aspect. But, here some best of mistakes in starting transitions, I had the chance to observe. All of these „mistakes“ will immediately picked up and felt by employees, just like a sled dog that is forced to make a U-turn.

Doing things in a rush (see above) is one of the most deadly sin. The concept of group speed vs. individual speed is incredibly important. The quicker we want to move, the more resistance we often create. Just like in swimming, moving constantly and elegantly is faster than moving in quickly. Counter intuitive, totally.

No apparent, explicit reason for the tranistion: Do we want to change? Do we have to? Why? Are we too slow? If yes: What does faster mean? More throughput? (That’s not what Agile is supposed to deliver, btw). Better time to market? Doe we actually have ideas worth changing the way we work? Better products? Better quality? Just getting rid of the jam of projects in our pipeline (that’s actually something that can not be solved locally, not even in the whole dev department.) Do we just want to get a company that is nicer to work in? There might be many reasons, some of them are valid. But often, these are not made explicit and the whole raison d’etre is conflated and can’t be understood. So, everyone will ask herself: Why bother?

Do those that are „ordering“ the change show any signs of change themselves? Do they live change? Or talk change? do they walk the task or observe others change? Are they open to solving problems that are caused by the change themselves? Do they care for the people they are responsible for?

A pattern that never works: Big change, now. „Agile for 500 / 5000 people, please!“ Successful transitions start in the small. To start in the big is just too complex and hard. The following issue alone will kill it: Coming from world of perfect planning, the detailed plan for a big transition will never come into existence. I once heard about a team planning a small, agile pilot for six months. Sorry, but: Such a thing, you simply do and the enemy is overthinking it.

Another thing that never works: Change without a concrete, palpable trigger! We need something which we could not achieve in our normal way of operations. This project or that that simply is out of reach within the way we work today. So, with a small group of people, going a new way to achieve that is what we want. They might have to break some rules, discover new territory – that also means: they need to be protected finding these new ways. Because that’s what’s at the core: They will have to do things really differently, otherwise there will be no difference ein outcome, right? Now, achieving that formerly unachievable thing is what creates trust in this breaking of rues and finding of new ways. These people were actually not crazy. And from here on we can build on that success. A hint would be googling for e.g. the Kotter change model.

Another way that can work: Change from the top. This is actually my preferred way: Lieblingsansatz. IN this model you can nicely „steer“ size, trigger event and direction of the transition. Also from here you can practice a good side to side between top-down and bottom up, by 1 (and thus triggering the same vice versa).A good portfolio approach is a good way to start, as it requires all parts of the company to cooperate and thus have all necessary friction in one room. best of all: The management team, in this approach, needs to be the most agile team of all. So, walking the talk is a must. And everyone else can see they are serious.

The topic is encyclopedic (while actually simple if we turn on our empathy). How I see it: Transitions are actually fun, if you see it as a process that takes as long as it takes and see the people in the core of it. Also, you will not exactly know what’s happening. And that you have to embrace. If you don’t embrace this, you will fail. It is hard problem. It takes time. It is a process. And you can not know what’s coming. In hindsight, the example of a company I work in myself as an employee: We worked on the transition for 4-5 years (at least that’s how long I’ve been part of that). Many days were difficult and challenging. And there was lots of perceived micro process. We were happy, sad, mad. We fought, we partied. And nothing was easy. But looking back after years, what we accomplished was just great. The clarity and focus of the company was on a level I don’t see often. So, the reward can only be seen in the rear mirror. Make yourself comfortable with that and enjoy the ride.

Sisyphos, but happy – as they say.

  1. See also, my podcast episode with Michael Foley



Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>