Hacker News new | ask | show | jobs
by myalphabet 2157 days ago
Nobody said anything about waterfall. A good agile process can and should have all of the things the parent commenter listed. If you eschew those things by using the "well we're agile, that means we don't plan ahead!" excuse, that's a sign of incompetence.
2 comments
dragonwriter 2157 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.

link
myalphabet 2157 days ago
>A good agile process will not have an ironclad upfront definition of what is to be delivered in a large project.

"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.

link
Shorel 2157 days ago
It's implicit. Not only software needs iteration.

Design documents also need iteration, because there's always something that was overlook, something that just escaped common sense, and so on.

In other words: Code can have bugs. Design documents also can have bugs, and the latter are almost never fixed.

Why is that? Because fixing a design document involves negotiations and changing budgets.

link