On the rails-business list, someone asked recently about Iteration Based Contracts.
“Iterations” in the software development world are a simple, yet powerful concept for developers and businesses. An Iteration is a pre-defined timeframe, usually 1 or 2 weeks, a pre-defined cost, and a general overview of the functionality and goals of an iteration (see also: Iterative and Incremental Development).
Some examples of Iterative development might have one goal:
- Develop a simple back-end server for an iPhone application that allows user registration, signup, and stores user profile information.
Or may include a package of goals, usually building on a previous iteration:
- Add a simple Software-as-a-Service payment processing system to user registration.
Most businesses looking for development really don’t care about the hourly rates when it really boils down to work (i.e., $20/hr for 5 hours of development for one developer or team == $100/hr for 1 hour of development for another developer or team). They really just want their product or service to work, and they would really like to know how much it will cost and how long it will take.
“you can build software 1) on time, 2) on budget, and 3) on scope, but you can only pick two….”
This is not to say that no developer team could never do all three, but it’s actually a lot more manageable (and fun) for businesses and developers to fix “time” and “budget”, and alter the scope in Iteration based development.
You might be thinking that we’re still back in Square 1 – i.e. aren’t those pesky developers just packaging up a set of hours and time – how will I know what will get developed in that time and for that cost? But, something very cool happens when you really embrace those constraints.
With an iteration, both parties are agreeing to a fixed amount of money and time, and the developers (and product owners) will develop as much functionality and business value within the Iteration. If development on an Iteration begins, and then the business owners suddenly have a fantastic new idea (which usually happens right after the first demo, once they have working software in their hands), they can simply ask the developers to make it happen. Similarly, if the developers think of a great way to simplify a process, leverage an existing plugin or library, or add (or remove) an additional feature, they can propose it without recourse. Both parties know how it affects the Iteration, and thus, the bottom line. There is no concept of the “change-order” and the rapid-feedback-loop created from iterating makes sure that what is being developed by the developers is exactly what the business owners want.
At Highgroove, we have a Master Services Agreement for Iteration Based Contracts, and without posting all the nitty gritty details, the meat of it revolves around the compensation and deliverables:
Deliverables are always outlined as attachments to the agreement, and are usually story-based (see BDD).
Iteration Based Contracts require quite a few more mechanisms to ensure that developers are not just packaging up X number of hours – there has to be agreed upon functionality and time-frames surrounding those deliverables within the Iteration(s).
We’ve found that our best clients are really seeking a proven process, and a team that can execute on that process: being transparent and delivering real business value at every step. Iteration Based Contracts are a great way to structure this relationship.