April 12, 2005

...Learn TDD with Codemanship

Are you Agile? Where's your customer, then?

It's de rigeur at the moment to practice agile software development. Just as the Java-UML or C#-UML combo is becoming very saleable, so too are the Java/XP or .NET/XP skillsets. But I'm not 100% convinced that many of the teams who are practicing eXtreme Programming are doing it for real.

I've encountered dozens of agile projects in the last 4 years, but I'm sorry to say that none of them were actually, geniunely agile.

You see, there is a critical part of the agile jigzaw puzzle that has always been missing - the customer. Lots of teams now practice TDD, continuous integration, refactoring, and some even work in pairs (try getting that one past your project manager!), play the planning game and maintain a sustainable pace. When they advertise positions on the team they stress the agile nature of the project, but they've missed the point, somehow.

Agile does not necesarily equal "test-driven" or "planning game". The XP books and web sites make it very clear that the vital ingredient is continuous customer communication and feedback. If the customer doesn't define the requirements, set the priorities, decide what goes into the plan and write and execute the acceptance tests as each feature is delivered, then you're definitely not agile.

But customers are a scarce resource. They're often important, busy people and they can't afford the investment in time that being the customer on an agile software project requires. It's so much easier to employ business analysts and delegate the role to them. BIG MISTAKE, in my humble opinion. That's like paying someone to tell you if you like your new haircut.

The way I like to envision an agile development process is as a motor car. The TDD, continuous integration, refactoring cycle is the engine. It makes the project go forward and is the "engine" of the project - so it's fitting that the speed at which teams deliver features is referred to as "project velocity". But there's more to a car journey than how fast you're going.

You also need direction, and in agile projects that requires STEERING. To effectively steer a car, you need your hands on the wheel (control) and your eyes on the road (feedback). Now, driving from A to B is a fairly straightfoward affair. You could delegate the role to, say, a taxi driver and tell him where you want to go. That's why many projects believe that it's also possible to delegate the job of steering the project to a business analyst. But software development is far too complicated. If only it were as simple as "left here, straight ahead, next right at the roundabout". But it's not. I've seeen plenty of projects fail because the driver didn't have a clear idea of where the customer wanted to go, largely because the customer wouldn't have known for sure until they got there. That's the nature of agile development. If the customer knew where they wanted to go from the start, then we wouldn't need feedback, and we wouldn't need agile development. But they don't, and - therefore - we do.

So what do you do when the customer is too busy to be the customer on your project? Well, one solution is to genuinely delegate the responsibility AND the authority. That means you have to give someone the authority to make business decisions on your behalf. Firstly, they need to really understand your business, your strategy and where you want to be. Business analysts, despite their title, are often not experts in the business at all (bizarre, that, isn't it?) Many business analysts are actually software requirements analysts - which is an entirely different thing. So, a good first step would be to find a real business analyst - one with a deep undertanding of the business. Secondly, many business analysts have to go cap in hand to the real customer every time a significant decision has to be made - yet another strong sign that they're not playing the customer role effectively. The customer makes the decisions about what gets delivered in each release. If the customer has to go and ask someone else, then they're not really the customer. So you have to empower your business analyst to make most - if not all - of those decisions. You have to trust them to do it effectively. Trust is another agile factor that's often missing in "agile" projects.

So, you need a customer who knows your business, understands the project goals AND is empowered to act on your behalf. I beleive the legal term is a "proxy". I've yet to meet one, unfortunately...
Posted 16 years, 5 months ago on April 12, 2005