Lean Thinking

Published in Agile

Take a thin steel rod. I'm sure you have one handy. Clamp one end in a vice (which you also have handy...I know I do) so that it's sticking straight up in the air. Now move the free end of the rod to the side a little and let it go. What happened? Did it spring right back? OK, now move it a little further. Still springing back? If you keep going, moving it a little further each time, you will find a point where the rod no longer springs back but bends permanently. Materials scientists call this the elastic limit. Below this limit, materials experience elastic deformation - they spring back to the way they were before once the force is removed. Above this limit, they experience what is called plastic deformation - they no longer spring back but permanently change shape.

So why am I giving you this lecture in materials science? Because organisations behave the same way. When you apply a force to them - when you change something - the organisation is very good at snapping straight back to the way it was before.  As soon as you stop pushing the change, the change disappears. We've all seen it happen. As soon as you relax, the change evaporates and within a short time the organisation is happily doing what it has always done.

Tuesday, 12 April 2016 11:09

The Team As A Decision Making Unit

Published in Agile

Teams hold a special status in agile. Teams are at the heart of all agile frameworks and much of the focus of the agile community is on growing and supporting teams. Not just any teams, agile teams stress things like self organisation and cross functionality. There is no denying that a really good agile team is an awesome sight to behold. The amount of stuff they can get done is nothing short of remarkable. But there are also an awful lot of agile teams that have the same properties but their performance isn't anywhere near as good. So what is wrong with those teams? Is it the people? Is it the environment? Is it the nature of the work? What stops some teams from performing where others with the same characteristics flourish?

In an effort to understand why, I have been thinking deeply about the concept of the team; why they are so effective and why we insist on certain characteristics for our agile teams. The conclusion I have come to is that it's all about the ability to make decisions.

Tuesday, 16 February 2016 10:05

Measuring Agile Success

Published in Agile

As soon as you talk to anyone senior in an organisation about agility, one of the first questions that comes up is "How do we measure the benefit?" It's a perfectly valid question to ask. We are (usually) asking them for a bunch of money to implement change and quite often the benefits we describe are fairly poorly defined - better staff engagement, the ability to respond faster, faster time to market. That sort of thing. They all sound great but what really matters to an executive sponsor is the bottom line impact. Will spending this money generate additional profit? 

Unfortunately, the question of measuring agile benefit is a hard one. Other than time to market (which is actually a hard one to pull off for a bunch of reasons), all the traditional agile benefits are pretty soft. It's hard to come up with a set of hard, bottom line benefits we can easily measure and show the difference agile is making. This tends to make a lot of agile sales pitches a bit like the underpants gnomes in South Park - Step 1: Implement agile. Step 2:Ummmm. Step 3: Profit! While the ultimate metric is the profit, for the reasons I mentioned above, that's actually quite a hard metric to impact on the short term. What we need are a set of good metrics that can show progress towards increased profitability that we can measure and track in the short term. Don Reinerstein is an advocate of using an economic model to show benefits and while this is undoubtedly the right way to go, most organisations simply don't have the maturity to even consider things like cost of delay accounting until they are quite a long way into their agile/lean journey. What we need are things that any company can measure right from day one that we can use as leading indicators for increased profitability. Over the years I have come up with a set of metrics that seem to do the trick.

Published in Agile

We have been looking at executive coaching and what sorts of conversations we can have with them as coaches. So far we have looked at resource management and financial control.  Continuing on our theme,  I'll be looking at the next burning question execs tend to have -  "How do I ensure good ROI in an agile environment?"

ROI is a term that frightens non financial folks but what it boils down to is "am I getting good value for my money?" Is the money I am spending giving me enough benefit to justify spending it? In a traditional organisation, ROI is managed through the business case and estimation processes. The business case will set out a number of benefits and the estimation process will work out how much it  will cost to deliver those benefits. In an agile environment, we don't go through those processes.  We don't do detailed up front estimates.  So how does the person in charge -  the person whose money we are spending - make sure they are getting good value?

Published in Agile

Last time we looked at the most common question you get when talking to senior leaders - how to control spend. This time, we'll look at probably the next most common one - how to control resources. By control resources, I don't mean how to tell people what to do. What I mean is how to keep control of resource numbers. In non-business speak, that means "how can I manage the number of people in my team and still deliver?" This is, of course another side to the "how do I control costs" discussion, and is a particular problem for IT departments.

The answer seems obvious - just stop hiring people. Set a staff limit and stick to it. The reality for IT departments is a little more complex though and it's related to the way big organisations control the flow of work. Or to be more precise, how they don't control the flow of work.

Calendar

« January 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