Agile transformation isn’t a single ‘ta-da’ moment when everything is done. I feel I need to say this up-front.
Now I can relax a little and tell you why I am saying it, and how an agile transformation might look after the first bit. The thing is lots of people are writing about the first bit. Where you get in some experts, you do lots of training – usually in scrum. Once you’ve done that, what do the next phases look like? (Yes, sorry if this is a surprise but you are not ‘done’ I’m afraid).
To explain, here’s a story about how I came to be talking about this at all, and then what various way-points in agile transformation might look like.
How it all began…
I was recently talking about the day I started at NewVoiceMedia. During the conversation, I used the story of my first impressions of NVM to illustrate a point. In doing so, I said something that has stuck in my head for entirely different reasons. (Do you ever get an insight from something you said by accident? Perhaps it’s just me…)
I told the story of a major reason I chose to accept the role at NVM was because it terrified me.
Here’s the story
I had already been an agile practitioner for a very long time, and I was good at it. At the time I joined NVM I had a lot of varied experience too, both in types of company and in terms of agile maturity. (I guess that’s the reason they liked me!)
Theoretically there shouldn’t have been very much that I could encounter at NVM that I couldn’t handle. Really. It was an agile environment of around 25-ish developers and testers (from memory) who were all working in agile ways in a mature agile environment.
And that was it…the crux of my problem. These people were good. I mean REALLY good. What on earth could I possibly bring to the table? At that time (2013) it was the most agile place I had ever seen working. They were head and shoulders above places I had previously considered great examples of agile working practice in the wild.
And I was terrified. What could I possibly bring to this party that they didn’t already have? How could I add value?
Don’t Leap to Conclusions…!
I can guess that right about here is where a few people reading this will be nodding sagely and saying “Ah, yes. Impostor Syndrome. Classic case.”
If you are one of those people, nice try, but not a hit I am afraid. I know more than I’d like to about impostor syndrome, and this was certainly nothing to do with it.
What I had was a lack of vision. I was expecting a standard, straightforward “we pay you & you do things we know you have done before”. Instead, what I was being offered was “hey, we want to learn how to get even better. We think it’d be interesting to do that together. Interested?”.
What NewVoiceMedia saw in me was the spark of what I could do. At the time I didn’t know what that spark was, or even that it was there. I have seen that spark in every single person I have been privileged to hire at NVM. (I’ve also seen it in quite a few of the people we weren’t able to hire too, for whatever reason too!)
It is the spark of potential.
Most people don’t know how capable they are
What Rob Lambert, Nigel Johnston and Dan Phipps saw in me 4 years ago was the way I thought, and how that could be applied productively to the NVM environment.
So, whilst I had no idea how I could add value to NVM on my first day, they probably didn’t know either. Between us though, over the next 3 or so years, we built an (even more) amazingly agile, responsive, respectful, adaptive and continuously improving environment. We moved from yearly releases to monthly and then to weekly releases. We just about quadrupled the number of people, with a staff churn so low I can’t tell you what the fraction was.
None of us would have had the audacity to set a goal like that in 3 years. Would you?
And here is where I came in: Agile Transformation is not binary
I couldn’t imagine being along for that sort of a ride when I joined NVM, and I couldn’t see how I could contribute to what they already had built.
But over those years we made many, many small experiments. We were successful with some experiments and we kept those. Other experiments we were unsuccessful with, and we came up with new experiments for those. The low-hanging fruit is easy to reach in an early adoption agile environment. 80% of the improvements can be got with 20% of the effort*.
But what about when the ‘easy’ stuff is all done? (Forgive me, I am not just over-simplifying here, but possibly inciting proper wrath).
*may not be statistically accurate, but anecdotally ball park for sure 😉
What exactly do you mean by ‘Easy Stuff’?
By ‘easy stuff’ I mean the 80% of the improvements can be got with 20% of the effort I mentioned above.
- You have teams successfully using agile in whatever from best suits their domain, and loving it.
- Morale is high and people love to come into work.
- You’ve embedded and embraced whatever flavour of agile practices works best for you.
- You have a sustainable pace and high quality releases are happening regularly
- Staff retention almost 100%
- New hires are largely from word-of-mouth recommendations of your existing staff
Many companies are struggling at this level. The bigger the company, the harder this easy stuff is to get done. Think of it as levelling up if that helps. Level 3 is only easy when you look back on it with all the experience that getting to level 23 gives you!
This is possibly the most persuasive argument there is for bringing in external help when your agile practice adoption doesn’t seem to be moving forwards anymore. You want help that has tales of former battles won to fall back on!
Lets assume you nail the easy stuff. Now what? Well, you move on to the harder stuff.
Levelling up is always tough, no matter where you are!
What do I mean by ‘harder stuff’?
- Perhaps having continuous integration, and are doing regular releases on demand (at whatever frequency is appropriate for your business. It’s having a short lead time to release that is important, not the frequency of release).
- Or your hackathon projects regularly include technical and non-technical projects, and projects both inside and outside to the IT team
- Maybe when you are well known as a company that’s great to work for, and candidates seek you out to interview for a chance to work with people they genuinely respect
- When teams challenge agile practices in ways that can potentially improve the whole system
Well, then you move on to the really difficult stuff.
Then there’s the really difficult stuff
Now what do you do?
This is where you start looking at things like failure demand & systems thinking for the business as a whole. This is about being a tiny bit better tomorrow than you were yesterday.
This may sound the same as where you started implementing agile working, and whilst that is true, ‘tiny improvements’ in the early days have much bigger impacts than they do at this end.
Improvements in the really difficult stuff are hard.
They take 80% of effort for a 20% improvement. And thats only on a REALLY good day.
Some days you put in 100% effort and get 0% improvement.
Sometimes you even make things a little bit worse.
This is where most people give up. They declare it’s ‘good enough’ and move on. But the real skill of the craft, the real difference between good and great, that lies in the very last bit.
A Better Metaphor for Agile Transformation
Its like that mathematical example where you are constantly halving the remaining distance to a destination to illustrate infinity. You can never reach the destination if you are constantly halving the remaining bit of the journey.
Agile expertise is like that. As you get better, you have to work harder and harder to get ever smaller gains. And all with no hope of ever being ‘done’ (gotta love the irony there!).
So next time you are looking for a new agile challenge, ask yourself how getting even better than yesterday could be done. Sometimes you need to find and work with others who are better than you are, and sometimes you can learn heaps by leading other people to be better than they are right now.
It really does seem to be a case of; the better you get the less you seem to know!
Helen
PS If you are interested in growing an increasingly better agile environment, have a look at my 6-post series on Building A Centre Of Excellence.