Lean Thinking

Written by Published in Agile

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.

The next part of the process is actually building the thing. Taking the raw timber sheets, assembling them into panels. Cutting to size. Cutting the joints. Gluing up and clamping. This is the real non-reversible part of the process. Once you cut a piece of timber you can't un-cut it. It can be somewhat nerve-wracking looking at a $200 sheet of timber and hacking it in half with a large drop saw. If that cut is in the wrong place, that's an expensive mistake. You don't get much leeway either. A mm too long or short and the finished piece won't go together without a bunch of crooked sides and visible gaps. I used to make a lot of those sort of mistakes. It's hard to be fractions of a mm perfect with large power tools.

Written by Published in Agile

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.

Written by Published in Agile

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?

Written by Published in Agile

We have all heard the story of the hyperproductive team. That beautiful creation that is 400% more effective that regular teams. The team that never stops getting better. But how many of us have actually seen such a thing in the flesh? I have been lucky enough to see one or two but most teams never reach those lofty heights. Why? Is it because we have the wrong people? Not smart enough? Not talented enough? Not committed enough? I don't think so. I have seen very talented teams struggle while teams that had much less raw talent went on to do great things. Although talent helps, there is no guarantee that a talented team will become hyperproductive and a less talented team will not.

Is it the methodology they use? Is scrum the recipe for hyperproductive teams? Is it Kanban? Crystal? SAFe? Less? Again, none of these things seem to matter. I have seen teams struggle and succeed with all methodologies. So what is it then that allows some teams to become hyperproductive? In my experience, there is one thing that allowed my hyperproductive teams to become hyperproductive - they are parts of hyperproductive organisations. The hyperproductive team is a myth.

Calendar

« August 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 31