Lean Thinking

21 July 2015

Coach Addiction

Written by Published in Agile

Agile coaches help teams. Right? Having a coach to help guide a team means they are more likely to become a successful, high performing agile team. Right? That's why organisations are prepared to pay for agile coaches. But is there a down side to coaching? Can coaching hinder a team, rather than help it?

Imagine, if you will, a team. They are on about sprint 20, you are their new agile coach, taking over after the last one left. You are observing a retrospective and they are doing what they should be doing - working out what went well, and what didn't. "Why", you are thinking, "do they need a coach after 20 sprints? They seem to be doing fine". Then they get to the "what should we change for next time" bit, and all eyes in the room turn to you. "This is where you, as our coach, tell us what to do so we can get better" they say. "Work it out", you say, "Self-organise around the problem and solve it". "No", they say, "you have to tell us what to do". Then you notice that there is no sprint planning scheduled for the next sprint. "That's your job" the team says. "You tell us what to do and we do it". Welcome to the dark world of coach addiction.

Written by Published in Agile

First up, a huge thanks to Mike Pollard for the inspiration on this one. This all started with a meeting invite from Mike to set up some experiments in organisational change. We all know that organisational change is hard. Organisations tend to resist change so doing any sort of substantial change is a lot of work, and also prone to failure as organisations slip quietly back into their old way of doing things. Since real agile success relies somewhat on changing some pretty fundamental things in the organisation, this has always been a pretty major limiting factor in agile adoptions - success relies on change and is limited by how much change we can introduce. Change is hard which limits the amount of success we can have.

Mike's idea was quite simple - rather than try to change the whole organisation, why not set up some small experiments instead? That gives the organisation a low risk way to see what works and what doesn't. Once we have some successful experiments we should have some good, hard data to back us up when we push for a wider rollout.

Written by Published in Agile

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).

Written by Published in Agile

In the agile community we love fast. Fast feedback, fast delivery. Fast is good. Slow is bad. Why then is the most common complaint I get about agile - "All this team stuff distracts me from writing code. We can't deliver fast if I can't write code". That's a good point. We are taking our devs away from coding to some extent. In an agile team they can’t just sit down in a corner with their headphones on and just cut code solidly for a week. There's a lot of team interaction that has to go on to make the team run smoothly.

So are we, by doing agile, slowing down delivery of code? Quite possibly yes. But what about fast delivery? How can we say we are about delivering fast but slow down the people who are actually delivering the code? The thing is, we don't actually deliver code. If we just delivered code we would go out of business. What we deliver is working, tested, fit for purpose code. More fundamentally than that, what we deliver is business value, not code. Agile is all about speeding the delivery of value, not the delivery of code.


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