So you've gone out and convinced a customer that you're the agile development team for the job. You've nailed down some expectations and codified it all in a neat little contract with a Statement of Work which spells out everything you're going to be expected to do.
There's just one little thing... A month or two into the project, your customer, with whom you're very engaged and meeting on a regular basis, has realized that their business has changed a bit, so they need to alter some of the work they need you to do. They need you to be...agile!
You're faced with a choice. You can stick to your guns, point to the SOW and the contract and tell them that's not what they asked for.
You can adapt. You can be agile. You can sit down with them, pull in the agile development team and go over the requests until everyone understands them. The team can then discuss them to ensure they understand how much work the changes represent.
A contract is a great thing, but it presumes a certain amount of adversarialness in the relationship. In agile development, we try to build our team in such a way that it includes a customer representative. It is, in fact, that person who is directly responsible for maintaining the ordering of tasks that the team is to work on next.
Delivering what the customer asked for early in the process assumes they knew what they wanted at the beginning. We know better. Needs change, perspectives change, environments change. Business changes. Agile allows for those changes, even encourages them.
Your relationship with your customer is far more important than some piece of paper you carved out way back when you were both naive about the project. Shake hands and continue to be partners.
This, by the way, is the point of the third value in the Agile Manifesto; valuing the ongoing interaction with our customer more highly than we value the fixed-in-stone contract.
Avoiding Scope Creep
Agile development in almost all its forms is about keeping the scope fixed by fixing the duration of the project. We don't allow the project to run long. There's no option for extending. So the only way to introduce new work is to let something fall off the list.
In agile development, we manage this by keeping our backlog (the technical term for the list of work to be done) in order so that the next work to be done is always at the top. Items at the bottom may never get done.
Tomorrow, we'll discuss some agile techniques for how to actually make this happen, including agile estimation and backlog management, that aren't just for software development any more!
Would you rather point your customers at the contract, or would you rather be agile and show your flexibility? Leave a comment and join the discussion!