Let’s get hurt

I was recently told by someone reviewing my proposed approach to “crawl, walk, run”. I told them I’m only interested in flying 🙂

That would have been all fine if it didn’t occur to me today that sometimes you need to crawl first.

What’s the rule then? Is there a rule? Who makes the rules?

I think the answer would be – what’s the risk? Two examples:

• If I’m actually flying an aeroplane with no licence and no clue of what I’m doing that’s too much risk. If I’m playing with a small drone outside my house, that’s very likely acceptable.
• Another example closer to IT – if you’re experimenting with technologies on your own team, you should be able to do whatever you like and pick the things you like so if you crash and burn you’ve only killed the tool and wasted a few days, weeks tops. If however, you’re setting out to change how an organisation of hundreds of people within an even bigger context of the company if you fail you’re going to burn more than a single person/tool and a lot more than few dollars.

Does that then mean you shouldn’t be ambitious? Never start big or even huge projects? Most certainly not but you have to be clear about the risk, your chances and don’t start at the end. Which do you think will get better results:

1. Start scrum with one or two teams, put best people you can find on them, surround them with coaches, environments plus coffee and cakes until they don’t need you anymore then add third and maybe fourth … repeat, or
2. Start with 10+ teams, struggle to staff them with competent people, only provide scant cover for trainers and coaches, have no environments and delivery pipelines so that all teams struggle to get any time from people you’ve funnily called DevOps (because that’s how you build DevOps culture, change a badge on Ops) …

Why is it so hard to “slow down to speed up” rather than speeding up when you’re already out of control?

This model shows the different stages that learners go through when learning new concepts:

• Shu—Follow rules to learn basics
• Ha—Break rules and discover context
• Ri—Mastery and find your own way

Somehow in our land, everyone wants to start at the last stage and get all the benefits right now without having to put in the hours, days, months and years into the journey to that level. Why? I guess scarcity of masters (people with a lifetime of experience, not 5 or even 10 years) is one factor and no access to temples (places where you come to learn and go away a master. And no, the certification schemes are not that) are key factors. If you pick a book on Aikido and practice in your back garden rather than seek a dojo the most likely result will be injury and disappointment. Why do you expect something else when you try to practice something as complicated as agile?

I don’t think I’m offering too many solutions here apart from what is in bold above – “slow down to speed up”. Here are a few more bits of details on that:

• Keep slowing down to the level of basics (agile processes) and smallness (size/number of teams and duration of iterations) until you always succeed.
• Until then focus all your efforts on either scaling down more or fixing things preventing you from succeeding if you cannot scale down more (which in my view is only when you have a single story per iteration and a single team).
• Only when you have successfully executed several times at this lowest speed, got the baselines and measures in place start to accelerate by scaling up (more stories, more product) or sideways (more teams). Preferably scale only in one direction in any given experiment at growth.

Congratulations you’ve now ready to be considered for being at Shu level. Bring a master in to assess you, take his advice and go back to practice 🙂

Advertisement