Lean Thinking

Published in Agile

What's the first thing you do when you look at a map? Find your destination? Maybe. Start planning a route? Sounds logical. But there is something missing. One fundamental step that renders the other two useless. That first step is locating where you are. Obvious really, but essential. Unless you can position yourself accurately on the map, no amount of accuracy in destination identification, or time spent in route planning, will get you where you want to go.

That's obvious when looking at a map. Very few of us (my mother excluded) will locate our destination then confidently set off without working out where we are now. My mother, on the other hand, will locate her destination, see that it is on the left hand side of the map and confidently set out towards the left. Consequently her excursions often end up in interesting places. Trouble is, the same principle applies to organisational change and in that context, very few of us perform the first step. We jump straight into desired state, plan a few actions and off we go. We don't spend much time, if any, on step one. We don't measure where we are first. The result is exactly the same as looking at a map without locating youself on it. You will start off confidently in a random direction and end up... somewhere. If it's at your intended destination that will be by good luck (or the help of someone you asked for directions) rather than good map reading.

Tuesday, 13 October 2015 18:33

Release predictability not speed

Published in Agile

When talking to stakeholders about why they want their project to go agile, the most common reason they give is speed. Faster time to market. Faster delivery. Fast, fast fast. If you dig a little deeper though, and ask what they mean by fast, they don't say things like "before our competitors", they will say things like "when you promised it". A lot of the time, speed is a kind of code for "no delays". Make us a commitment and stick to it. Don't jerk us around. What they are really looking for a lot of the time is not more speed in delivery but more predictability.

Predictability is really important to the wider business. They may have trade shows booked, advertising campaigns locked in, shareholder briefings prepared. If commitments aren't met, it can have big impacts on the rest of the organisation. I know of one organisation who sent out letters to a million customers advising of a change on a particular date, only for that date to slip by 6 months. Not only is that not a good look, it's expensive too, as a million other letters needed to be sent out advising that the change would not, in fact, be happening, then another million when the new date was announced. Fortunately, an agile approach is ideally suited to giving the business the certainty it needs. How can this be when the agile approach doesn't try to lock down everything in advance? How can you have predictability without certainty?

Published in Agile

Faster, Better, Cheaper. That's the way agile is usually sold. Faster delivery, with better quality and lower cost. That's the pitch I hear over and over from people trying to get organisations on board with agile. It's an attractive pitch too. Who wouldn't want something faster, better and cheaper? The only problem with the pitch is that it's not really true. Not initially anyway. Agility will eventually get an organisation delivering faster, better and cheaper but, at least initially, it will be slower and more expensive (it will usually be better quality though). It may well stay slower and more expensive for a long time if the organisation has to overcome a lot of legacy (not just code but culture and processes as well).

So when the organisation goes to measure its new agile initiative and finds that it's not getting what it was sold, questions get asked. And well they should. The first is usually "Why?", to which the standard answer is "cultural change is hard....", the next is usually "When?", to which the answer is usually a shrug and some more about how hard cultural change is. This is often the point where the senior leaders that were really keen on agile, suddenly stop being keen on agile and organisational support vanishes. Given the length of time it takes a big organisation to get to faster, better, cheaper with agile, we really do ourselves no favours by using that as our selling point. What we need is something we can have an immediate (or at least relatively quick) impact on, that is also going to have a positive impact on the business. Fortunately it exists - risk. Agility should be sold as a means of reducing risk.

Tuesday, 12 May 2015 16:52

Legacy Is Anything Without Feedback

Published in Agile

This post is the result of a conversation I had the other day, over a few after-work beers with Andrew Knevitt. He deserves a large part of the credit (and/or blame) for this for starting the ball rolling. Andrew was bemoaning the amount of legacy he had to deal with and I immediately started talking about code and automated testing. This wasn't what Andrew was referring to though. He was working mostly with business process and was referring to the problem of legacy business process. We all know the problems of legacy code - hard to maintain, fragile, lots of manual testing required. Legacy business processes have similar problems - clumsy, fragile, constantly out of date, lots of manual work required, and so on.

We both agreed that legacy process was a problem but neither of us could come up with a good explanation of what made a business process legacy. It's more than age - some old processes work really well but some brand new ones are out of date as soon as the ink is dry. So what makes a business process legacy? During the course of the discussion, I trotted out one of the more common definitions of legacy code - legacy code is any code written without automated tests. That was when the lightbulb went on for both of us. Legacy business process is any business process without a built-in feedback loop. But not just any feedback loop. A 2 yearly process review cycle isn't enough. It has to be fast feedback.

Tuesday, 28 April 2015 18:24

Outcome Based Funding

Published in Lean

So last time I talked about large companies and some of the reasons why they make sub-optimal decisions. Not bad decisions, but ones that aren't as good as they could be. The main reason for sub-optimisation was centralisation of decision making and the main reason for centralisation was the need for control. In particular the control on spending money. With no central control of funding, anyone could spend a bunch of company money and the company would soon be broke.

If decentralised decisions are more optimal because the person making them has more information than someone further from the coal face, but centralisation is required for spend control, what are large companies to do? Are they doomed to make sub-optimal decisions forever? Fortunately, no. There are ways of maintaining centralised control of spend while allowing decentralised decision making about where to spend money. There are, in fact, many ways to do this and we will look at one of them now. I'm calling it outcome based funding; I'm sure the financial folks have a fancy, official name for it, but outcome based funding will do for now.

Calendar

« April 2018 »
Mon Tue Wed Thu Fri Sat Sun
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30