When Agile Doesn't Work

When I first started talking about agile development, way back in the last century, I was inclined to present agile solutions to every problem that was presented to me. I think this said more about me than about agile - that I was actually insecure about my ideas and understanding, so I felt I needed to look authoritative by solving every problem. As I became more secure, I was happier to say "agile doesn't solve that problem - nothing solves that particular problem". I think this is a very important transition, and with the benefit of hindsight I think it makes people sound more authoritative, or at least more trustworthy, when they readily admit limits to whatever they're advocating (I think politicians would benefit from the same approach).

The secret that zealous attackers of agile, and its zealous defenders as well, don't want you to know is this - nothing works all the time. Every approach you have needs to be modified to take your context into account, particularly your people (see Alistair Cockburn on this). I can be confident that my assertion is true because it contains a very subjective term used repeatedly in software development discussions - "works". When you have a discussion about sofware development, be very careful to check that everyone is using the same definition. There is one cheap defense of agile that would suggest that it can always "work" - agile methodologies are adaptive, so if your methodology isn't working right now, then change it until it does work. Technically that's true, but I don't think it's particularly helpful (nor is it helpful for people to ignore the principle of adaptability so they can dogmatically dump on agile, but I've already written about that).

One are of agile that might not work for you is design. I teach a course on TDD, and one of the things that I emphasise in the course is that TDD and BDUF are end points of a continuum, and that very few people (if any) really work at the end points of the continuum. In the most zealous TDD shop, some thought is being given to the future requirements and overall shape of the application, and in the most zealous BDUF shops some design is being done in response to problems detected during development (or even later). There are lots of factors that influence where you should be on the continuum, but they include design experience, technical experience, and domain experience.

One way in which agile can go wrong is by being too close to the TDD end of the continuum (it's less likely to go wrong by being too close to the BDUF end of the continuum, because of the inherent biases in adopting agility). Things go wrong when the design is moving in a bad direction, often in small increments, and the development team can't detect the problem and respond to it. I used to think that all developers with more than a few years of experience could tell when the design was heading in the wrong direction, but experience is teaching me otherwise. It makes me more sympathetic to the "architecture" groups of large companies, who want to somehow check everything that's going on in their organisation.

If you've got people who can't tell when a design is going wrong I think your choices are:

1. Don't hire them in the first place, or get them off the team in some other way


2. Educate them so that they can see what's going wrong


3. Change your process so that there's more oversight or review, to try to stop designs going wrong in the first place

In principle, XP "out of the box" uses (2), with pairing as a major mechanism for education. This works provided you have enough people with the appropriate design skills. My preference is for (1), but it's hard to find good people - that's one of the motivations for eliminating growth from my company objectives. Most companies go for a combination, with an emphasis on (3). Personally, I think that (2) can be very difficult, and that one of our weaknesses as an industry is how to demonstrate skill shortcomings and then correct them.

If you feel that agile approaches to design "don't work", I encourage you to think about whether they don't work globally, or they don't work for your team right now.