Posts tagged flow
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.

Read More
Executive Coaching Part 3 - Resource Management

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.

Read More
Release Train? Or Release Metro? What cadence works for you?

We have all heard about the Release Train as a concept for managing agile at scale. It's a pretty good metaphor. A train leaves the station according to a set timetable. The passengers fill up the train when they are ready to depart and if you arrive late, you miss the train and catch the next one. Software releases under a release train work the same way - the train leaves the station (releases to production) according to a set timetable. While waiting, the train gets filled with completed features and if a feature arrives late, it waits for the next train.

Not a bad metaphor, and, for some businesses, not a bad way to organise a release cadence either. However, for other businesses, a release cadence like that is not appropriate. It may be too fast. Or too slow. Maybe what you need isn't a train, but a metro. On a metro, smaller trains arrive and leave so frequently that no timetables are needed. Just turn up and hop on the next train. Or is your release more like an ocean liner? Their arrival and departure is large, infrequent and marked by a lot of fanfare (and more than a little cursing by those doing the hard work of steering the thing in).

Read More
The Problem With Projects

They say that when all you have is a hammer, every problem looks like a nail. It’s the same in business – when all you have is a project management methodology, everything looks like a project. Most organisations have become very project focused. Everything is a project. New release of software – project. Some process change – project. That’s great. Projects are good. They are certainly better than the ad-hoc approach we had before projects. But projects do have some drawbacks.

To work out what the drawbacks are, we need to look at what a project is. A project is defined (by the PMI who should know) as something that has a defined scope, a defined start and a defined end date.  So projects are finite in length. Anything without an end date isn’t a project, it's business as usual.

Read More
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.

Read More