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.

Last time we started looking at my holiday workshop experience and seeing how it related to agility and infrastructure agility in particular. We looked at why the two are similar (long lead times for materials, limited rollback options for mistakes and so on). We then started to step through the process of building something out of timber and discovered a few useful rules for infrastructure agility along the way. We looked at the planning and material buying stages and discovered the first two rules for infrastructure agility -

• Have just enough information to get started. The detail will follow.

• When buying materials, give yourself a little slack. A little upfront cost leads to a lot of downstream flexibility.

Today we are going to cover some more of the process and see if we can discover some more useful rules.

Happy new year folks! Welcome back to the blog for another year. I hope you all had a great holiday break. I certainly did. I spent a large part of my break productively engaged in my workshop building things. I have mentioned this before but for those who have missed my previous workshop updates, I build things out of timber. Furniture, using traditional joinery so no nails, no screws, no fancy fasteners, just mechanical fit and glue to hold it all together. No cheap timber either. No pine. No MDF. No chipboard. Australian hardwoods all the way. To describe the process of working with expensive timber, let me put it into terms that more of my audience will understand (given that I suspect there are more software people than timber-workers who read this) - imagine working on a software project where every action you make is non-reversible. There is no source control, no revert, no undo, no control-z. Everything you do is straight to production. If you make a mistake you have to throw the whole part (and anything it is permanently glued to) away and start again with new materials, which involves a 3 hour round trip to the specialist timber yard, a lot of expense as you have buy a whole length not the little piece you need, and a long delay if they don't have what you want in stock.

So while I was building, I was thinking about just how anti-agile the whole process is. You need detailed up front plans. Once you start you really can't make changes, you are basically locked in. Materials are in limited supply, have long lead times and are expensive. There are limited options for any sort of teamwork. You can't have a team standing around a table saw. That's unsafe. In fact any more than two (one feeding, one catching and even then only if it's a big piece) and it's just not possible. You can't even have multiple people working on different pieces simultaneously (not in my workshop anyway) - there isn't the space and more than one machine at a time would start to blow fuses. So it really is a solo activity (until it gets to glue time where 7 or 8 extra pairs of hands are really handy for manipulating clamps). In a lot of ways it's a lot like infrastructure projects - expensive materials with long lead times. Detailed up front planning. Limited ability to roll back changes without massive rework. Lots of solo work doing configuration then brief bursts of activity at deploy time when it's all hands on deck. No wonder people say that infrastructure can't be done agile. But then I really looked at what I was doing and realised that most of those things describe the way I used to do woodworking a few years ago when I was starting out. What I was actually doing now, while it looked similar on the surface, was actually quite different. And quite agile.

A few months ago I saw a meme floating around contrasting a good agile team with a group of cowboy coders. Their chosen metaphor was a nautical one. The good agile team was the navy (age of sail style) - disciplined, focused, effective, working together for a common purpose. The bad team was, of course, pirates - rough, undisciplined, attacking stuff at random, scary but ultimately ineffective.

I looked at that, and knowing a little something about pirates (real ones, not the Long John Silver/Jack Sparrow/Captain Hook type Hollywood ones) it didn't quite ring true. In fact, if you look a little deeper, the age of sail navy is actually quite a good metaphor for traditional organisations and pirates actually make a great agile team. Since this is International Talk Like A Pirate Day, heave to for a moment ye scurvy dogs and let me explain.

We talk about value a lot in agile. The whole point of agile is often given as "the ability to deliver value quickly". Lean looks at value streams and flows of value. But when we say value, what do we really mean? What is value? The dictionary tells us that value is "the regard that something is held to deserve; the importance, worth, or usefulness of something."

So value describes something that is important to someone. But who? When we ask ourselves this question, we usually come up with and answer of - "the customer". This isn't a wrong answer, customer value has to be our of our key drivers. Make the customer happy by giving them what they want. That's the key to business success. But note that I said "one of our key drivers", not "our key driver". There are other "someones" out there who are also important, and often get forgotten. What about the organisation itself? Its employees?

We have all seen the press releases come out. The CTO of some big organisation proudly announces that with this new agility thing they are now able to release to market every three months instead of yearly. Great news isn't it? Great endorsement of agile techniques, isn't it? Have you ever worked in one of those organisations? What is it like working in the delivery teams for one of those organisations? Is it, as the press release seems to indicate, some sort of IT workers' paradise where features flow easily into production and there are smiles and profits for all?

Or does it feel like an endless treadmill where releasing every three months just means jumping through all the hoops you had to jump through for the yearly releases but now instead of doing it once a year you are doing it all the time? Where the nightmare month you used to have once a year to push the release kicking and screaming out the door is now your normal workload? Chances are, it's not the first one. Feeling burned out? Are we achieving our results by throwing away one of our key principles - the principle of sustainable pace?

Last time we looked at how to transform large organisations by building capability internally rather than buying capability externally. There are a lot of benefits to this approach. It's faster. It's cheaper. It's more effective. But it does fundamentally change the way an organisation sees its agile transformation program.

Most of the time, a traditional coach-led transformation program is set up to minimise the disruption to staff. Apart from some training and a new way of working (and maybe a slight blurring of strict job titles), the organisation sees its staff doing pretty much exactly the same thing they were doing before the change. Developers develop, testers test, they just do it in a new, agile way. With an internally-led transformation, this is not the case. A significant number of staff will be involved in this program for a long time. This will impact their day jobs. So the first rule of internally-led transformations is - give people time.

If you work for a large organisation and you want to transform the way you work to be more agile, what's the first thing you do? Chances are it's hiring a coach or two. That's not a bad way to start. Experienced people to guide the transformation make things much easier. But what do you do once the first pilot is done, you have proven that it works and demand is growing? More and more people are wanting agility. Your current coaches can't handle the load. What do you do?

What most organisations do is here some more coaches. And some more coaches, and more coaches and more as demand continues to grow. Now, as an agile coach, this has kept me in work for many years so I may be shooting myself in the foot a little when I say that this is a really lousy way to do an agile transformation. Yes, that's right. You heard it. An agile coach says that hiring a bunch of agile coaches is not a good way to transform an organisation. Let's look at why and then look at how we can do things better.