I’ve been asked to review a lot of projects and systems in the last ten or so years. 10 years ago, no-one talked about Agile development (I don’t think the phrase had yet been coined); 5 years ago very few mentioned the ‘A’ word; now every project I see claims to be Agile. What’s depressing is that, despite the very real benefits of an agile approach, very little has changed. Of course, this is a self-selecting group – sadly I’ve yet to be asked to review a totally successful project that delivered a beautifully-realised system – but my impression is that my pool of potential project reviews is not rapidly shrinking due to the success of Agile methods.
One of the common factors of the failing Agile development project is that they are selective in their application of agile development practices. They all have (or have close approximations of) sprints, user stories, prioritisation, planning meetings, daily stand-ups, and visible metrics. People talk knowingly about ‘you aint gonna need it” and “do the simplest thing”. They started out with a sustainable pace. And yet commitment dates are being missed, the customer can’t get a straight answer to when they can go live, changes in requirements are met a collective sucking of teeth and the team is afraid to touch the code in the system in case something breaks unexpectedly (as opposed to all the expected breakages that occur daily in the running system). In short, there is no agility in these Agile projects.
On the flip side, projects that achieve true agility all have a common core of practices:
- Pair programming
- Test Driven Development
- Continuous Integration
There can be quite a variation in the approach these projects take to the other stuff: there’s always a daily stand-up and usually user stories, but approaches to planning and prioritisation, the metrics gathered, the lengths and purpose of iterations can vary significantly. Sometimes the customer is on-site and heavily involved, at other times there is a set of people (let’s call them BA’s) acting as a proxy customer. There may or may not be a coach or appointed Scrum Master. But there is always the four practices above.
Of course, there’s nothing magic about these practices. All they do is establish a high degree of agility in the development team which, in turn, helps the wider project to achieve agility. Here’s why:
- Pair-programming ensures no bit of the system is understood by any one member of the team. The bus-factor for the system is zero. The team develops a shared understanding of the system at every level: code, metaphor, architecture. They learn new skills and techniques from each other. New people join the team or existing members leave without huge impacts on team productivity or ability. Teams that pair-program never say to the customer: “well we can’t estimate or deliver that because Freda’s away and its her part of the code” or “its going to take a while because the guy who used to do that has left”.
- Test-driven development concentrates the team on really doing the simplest thing possible and making sure they stay focussed on just that. It also produces an executable specification of the system that, combined with pairing, ensures no piece of the system is ill-understood or ‘off limits’. And it provides a safety net that allows the team to rapidly makes changes to the code without fear of unexpected breakages. Teams that practice TDD never say to the customer: “well we think we’re finished but we’re not sure its working properly” or “well we delivered on time but the bug count is too high to allows us to go live”.
- Refactoring is simply the processes of improving the design and implementation of the system as you go. Refactoring, or rather the clean implementation and designs it produces, combines with TDD to ensure the team can make changes to the system quickly and confidently. Refactoring makes it possible for someone who is less familiar with a bit of the system to pair with someone who is more familiar and find it easy to ‘get up to speed’. Teams that refactor never say to the customer: “Yeah, the bit of the system that’s causing all the problems is a right mess; we need to stop building features and spend some time cleaning it up”.
- Continuous integration is having one codebase that everyone changes on a continuous basis. That means: no branching (okay, maybe one branch for the live system and the trunk for the next version in development), no keeping changes on your own workstation for a few days, no integration hell. More importantly it means always having a working version of the release in development available for the customer, the users and/or the QA team to review and provide feedback on. Teams that integrate continuously never say to the customer: “Oh, that’s what you meant by XYZ. Well, we’re either going to have to go live with what we have or postpone go-live for a few weeks while we fix it” or “You can review the system in three sprints time” or “Yeah, that bits been broken for ages, I’m sure it will be fixed before we go live”.
I’ve come to think of these four practices as the ‘heart of agility’; they’re certainly not sufficient on their own but they are the foundation on which the other practices build. If that heart is missing, achieving agility is going to be extremely hard, if not impossible. If you’re working on an Agile project that is failing to deliver some or all of the publicised benefits of an agile approach, ask yourself whether you’re really doing all of these four practices all of the time. Of course there may be many factors that affect a team’s ability to deliver but, if you’re not doing these four, you could do worse than working out why not and trying to change the situation.
[Note on the title: Originally the post was called ‘The Heart of Agility” but there’s a somewhat eccentric pub I like in East London called The Golden Heart and the phrase kind of stuck. Pair programming, TDD, Refactoring and CI are not just the ugly muscle that powers agile development, there is something beautiful and valuable about how they combine.
Note on capitalisation: In the late 90’s I gave a session on why XP does away with the need for what I called ‘Big A Architecture’. Software architecture is an extremely important subject but at the time there was a whole industry being built around standards, notations, patterns and processes for software architecture that meant a lot of people could talk about Architecture and could even produce an awful lot of outputs that contributed precisely nothing of benefit to the architecture of a system under development. I see the same thing happening with ‘Big A Agile’ and try and distinguish between Agile methods and achieving agility.]