14

I recently had a conversation with a fellow developer about Agile Software Development. While I understand the principle, it seems that continuously changing requirements creates the potential for the project to go on forever. But, at least where I work, projects need to reach completion because it's a contract.

That is, the first iteration could take months, because for some projects the customer cannot use an incomplete application. For some projects, I think you need to define finished first, then you can break it into iterations and refine your definition after each iteration. But you must always have this definition.

If Agile Software Development embraces changing requirements how do you know where it ends? How can you budget for a project when the end result is always changing?

Is Agile Software Development more about an agile process, than an agile product?

Verax
  • 240
  • 1
  • 7

7 Answers7

20

If you're focusing on doing (what you believe is) the most important stuff first, then the project will finish when:

  • You've spent the money you budgeted.
  • You've elapsed the time you budgeted.
  • You no longer want to add or change anything.
  • The next batch of your highest priority changes aren't worth what they will cost.
Dale Emery
  • 330
14

You stop when the business decides they do not wish to do any more iterations. You would hope that this is after a significant amount of value has been delivered but before you get too far into the realm of diminishing returns.

It should always be driven by "the business" whatever that means in your circumstance. It could be the senior management of a software development shop or the actual business sponsors in an in-house development environment. They will decide when the cost of the next iteration outweighs the benefit of the features that will be deliverable in the next iteration.

mcottle
  • 6,152
  • 2
  • 26
  • 27
7

From the OP's Comments is seems that he like me works for a Consulting shop, where we provide development services for our clients... I think because on this mind-frame that is causing his/her confusion... So I am going to state a well know but never stated fact.

Agile is incompatible with software development that is defined by a contract.

  • Contracts need to be Hard, You pay X we do Y. You want X+M you pay us Y+(M*N)
  • Contracts MUST be satisfiable , (IE not open ended ) otherwise they are not legal contacts. (When a contact is involved you must go though a strict change control process.)

Many Consulting shops claim to Agile, they are lying. They just say that because Agile has attained Buzz word status.

Agile works best for internal development where programmers are full time, and there is little talk of budgets. Just Time Frames and Features.

Morons
  • 14,706
5

Never, and that's the beauty of it.

The project is never finished. You reached another release, another milestone, but as long as the money is flowing, there's always one more feature to add, one more piece to make better, one more bug to fix. The project will die when it's no longer needed, but it will never get finished. As opposed to Waterfall model with requirement->project->product->end, this is a loop that can spin forever - as long as you're getting paid.

Not a frequently mentioned business feature of this technology, is it?

SF.
  • 5,236
4

There is a misconception here: Agile does not encourage the project's requirements to change. It instead allows for change without wasting work, or sacrificing important areas of development.

There are four fundamental constraints to any engineering project; scope, cost, time and quality. Waterfall assumes that these will be static. That is an incorrect assumption; one or more of these ALWAYS change. Scope creep, slashed budgets, and other "unknown unknowns" ALWAYS interfere with a project, changing the constraints. Waterfall does not anticipate this, so when it happens, the project changes in undesirable ways; important features that haven't yet been added go away, or are quickly done, or the release has to be pushed back, or cost balloons as the PM throws money at new developers to come in and help get it all done right.

Agile, by contrast, allows constraints to change, and actually expects it. It does this by doing work in small, useable chunks, according to the priorities of the owner, and thus the chunks are ideally immediately useful to the project owner. Thus reduces exposure to the unknown by not making big plans out in a timeframe where the unknowns are large. If the timeline changes, teams can be added, or less important features "de-scoped", and the system the team has already built is unaffected.

It also provides for better estimates of the time and cost required to produce the given scope at the required quality. People are notoriously bad at estimating big jobs; it takes a LOT of experience, and a LOT more upfront calculation, to do it properly. By contrast, people are generally good judges of what they can get done in a day, or a week or two. That quickly produces a steady-state where you can extrapolate the time and cost of the work left to be done based on your historic pace, with a fair amount of accuracy.

As for defining endpoints, you're right; an Agile project CAN go on forever. However, so can the traditional SLDC; the client often comes back with more money and a wishlist of upgrades. The difference is that there isn't a clear line between "analysis", "design", "development" and "maintenance" when looking at the project as a whole; it all happens brick-by-brick, sprint by sprint. If at any point the owner wants to call the project "done", they can, and they will have the sum total of "bricks" they've paid for in a solid "wall"; it may not be as high or extend as far as they originally planned, but it's firmly in place, does the job, and can be added to at a later date with a minimum of tearing down.

KeithS
  • 22,282
1

It ends once all the features are implemented and all the bugs are fixed.

If the deadline is fixed and the requirements are also fixed. Then this won't be a problem. But if the deadline is fixed, but the requirements are changing, then there is something that you should do in order to proceed the project successfully.

Fixed price part 1, what's so bad?

Fixed price part 2, Fix it with agile!

CharithJ
  • 111
1

The big assumption behind agile development is that requirements are always changing, no matter which methodology you use. Now, of course you could build a requirements document, build a plan to execute on it, and deliver at the end, and it may seem that your requirements didn't change. They may not have changed in your plan, but with market changes and your and your customer's better understanding of the product, requirements in terms of what the customer wants is going to change. Agile comes in and suggests a process that doesn't hide these these changes through a fixed schedule, but instead builds responding to inevitable changes into the process.

When you are done now shifts from finishing a fixed schedule to when you product is at a place where you can deliver enough business value where your customer can ship and market the software in its current state. Being done is tied much more to how much value you are delivering instead of how you adhered to a schedule.

Brian Geihsler
  • 346