Lean Thinking

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.

Written by Published in Agile

There seem to be two camps of agile coaches, those that advocate deeply embedding into a team and essentially becoming part of the team, deeply involved in the day to day stuff that the team does, and those that prefer to take on more of a mentoring role rather than being an active part of the team's day to day activities. For a long while, I was very firmly in the coach as mentor camp, and to a large extent, I still feel that that's the most effective coaching style long term. However, I have changed my opinion somewhat on the value of deeply embedded coaching for new teams.

I am now of the opinion that a coach needs both styles available to them and to be able to choose which is best in the situation they find themselves in. As both approaches have their strengths and weaknesses it is worth taking a look at both to see where they can be applied best.

Written by Published in Agile

Hi Folks. Something a bit different today. It's a video post. Specifically, the video of my talk at the Agile@Scale Meetup in Sydney a couple of weeks ago.

https://www.youtube.com/watch?v=5rC54siNInA will take you there (Sorry... can't embed the video).

The presentation I used can be found on Slideshare here, or on my Google Drive here.

And if you want to know more about the Agile@Scale meetup, you can find them here.

04 August 2015

Pair Coaching

Written by Published in Agile

One of the main technical practices that we recommend for teams is pair programming. Under pair programming, two people work on the same piece of code, with each checking the other's work in real time. It's a great way to boost the quality of the code delivered. It's not just code either. It works for testers (one of the most effective pairs is a developer and a tester pairing on something), UX designers, business process folks and so on. Any sort of work can benefit from a second pair of eyes.

Why then do agile coaches tend to work alone? It's very rare to see two coaches working together on anything. While we teach pairing, we coaches tend to work solo. I think this is unfortunate. On the few occasions where I have had the opportunity to work closely with another coach, it has always been a really good experience. So why then don't we do it more often?

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.


« November 2017 »
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