Technical stuff Requirements are like water. They're easier to build on when they're frozen.

So you’re a company delivering software and you’ve heard of this new way of doing things, have investigated it, but you’re skeptical as how the legal aspects are handled. You might be in one of these two states of mind:

• you embrace the idea of tailoring the final solution while developing it, because you would get a satisfied customer, who can adjust his/her priorities as the project develops
• you think that Scrum is more suited to the projects developed internally by companies who don’t have a client pressure because they are their own customers, who have already a specific set of resources which can be alloted and can afford changing them in the interest of the project; you just can’t picture how this could apply to web/mobile development targeted to your clients

Let’s remember what Scrum is: a way of developing software incrementally, each iteration producing shippable software. What isn’t clear, though, is the way costs are handled. Alistair Cockburn has gathered ideas for handling Agile contracts, and the team at OpenPlans has put together a list of resources which can help you understand how things are already done by others.

The idea is to choose whatever is best for your client and you. If the set of requirements is very stable, you could just go for the waterfall approach, yet by choosing Scrum you’re giving the freedom back to the client. He might feel after a while that common-sense changes should occur; by letting him know this from the beginning and negotiating the way they should be taken care, you can only gain credibility and confidence.

On the other hand, if your client has a great business idea but is not decided on how to bring it to the market, Scrum is definitely the best choice for you to refine and implement it together as a team, gathering measurable results all the way through.

And if your team is geographically distributed, you might want to watch Jeff Sutherland presenting an example of outsourced development team.

I hope you are now more confident on how to choose the right methodology for your project. I would love to hear back your arguments of choosing one path or the other.