Distributed Decision Making

Imagine you are in a car travelling down the motorway. You are trying to keep to the speed limit (110km/h here in Australia). How good are you at doing that? Do you, like me (and most of the population) just follow the car in front with an occasional glance at the speedometer? A few hasty speed corrections when that occasional glance tells you that the car in front was doing 130 not 100? Now imagine that there is a police car right behind you. Does your strategy change? Mine certainly does. Your eyes barely leave the speedometer. You maintain absolute, tight control over the car's speed.

There are downsides to this approach though. While your eyes are firmly fixed on the speedo (that's Australian for speedometer BTW) they aren't firmly fixed on the road. While you are deeply focused on the operational details of driving the car (controlling its speed) you have lost sight of something very important - the road ahead. You may be sitting right on the speed limit but you have just driven past your exit. Or worse, you may have missed a sign telling you that the speed limit had changed and now the flashing lights are in your rear view mirror and you are being pulled over for speeding. Precisely the thing you were trying to avoid.

Organisational Change, AgilityDave Martin3 October 2018patterns, organisational change, decision making, decentralisingComment

Doing vs Being

Let me get this out of the way first - Agile is not the point. I see a lot of organisations wanting to "do agile". My question is always "Why?" Why do they want to do agile? Often I find that there is no why. They want to do agile because doing agile is what you do these days, or doing agile is what our competitors do. Doing agile is seen as some sort of magic formula for success. Do these things and good things will happen. No one is quite sure what good things they will be, people talk vaguely about efficiency and faster/better/cheaper. But that doesn't really matter, whatever happens, it will be good.

All these efforts will fail. The organisation will end up doing a bunch of agile things - standups, boards, retros and so on, but the end result will be - nothing. No change in any real measures of organisational success. No improvements in ROI, no improvements in time to market. Nothing. Why? Because doing agile is not the point. Agility is a way to deliver business outcomes. Business outcomes are the point. Not doing agile. The outcome organisations are really looking for is to become agile. Becoming agile means they can respond quickly to changing markets, deliver what their customers need before their competitors do and so on. Becoming agile as an organisation is not the same as doing agile practices. Yes, the practices are important but they aren't the full picture. If all you do are the practices, you will never become agile. As a mathematician would say, they are a necessary condition but not a sufficient condition.

Agility, Organisational ChangeDave Martin18 September 2018patterns, organisational changeComment

Last Responsible Moment

Probably the least understood (or most misunderstood) lean principle is "decide as late as possible". I have seen it used to justify all sorts of weird decision-making policies that generally involve never making decisions, because surely as late as possible means leaving it until the absolute last possible moment, or even later. I have seldom, if ever, seen it applied correctly. So let's take a look at this principle and see what it really means.

The other way to express this principle is "defer decisions until the last responsible moment". There are two points of confusion here. The first is what is the last responsible moment? The other is what exactly do we mean by deferring decisions? Let's look at the last responsible moment. What is the last responsible moment? Does it mean the absolute last minute? Do we leave all decisions until we are absolutely forced to make one because otherwise the whole endeavour will fall flat? No. That makes no sense at all. Leaving decisions until they are forced upon you is hardly being responsible. Does it mean making decisions early because that's the responsible thing to do? Again, no. Making decisions early isn't using the last responsible moment. The last responsible moment is a really hard thing to define, so let's not try. Let's re-word it instead. The intent of the last responsible moment is to make decisions with the maximum possible information.

Agility, Organisational ChangeDave Martin4 September 2018decision makingComment

Rigidity = Fragility

"We need to harden this process...make it more robust. Too many things are slipping through the cracks". How many times have you heard statements like that? Things that don't fit the process take extra time to resolve, so we make sure that the process covers as much as possible. As issues arise, we tighten the process still further. Spell out the entry criteria. Map the process steps in great detail. The problem is, of course, that no matter how much detail we have in the process, things still don't always fit so we document and harden even more.

We create processes and because we are humans working with incomplete information, there are gaps. Our natural instinct then is to fill in the gaps. Tighten the process. Specify, document, enforce. The problem is that this simply doesn't work. The real world conspires against us. Customers don't always want the standard product. You may have a carefully documented 30 day SLA but that doesn't help a bit when a key customer rings up and says "We know it's usually 30 days but we really need it in 10, can you please help? If not, your competitor has said they can do it in 10 days." You may only sell in lots of 100 but what happens if a good customer rings up and asks for an extra 35 because they have had a spike in sales but don't have the space to store another full hundred? The more rigid we make our processes the more often they break down.

The Boy Scout Principle

Last time we looked at refactoring. How real refactoring isn't re-writing big chunks of legacy code, it's cleaning as you go. Making sure the code you write now is clean. But what do you do about those big lumps of legacy? They weren't written with "clean" in mind, they were written with "hack it together to meet the date" in mind instead. It's messy and it's slowing you down. What do we do about it?

Well, we need to refactor it. But how, if we can't spend the whole sprint rewriting a big chunk of it? We need to stop thinking big - think small instead. Use the Boy Scout Principle - leave the camp ground cleaner than when you found it. When scouts leave a camp ground, they spend a few minutes cleaning up. Not just their rubbish but anything else they can find left by previous campers. And crucially, they don't try to clean up the whole forest, or even the whole camp-site - that would take weeks - they just clean up the area they were using.

Organisational ChangeDave Martin24 July 2018refactoring, efficiencyComment

Clean = Fast

Whenever I mention refactoring in an organisation, I usually get the same response - "Yes, we know it's important, but we don't have time. We need to move fast. We can't afford to go back and keep tweaking things, we have to keep moving forwards". On the surface that's a reasonable sounding argument. It doesn't matter whether your organisation is big or small, established or startup, the imperative is to move fast. Get things done. Those customers won't wait, you either give them what they want now or someone else will. In an environment like that, who has time for refactoring?

I'd like to challenge that thinking. Not the bit about having to move fast, that's a given these days. No, the bit I want to challenge is the bit about refactoring being incompatible with being fast. To me, refactoring is not an impediment to being fast, it's an enabler. I think the view that refactoring slows you down stems from a serious misinterpretation of what refactoring is.

Organisational ChangeDave Martin10 July 2018refactoring, efficiencyComment

TL:DR - Information Smoothies

I have had quite a few comments over the years that I have been running this blog along the lines of - "OMG! Wall of text" or "What's the takeout here?" or "Why don't you make this an easy to read list? " or "Can you summarise into a few bullet points? " or just the basic "TL:DR". This worries me a bit. Not just because people aren't reading my stuff, but because I think this points to a much deeper problem. I think this points to the reason people and organisations find it so hard to change.

My posts are always between 800 and 1200 words. That's not exactly a wall of text. If you print it out, it's about a page and a half. The reading time is about 5-10 minutes. Maybe 15 if I really make you think. That's not a large amount of time. But yet many of us feel unable to invest that amount of time to read something. If it's hard to find time to read a short blog post, what about longer format work? An essay? A book? 200 pages? 50,000 words? I know a lot of people who tell me that they barely have time to read tweets these days. What does this say about our capacity to absorb and process new information?

Organisational Change, LeadershipDave Martin26 June 2018information, organisational changeComment

Control vs Empowerment

There has been a lot of talk at work about increasing empowerment and employee engagement. The common complaint I get from management is that "we have empowered our people but they just won't make use of it". It's a common story. Management gives empowerment but nothing at all happens. Things go on as they did before - everyone looks to management for direction. No one takes initiative. No one takes ownership. No one is empowered.

Empowerment takes more than a few words from management. You can't just tell people they are empowered and lo and behold, they are empowered. Empowerment is something people can't be given. They need to take it, it isn't something you can give. It is something people need to become. Management can't give empowerment. What they need to do is create an environment that allows people to become empowered.

Leadership, Organisational ChangeDave Martin7 March 2018decision making, empowerment, leadershipComment

The Agile Transformation. Myth Or Reality?

We have all heard about organisations that have successfully made the transition to an agile way of working. Some of us may even know someone who knows someone who says they worked at one once. But much like sightings of the Loch Ness Monster, Bigfoot or the Tasmanian Tiger, most of these claims evaporate under even basic scrutiny. Now, I know there are agile organisations out there. Organisations that have been born in the agile age and have been built from the ground up with agile principles in mind. I'm not talking about those organisations.

I'm talking about the old, legacy organisations. The ones with decades of process and culture to remake. The ones we are always being told (mostly in press releases or flashy conference presentations) are transforming themselves into new, agile organisations. Shedding the baggage of the past and embracing the bright, agile future. But scratch the surface and how many have actually managed to transform themselves? "But transformation is hard", I hear you say. "It takes time and many organisations just haven't had time to complete the job. What you ask isn't fair". And indeed, transformation is hard so let's relax the criteria a bit - how many organisations have actually managed to establish even the start of a real agile culture?

Agility, Organisational ChangeDave Martin29 November 2017organisational change, anti patternsComment