|
|
|
|
|
|
by dragonwriter
2158 days ago
|
|
|
> A good agile process can and should have all of the things the parent commenter listed. A good agile process will not have an ironclad upfront definition of what is to be delivered in a large project. A process with that may not be waterfall, but it's definitely non-Agile Big Upfront Design. OTOH, Agile is largely about managing risk and incrementally delivering value without overcommitting forward, so the contracting process with Agile should reflect that and shouldn't commit to a giant project in a lump contract. |
|
|
"what is to be delivered" does not have to be a rigid definition of "5,000 lines of code program with features 1, 2, and 3". A good agile contract will allow the possibility for changing project requirements but also still define how those changing requirements affect expectations and responsibilities of the consulting company.
The agile process itself can actually be a deliverable that you define in a contract, and it should spell out, for example, how new requirements are prioritized and the criteria you use for determining if it's something that the consulting company is responsible for. In my experience if you can't write out your agile requirements in a contract, then you don't have a good enough internal understanding of your own agile processes and should probably work on that, too.
Far too many people use "we're Agile" as an excuse for "we don't plan or document anything" and extend that to contracts, but that's absolutely not what good Agile actually is.