Lean Thinking

Written by Published in Agile

For the last few weeks (interrupted briefly by the holiday break) we have been looking at executive coaching. We have taken a look at some of the big problems executives face and at some of the ways we can use agile tools to help resolve them. We have looked at resource planning, controlling financial spend and estimating ROI. All these things, though, are manifestations of a more fundamental problem - the problem of control. Control is a real issue for executives. They are responsible for a P&L. They have business goals to meet. They have people under them to meet those goals. They are expected to be in control.

In a traditional environment they maintain control through their position as central decision maker. Any significant decision will be funnelled up through them. In an agile environment we recognise that centralised decision making is slow and inefficient, so we decentralise the decision making for efficiency. The problem is that, to the exec, we have taken away their decision making (and therefore their control) and not given them any other control mechanism to replace it. Without some alternative control mechanism, execs in an agile environment will continue to rely on their old control mechanism - centralised decision making - to the detriment of the agility of the group. All the unnecessary steering committees, status reports, executive briefings, financial controls, and so on are all manifestations of this fundamental problem - how does an executive maintain control when they are no longer the one making all the key decisions?

Written by 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?

Written by 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.

Written by Published in Agile

Last time I talked about executive coaching and the need for coaches to engage with senior leaders. A lot of the comments I got were along the lines of "great idea but I have no idea what to say to them. I can relate to teams because I used to be a developer. I've never been a senior leader so I don't know that their problems are". That's fair enough. It's hard to relate to something you have never been exposed to so I'll throw out a few suggestions to get conversations started. Once the conversation has started, it will take its own course.

In my brief stint as a senior leader, and in my many subsequent interactions with senior leaders, there are 4 key conversations that come up over and over again. Financials is usually a popular one - how to maintain financial control in an agile environment. Resource management is another one. There is usually a good conversation to be had around the age old question of measuring return on investment, otherwise known as "how do I make sure I get my monies' worth?". The last one I will cover is control - how do executives maintain control of their portfolio when decisions are being delegated to product owners and teams. But first financials. I know...boring. Try to stay awake here, this may be dull, and involve dealing with finance people, but it is important stuff.

10 November 2015

Executive Coaching

Written by Published in Agile

In the agile community, we tend to focus a lot on teams. This is a natural thing to do as building high performing delivery teams is where agile started. We tend to see management as an impediment to good team functioning. We talk about "the frozen middle" and "lack of executive support". We teach scrum masters and product owners how to shield their teams from management.

If we are going to stay in delivery team land, this is fine. We can build high performing teams and shield them from management as we always have, but if we want to take agile further - build truly agile organisations rather than just agile delivery teams - we need to take a different approach to management. We need to start engaging them as allies rather than treating them as the enemy.

There are limits to how far we can go with just teams. By just optimising delivery within a larger organisations that is disfunctional, we sub-optimise. Teams will deliver efficiently, but they will not be delivering the right things for the organisation and its customers. The work that makes it into the teams will not be the right work. The system that feeds the teams is still broken.

If we want agile organisations, we need to fix the whole system, not just delivery teams. As Demming said -

"The workers are trapped in a system and the system is owned by management"

So to fix the system, we need to fix management.

Easy to say, much harder to do.

The big problem we have with reaching out to senior leaders is that many large organisations (the sort that can afford agile coaches) tend to be very hierachical and as a lowly agile coach, it is often difficult to navigate the layers and get access to the people who can fix the system. In some large organisations, senior leaders are revered almost like demigods... a hush will decend on the room... A GM has graced us with their presence. Everyone put on a tie and look smart. There is actual, real fear of these people. You can feel it when they walk in the room.

But you know what? Once you do get to talk to senior leaders, you find out that they are people. People, doing pretty much what the rest of us do - working in a job and trying to do their best at it in an environment that keeps shifting around them (ony they tend to wear nicer suits while doing it). Just like us they are trying to make the best decisions possible with very limited information and under enormous time pressure.

They are also quite often extremely isolated. Particularly in companies with a very aggressive management culture. They have to be seen to have all the answers. Reaching out to their peers for help is equated with weakness and they will be eaten alive. Often they feel overwhelmed and really struggle with uncertainly. This manifests in many ways, from the overly agressive crash or crash through manager to the indecisive, won't make a decision without mountains of data manager and everything in between.

In short, they are people. Real people, just like the rest of us, dealing with the same real problems the rest of us deal with, but often without the support network of peers that the rest of us can draw on for support.

They are often actively looking for advice and help on how to do better (ever wonder why there are so many management books on Amazon?). What we need to do as agilists and coaches is to show them that we have something to offer that they can make use of in what they do. We need to be able to show that we can help them.

