Lean Thinking

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.

Written by Published in Agile

Faster, Better, Cheaper. That's the way agile is usually sold. Faster delivery, with better quality and lower cost. That's the pitch I hear over and over from people trying to get organisations on board with agile. It's an attractive pitch too. Who wouldn't want something faster, better and cheaper? The only problem with the pitch is that it's not really true. Not initially anyway. Agility will eventually get an organisation delivering faster, better and cheaper but, at least initially, it will be slower and more expensive (it will usually be better quality though). It may well stay slower and more expensive for a long time if the organisation has to overcome a lot of legacy (not just code but culture and processes as well).

So when the organisation goes to measure its new agile initiative and finds that it's not getting what it was sold, questions get asked. And well they should. The first is usually "Why?", to which the standard answer is "cultural change is hard....", the next is usually "When?", to which the answer is usually a shrug and some more about how hard cultural change is. This is often the point where the senior leaders that were really keen on agile, suddenly stop being keen on agile and organisational support vanishes. Given the length of time it takes a big organisation to get to faster, better, cheaper with agile, we really do ourselves no favours by using that as our selling point. What we need is something we can have an immediate (or at least relatively quick) impact on, that is also going to have a positive impact on the business. Fortunately it exists - risk. Agility should be sold as a means of reducing risk.

Written by Published in Agile

This post is the result of a conversation I had the other day, over a few after-work beers with Andrew Knevitt. He deserves a large part of the credit (and/or blame) for this for starting the ball rolling. Andrew was bemoaning the amount of legacy he had to deal with and I immediately started talking about code and automated testing. This wasn't what Andrew was referring to though. He was working mostly with business process and was referring to the problem of legacy business process. We all know the problems of legacy code - hard to maintain, fragile, lots of manual testing required. Legacy business processes have similar problems - clumsy, fragile, constantly out of date, lots of manual work required, and so on.

We both agreed that legacy process was a problem but neither of us could come up with a good explanation of what made a business process legacy. It's more than age - some old processes work really well but some brand new ones are out of date as soon as the ink is dry. So what makes a business process legacy? During the course of the discussion, I trotted out one of the more common definitions of legacy code - legacy code is any code written without automated tests. That was when the lightbulb went on for both of us. Legacy business process is any business process without a built-in feedback loop. But not just any feedback loop. A 2 yearly process review cycle isn't enough. It has to be fast feedback.