July 14, 2010

...Learn TDD with Codemanship

The Customer Holds The Key To The City of Agile

We all gripe and moan about how hard it is to get our customers to "go Agile" and play their role effectively. And it's an important role. Indeed, the customer is the key to Agile.

We have a hard sell on our hands changing the customer's mindset to embrace Agile values. But when it's the other way around - which, of course, it very rarely is - the customer doesn't have to do much to pretty much force teams to be Agile.

For example, if I was funding a software development venture (let's not call them "projects" any more) I would demand to see working software - growing working software - pretty frequently. A development team in the UK will cost you tens of thousands of pounds a week, so at the end of one week I'd want to know what that money bought me.

To deliver every week, cycles need to be short. If regression testing your application takes weeks or months, then a weekly show-and-tell will be nigh on impossible. A team would pretty much be driven into the comforting embrace of automated builds, tests and deployments. Either that or fail to meet my expectations, and risk getting canned.

And if a team or a supplier demands a complete detailed requirements specification up-front, or tries to freeze the requirements, again - as it's my money and my choice - they'd have to either adapt to work with high-level product goals for the long-term and detailed requirements for the work that's in focus for the next delivery, or be shown the door.

They would also have to accept that week-on-week, I can change the requirements based on what we've learned up to that point. I am the customer. It's my money. I reserve the right to change my mind. I'm willing to pay for those changes, so what's the problem?

What about quality? What if each drop is riddled with bugs and the devs end up spending most of their time fixing them? I'm not a programmer. How can I effect that?

Easy. I demand precise, executable acceptance tests. I can do that. I can insist. I can bring in my own test expert to help make sure it happens. She would work for me to ensure we all know exactly what should be delivered and how we'll know it works.

It's my money. So even if the devs normal modus operandi is code-and-fix development, I will not sign off on any delivery that doesn't pass my aceptance tests. Work is funded (by whatever model) week-by-week, and it's my money. Failure to deliver something that passes my acceptance tests will stop the flow of funding. Two or three painful, bug-filled deliveries in a row, and I'll withdraw my funding completely and the venture will end (or switch to a better team).

And if the team can't deliver everything we agreed in that week, well, I'll take a view on that. Is what they delivered worth what I paid for it? If, week after week, I feel I'm not getting value for money, then - yep, you guessed it - it's my money and I can decide to stop wasting it.

To meet my expectations as a customer - frequent deliveries of working software which I deem worth what I spent on it, verified by executable tests agreed with me, and adaptibility after each delivery cycle - I'm not aware of any way than to be Agile in the accepted sense of the word.

If the choice is between that and getting canned (and/or replaced with a better team), many teams will step up to the plate and find a way to do it. It can be done, this we know.

As the customer, I can set the values of the venture by setting the right expectations and doing my job in all of that. I can choose to make myself available (or someone I trust, at least) to make sure everybody gets the decisions and domain expertise they need when they need them.

The keys to the city of Agile are in my hands.

If I forget that, please remind me. It's my money, and I insist that you do. Even if I act like I don't want you to.

Posted 7 years, 9 months ago on July 14, 2010