Andre asked:

Part of agile is the idea of not complaining when the spec changes -just go ahead and make the change - even if it means rewriting a large part of the project because the software wasn't originally designed to accommodate the new requested functionality.

How do you deal with this in the real world?

In any environment where there are stakeholders, you must inform the stakeholders of their options and solicit their preference. This is true in Agile, this is also true in Classical project management. The only difference (which I will address) is your ability to handle the change.

Where Agile is beneficial is in reducing the cost so that the likelihood of "rewriting a large part of the project because the software wasn't originally designed to accommodate the new requested functionality" is lower.

How can this be so? How can Agile reduce (not eliminate) the cost?

One of the answers is by reducing Acceptance Debt.

At any one time in any project, the stakeholders will have a finite list of requirements. They will have tested the unfinished product against zero or more of those requirements. If they test, they will pronounce the product to have satisfied zero or more of the requirements.

This is acceptance testing. Code that does not contribute to satisfying one or more requirements accepted by the stakeholder is unaccepted code. Note that you must actually test, and the stakeholder must be satisfied. This eliminates "requirements drift," where you test against a stale requirements document. The stakeholder must validate the acceptance test.

During a development cycle ("iteration" in XP, "sprint" in Scrum, "release" in Classical), new code is unaccepted. You're building "Acceptance Debt" as you write every line. At the end of the iteration, you acceptance test. You eliminate the debt by proving that the code satisfies the stakeholders.

Why is it debt? Because you pay out resources and time to obtain code. You're "out of pocket" until the stakeholder accepts that the code satisfies their requirements.

Agile reduces Acceptance Debt in several ways. First, Agile has short iterations (2 weeks for XP, 30 days for Scrum). You have less unaccepted code at any one time. It's like being on a contract and negotiating progress payments: you have better cash flow and less risk.

Agile also eschews coding for requirements you cannot satisfy during an iteration. This doesn't mean don't think ahead and don't design, just don't write code you can't test.

Classical uses very long development cycles with little or no acceptance testing until the end of the project. Lots of unaccepted code (no, unit testing does not reduce Acceptance Debt). So Classical builds up huge acceptance debt.

So, how does lowering acceptance debt lower the cost of requirements changes?

Well, you can devise a scenario that is an exception to any generalization, but I will suggest to you that most requirements changes tend to keep substantially all of the existing requirements. One or two get lopped off and an entirely new set get added on that you didn't anticipate.

So what happens? Let's look at your acceptance debt. What happens when a requirement you haven't satisfied yet gets dropped? In the Agile world, you have no problem, because you didn't write any code to partially satisfy requirements.

This is different than the Classical World. Most Classical architects develop things in nice layers of abstractions with frameworks and delegates and tiers. So at any one time you have huge acceptance debt in the form of code that doesn't satisfy a requirement today but it might help satisfy one next month. Those architects have a problem when those unsatisfied requirements change.

So, I suggest the Agile project has less acceptance debt from unsatisfied requirements than the Classical project, because the Classical project hasn't satisfied as many requirements, and even the ones that have been satisfied haven't been accepted by the stakeholders.

Now what happens when a requirement you've already satisfied gets dropped? Some or all of the code supporting that requirement just became unaccepted, and you have instant Acceptance Debt. This is not so good. Is it the same for the Agile and Classical World?

No, it is not the same. In the Agile World the stakeholder has accepted the requirement. You didn't send her an email saying some task was done, you didn't show some demo that might have really been PowerPoint or Flash, you stress tested the Product Increment and gave it to them to use in a production setting. They know it was done.

In the Classical world they take your word for it that it was done, but the Product Increment isn't in production. How is this different? In theory it shouldn't be different, it shouldn't matter because they no longer need the software to satisfy the dropped requirement.

In practice, when the stakeholder has already accepted the product increment, they understand the wastage in a visceral sense. It's like buying a sedan, then taking it back to the dealer to ask them to cut the roof off and make it a convertible. If you already took the car for a drive, you appreciate the fact that metal must be cut and welded. But if the car hasn't been delivered yet, you just say "sorry, I changed my mind, change the car for me." The roof is the dealer's problem.

Anyways, the stakeholder is adamant, so you just piled up acceptance debt. So what? Okay, there's less debt for the Agile project. So what? In practice, this debt now weighs you down. It takes more time because you're rooting through the now unaccepted code trying to change it, without breaking anything that satisfied a requirement that hasn't changed.

Labels: agile