Lean Thinking

Written by Published in Agile

Last time I looked at one of the common traps an organisation can fall into - the solution trap. Going straight for a solution rather than stopping and thinking about the problem first. Today I'd like to explore another common trap - the productivity trap. Productivity is usually seen as a good thing. The more productive we are, the more we get done with the same level of investment, so we are better off. The more time we spend on productive tasks (and the less we spend on unproductive tasks) the better.

Generally that is the case. The difficulty comes in the definition of what is a productive task. Working directly on something that is valuable to customers and will make money for the organisation is clearly a productive task. But what about things like maintenance? Upgrades? Training? Process improvement? Exploration of new ideas? Where do you draw the line between a productive task and a non productive task? And why does it matter?

03 April 2018

The Solution Trap

Written by Published in Agile

"Don't come to me with problems", says the boss, "Come to me with solutions". We've all heard it before. It's supposed to be terrifically empowering - giving people the agency to fix their own roles instead of expecting the boss to do it for them. It's become a kind of mantra for modern management. Empower your people. Ask them for solutions. And it can be empowering. Sometimes.

Quite often though, I find myself talking to a leader in an organisation who says something like "I don't like having problem discussions with my people. They always just whinge at me. They never come to me with solutions. I have empowered them to come up with solutions but they don't, they just whinge all the time". When we look a bit deeper at the reasons for that (usually by asking the leader what they would do about the problem if they had to solve it), it's usually because the problem is actually quite hard to solve. There may not be a clear solution. The symptoms are usually apparent but the causes may not be. The data to understand and solve the problem may not exist. Jumping straight to a solution in this case is not a good idea. I call it the solution trap.

Written by Published in Agile

I have been talking a lot about leadership and the part leadership plays in agility. A lot of the feedback I get on that are comments along the lines of "that's great but I can't talk to leaders". When I dig further, there are two separate problems here. One is an access problem. Some organisations make it difficult to talk to leaders, and sometimes someone will be in an engagement at a level where access is extremely difficult to arrange. Team coaches can often find it hard to get access to senior leaders because they are engaged at the team level. There isn't much I can do about that problem. The other class of people are ones who basically respond "because I don't know how".

The facetious answer is "well you engage your brain, open your mouth and words come out". But so many people have said it that it got me wondering why. Why do so many people have this in their heads? Why do so many people say to me that " you can't just walk up to leaders and talk to them, you need to handle them differently". Why do I keep getting told that "only specialist leadership coaches can talk to leaders"? Apart from specialist leadership coaches trying to secure their future work pipeline, that is all absolute crap. Leaders are people just like the rest of us, with the same concerns and pressures as the rest of us. They are not some alien species that needs to be handled in a special way. I think the main problem is a language one. People start talking to leaders in the same way they talk to teams and it just doesn't connect. Then they get discouraged and leaders become this remote species that you can't talk to. So I'm going to give you my 7 point cheat sheet for leadership communication to help get those conversations started.

Written by Published in Agile

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.

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.

20 December 2017

Happy Holidays

Written by Published in Agile

It's supposed to be jolly, with mistletoe and holly... and other things ending in olly.

Terry Pratchett - The Hogfather

Hi Folks

Just a quick note to wish you all a very happy holiday season. Whatever you celebrate be it Christmas, Hanukkah, Festivus, or indeed Hogswatch, have a very happy and safe one. With plenty of things ending in olly. 

I'm taking my usual few weeks off from writing so I'll see you all again in February 2018.

Cheers

Dave

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?

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