Again, easy to say... but how do you get access? How do you start that conversation? You start with what you have. You obviously have access to someone on the organisation, otherwise you wouldn't be there. Ask to talk to their boss to find out what problems they have with the way things run and how you can help solve them. It really doesn't matter how low in the organisation you start, just get started. Talk to their boss. Have a conversation about their role and the challenges they face in it. Find out what their biggest pain points are.

Frame the conversation around the agile transition that is happening lower down - "Change is happening, how can I help make your job easier in the face of that change?" That way it looks like they are managing change rather than asking for help.

9 times out of 10 it will be a plea for data to help them understand progress without the usual gantt charts. That's an easy one to solve. It doesn't really matter what the problem is, use your skills and techniques as an agilist to help them - problem with scheduling work? Teach them Kanban. Problem with resource management? Teach them WIP limiting.

Once you have that initial conversation going, expand it. See what you can offer for their other non-agile problems. Become a trusted advisor.

Then ask to talk to their boss. And so on up the chain. Also ask to talk to their peers in other areas of the business. Use them as a bridge into areas you don't have direct access to. Build a network of introductions upwards and outwards.

Providing coaching and advice to executives is one of the most valuable things we can do as coaches. If we really want to transform organisations and unlock their potential, we need to get senior leadership on side and involved. We can't do that if we stay down at the team level. We need to show that we have something to offer at their level as well and the only way we are going to do that is by becoming their trusted advisors. We need to become coaches for the organisation, not just its teams.

Written by Published in Agile

What's the first thing you do when you look at a map? Find your destination? Maybe. Start planning a route? Sounds logical. But there is something missing. One fundamental step that renders the other two useless. That first step is locating where you are. Obvious really, but essential. Unless you can position yourself accurately on the map, no amount of accuracy in destination identification, or time spent in route planning, will get you where you want to go.

That's obvious when looking at a map. Very few of us (my mother excluded) will locate our destination then confidently set off without working out where we are now. My mother, on the other hand, will locate her destination, see that it is on the left hand side of the map and confidently set out towards the left. Consequently her excursions often end up in interesting places. Trouble is, the same principle applies to organisational change and in that context, very few of us perform the first step. We jump straight into desired state, plan a few actions and off we go. We don't spend much time, if any, on step one. We don't measure where we are first. The result is exactly the same as looking at a map without locating youself on it. You will start off confidently in a random direction and end up... somewhere. If it's at your intended destination that will be by good luck (or the help of someone you asked for directions) rather than good map reading.

Written by Published in Agile

When talking to stakeholders about why they want their project to go agile, the most common reason they give is speed. Faster time to market. Faster delivery. Fast, fast fast. If you dig a little deeper though, and ask what they mean by fast, they don't say things like "before our competitors", they will say things like "when you promised it". A lot of the time, speed is a kind of code for "no delays". Make us a commitment and stick to it. Don't jerk us around. What they are really looking for a lot of the time is not more speed in delivery but more predictability.

Predictability is really important to the wider business. They may have trade shows booked, advertising campaigns locked in, shareholder briefings prepared. If commitments aren't met, it can have big impacts on the rest of the organisation. I know of one organisation who sent out letters to a million customers advising of a change on a particular date, only for that date to slip by 6 months. Not only is that not a good look, it's expensive too, as a million other letters needed to be sent out advising that the change would not, in fact, be happening, then another million when the new date was announced. Fortunately, an agile approach is ideally suited to giving the business the certainty it needs. How can this be when the agile approach doesn't try to lock down everything in advance? How can you have predictability without certainty?

15 September 2015

Blame Culture

Written by Published in Agile

Got a team that isn't performing? Won't raise issues in the retrospective? Acting like group of individuals rather than a team? Product owners constantly changing priorities mid-sprint? Scrum masters not protecting the team from interference? Team communicating via email instead of talking? That's quite a laundry list of dysfunction, isn't it? You would think you have a whole bunch of problems to solve, but if you are seeing all of these at once in a team that has been together for more than a sprint or two, chances are you only have one. It's a big one though. There is one really common dysfunction that can cause a whole range of problems. Usually, it's not a problem with the team, it's a problem with the wider organisation. What could well be to blame for your team's problems is...blame.

A corporate culture based on assigning blame for failure can manifest in a wide range of bad behaviours. The first casualty of a blame culture is trust. If everyone is frightened of being blamed for something, they will tend to start deflecting blame to others - "it's not my fault... Fred didn't get his part done in time...blame him!" Naturally, teamwork suffers as people retreat into self-protective shells and start communicating via documents and emails so they have evidence to back up their side of the story when blame time comes round. Naturally, this sort of thing makes teamwork pretty difficult. As soon as blame starts getting handed around, trust evaporates and with it goes teamwork.

Calendar

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