Execution Efficiency

It's time to continue our look at the 4 key changes needed to become a truly agile organisation. This time we will look at the second key change - execution efficiency. Now most organisations will claim to be efficient already. They make very efficient use of their resources - everything is scheduled to achieve 100% resource loading at all times and costs are kept to a minimum. Things are produced with the minimum number of people and at the minimum cost. What could be more efficient that that?

From a pure, cost efficient sense, they are right, so I'm going to carefully define what I mean by efficiency here. It's not cost efficiency. What I'm talking about is how efficiently the organisation can turn ideas into value. How long does it take, and how much does it cost to take an idea and turn it into a real product or service that generates business value? Isn't that the same as resource efficiency? No, it isn't.

Agility, Organisational ChangeDave Martin17 October 2018organisational change, patterns, efficiency, flowComment

The Boy Scout Principle

Last time we looked at refactoring. How real refactoring isn't re-writing big chunks of legacy code, it's cleaning as you go. Making sure the code you write now is clean. But what do you do about those big lumps of legacy? They weren't written with "clean" in mind, they were written with "hack it together to meet the date" in mind instead. It's messy and it's slowing you down. What do we do about it?

Well, we need to refactor it. But how, if we can't spend the whole sprint rewriting a big chunk of it? We need to stop thinking big - think small instead. Use the Boy Scout Principle - leave the camp ground cleaner than when you found it. When scouts leave a camp ground, they spend a few minutes cleaning up. Not just their rubbish but anything else they can find left by previous campers. And crucially, they don't try to clean up the whole forest, or even the whole camp-site - that would take weeks - they just clean up the area they were using.

Organisational ChangeDave Martin24 July 2018refactoring, efficiencyComment

Clean = Fast

Whenever I mention refactoring in an organisation, I usually get the same response - "Yes, we know it's important, but we don't have time. We need to move fast. We can't afford to go back and keep tweaking things, we have to keep moving forwards". On the surface that's a reasonable sounding argument. It doesn't matter whether your organisation is big or small, established or startup, the imperative is to move fast. Get things done. Those customers won't wait, you either give them what they want now or someone else will. In an environment like that, who has time for refactoring?

I'd like to challenge that thinking. Not the bit about having to move fast, that's a given these days. No, the bit I want to challenge is the bit about refactoring being incompatible with being fast. To me, refactoring is not an impediment to being fast, it's an enabler. I think the view that refactoring slows you down stems from a serious misinterpretation of what refactoring is.

Organisational ChangeDave Martin10 July 2018refactoring, efficiencyComment

Are Hyperproductive Teams Real?

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.

Agility, Organisational ChangeDave Martin15 November 2017team, organisational change, efficiencyComment

Control Charts

A couple of posts ago I promised you a post on Control Charts. Here it is. For those of you who have never come across these before, they are come from the field of Statistical Process Control (no... really... don't go...stay with me here... it's worth it, I promise). They provide a means of charting process data in a way that answers the single most important question you should be thinking of when looking at a chart of process data. No it's "not when can I go home?", or even "I wonder whether stabbing myself in the eye with this pencil will be more interesting?". It's – "what's normal?". When does the chart show normal variation and when does it show something I should be concerned about? Is this spike in the data something I need to investigate, or is it normal?

There are about a dozen different types of control chart for different types of data and you can use the various types to build a chart for just about any metric you choose, but for an agile project the most useful ones to chart are Velocity and Lead/Cycle Time. Even better, these two metrics use the simplest possible type of control chart – the IMR chart or Individual & Moving Range chart.

AgilityDave Martin19 August 2014metrics, measurement, efficiencyComment

The Black Ecconomy

When you work in a large company, one of the things you hear quite often is “we have to follow the process”. Large companies, for very good reasons, have a need to standardise their processes. If you have 50,000 staff, having one way to do things makes a lot of sense. No matter where someone goes in the organisation, the process for ordering a new pen, or whatever, will be the same. The problem with defined processes though, is that unless they are regularly reviewed and cleaned up, they tend to accumulate complexity. Each time something happens that is just outside the normal way the process works, someone will add some extra checks into the process to make sure that that situation is now covered. Over the years it will collect enough of these extra checks that your carefully considered and streamlined pen ordering process now requires a 10 page form, 15 signatures and about 4 hours (and in some companies a pint of cockerel’s blood). The end result is that everyone spends all day looking for pens.

AgilityDave Martin24 June 2014continuous improvement, process, process improvement, efficiencyComment

When You Are At The Bottom Of A Hole

When a team is behind its targets, the natural instinct is to work even harder to catch up. Sometimes though, the best thing you can do is… nothing.

Let’s look at a team. For various reasons, they have done several sprints' worth of work with no test environment available. How can this be? Let’s just imagine that they work for a hypothetical large company with a ludicrously complex process around setting up test environments. I’m sure such things never happen in real life, but just go with me on this one.

AgilityDave Martin28 October 2013flow, efficiencyComment

The Importance of Slack

Hi Folks

In many companies, resource utilization is considered an important measurement. The idea is that resources, whether they be machines or people should be occupied as close to 100% of the time as possible doing chargeable work. On the surface this looks pretty sensible. No point having people spending time doing things that the company doesn't make money from is there? The more time people spend working on chargeable tasks, the more money the company makes. Right?

AgilityDave Martin24 May 2013optimisation, efficiencyComment

Scrum - It's Not All About The Developers

I recently checked back in on a team I had started up a while back. Over the months since I had set them free they had made a few modifications to the process and in doing so had fallen into one of the most common traps I have seen teams fall into - they had made it all about the developers.

My first inkling that there was something amiss came when one of the testers on that team approached me for some advice on how she could be more efficient in her testing. She felt she was falling behind. When I dug a little further it turns out the team had delegated the job of unit testing to the testers to "free up the devs". This was in addition to the acceptance test automation the testers were doing as well. The devs had also resisted any attempts to assist with testing so "they could be more efficient".

AgilityDave Martin1 April 2013efficiency, optimisationComment