|
I am starting a company and am considering agile development, but I don't understand how a Fixed Price contract (the type I would like to use), could work. It seems like the point of Agile is to keep things versatile and always bubble important issues/requirements to the top. Can this work in the Fixed Price world? Are most Agile contracts just a deep bucket of money that can be dipped into until it runs out? How do you handle change management? Thanks. |
|||
|
|
|
Those things are completely unrelated. You seem to be entertaining either doing consulting/developing for others or hiring others to develop for you (it's unclear from the question). Agile is how you go about the development process. In case of hiring others, development process is not handled by you, so the question would make little sense, so I'll assume you're talking about providing development services for others. In that case the requirements are fixed and given by people who hire you. Fixed price vs. compensation per hour only determines how are you going to be paid for completing the contracted work. Which payment method you choose should depend on what you believe will make you more money. Fixed price is more risky (if you underestimate the number of hours needed, your per hour compensation will go down) but if you think you can complete a project quickly and ask a high fixed price for it, you might go for it. Agile is a development process i.e. ideas and practices for structuring your development work to achieve your end goal faster. Some of the principles of Agile do not apply to the world of short-term contract programming. In contract programming the requirements are specified upfront. You are being paid for implementing exactly what is specified, quickly. Parts of the Agile process involves management of requirements. In contract work requirements are usually given to you and you have no authority to change them so those parts of the Agile process are not applicable. Non-applicable, however, is not the same thing as contradictory. Agile consists of very rich set of practices. It's not meant to be applied verbatim and 100%. It's up to you to choose the practices that make sense in your particular situation, given your particular constraints. |
||||
|
|
|
we provide this option for our clients now. For clients asking for fixed price development we have our Blueprint Process which makes the client sign off the "goal" before we start. Changes to the goal are then handled as change requests to the original quote. This is exactly the same as an agile process but with a signature showing understanding at each step along the way. We still break the development it into sprints and provide a "deliverable" per sprint. They can still change their mind for subsequent sprints but they sign off a change request ... all it really does is help manage their expectations and create a higher workload for the project lead as they have to actually think ahead and plan out sprint deliverables properly. |
|||||
|
|
Very simple.Fixed price = fixed effort (i.e. X sprints). Features get prioritized. Anything that does not fit in the budget is cut. Voila - fixed price. |
|||||
|
|
I never saw it working like it is described in Agile books & articles. Very few customers will buy it. I personally never meet any that accepted to buy sprints instead of completed features. They simply don't see the value ... yet. Your customers are seeking for the security. They are taking the responsibility to select you, instead of the one that promised by contract that everything they asked will be done on time. With the second option, they choice is "safe". If they fail, they are somewhat protected by contract. If they fail with the first option (buying iterations), if they end with a non usable product, they are screwed. However, nothing prevent you from using Agile internally if the customer get what he ordered and you take the responsibility for it. |
|||
|
|
|
I read a lot of great stuff on VersionOne's website. They have a free trial too (or it might even be free for 1 project or something). www.versionone.com They have a tutorial section, and in about an hour you can have a pretty good working knowledge of the Agile process. I just read it a few days ago. |
|||
|
|
|
From the Agile Manifesto, the latter two priority points present specific challenges for fixed price contracts: "[We value] Customer collaboration over contract negotiation" This is either pretty straightforward, or else impossible, to reconcile. The principle is that the contract does the job of defining commercial terms. A 'classic' development contract that sets out waterfall-style milestones etc is obviously anti-agile. If the customer requires this non-collaborative approach, some agile ideas may help you in your internal processes, but don't kid yourself. However, the collaborative approach will often include helping the relevant manager to create a contract that will satisfy internal procurement processes based on price-for-scope, but create what should be more valuable to the manager, price-for-progress. You can fix the total contract price, or the price per month, or pretty much anything you like, and be fully agile. "[We value] Responding to change over following a plan" Agile doesn't say, "don't plan." It just says it's crazy to follow the plan blindly when the world changed. Again, traditional buying processes tend to look exactly the opposite of us. But this is an easier reconciliation. In some cases, especially smaller projects or ones driven by external factors such as compliance, there is no significant likelihood of change. In others, this is a minor contractual issue (what is the mechanism within the contract to allow for variation), but more importantly a relational one (how do we stay engaged with stakeholders so that situational change is discovered quickly and embraced organically. If you are truly embracing agile, and change arrives such that the project doesn't make sense, or can be reduced, or considered complete early - be ready to give the customer the gift of freedom to end up below the fixed price. |
|||
|
|
|
Agile does not imply you don't have a target of what to build nor a solid definition of what is in scope and out of scope. The beauty of Agile is that the sprints are short and compact. That allows you to define places where incremental change can be captured. My advice would be to get the best up front scope you can, have a solid change order process and make the sprints short so that you can limit any downside for scope creep. |
|||||||
|
