Delivery versus Compliance in Agile Project Management (APM)

[Darya Akbari]

Hi,

APM is first and foremost about delivery as delivering results and delivering value to customers. On the other hand compliance as it seems to me is more a secondary goal.

Shouldn't it be the opposite? I mean, compliance is what the contract says. Not fulfilling the contract can end up paying a high price .

What do you think about it

Regards,
Darya

[Ilja Preuss]

The third line of the Agile Manifest <http://agilemanifesto.org/>; is

"Customer collaboration over contract negotiation"

And the first two principles:

"Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."

The reasoning is that delivering high value software early and often is what will make the customer happy, not compliance with the contract.

Imagine these two scenarios:

a) A more than happy customer, which got delivered exactly the system that he needs, although it wasn't defined that way in the contract.

b) A system that complies to the contract, but doesn't solve the customers problem -> customer unhappy.

Which situation would you rather be in?

[Darya Akbari]

Well, the contract is the thing that only counts when you are in court . Whether the customer is happy with what you deliver doesn't count anymore when you are at court over a dispute of some tiny thing.

How should the contract look like in an Agile manner?

Regards,
Darya

[Ilja Preuss]

Originally posted by Darya Akbari:
Well, the contract is the thing that only counts when you are in court . Whether the customer is happy with what you deliver doesn't count anymore when you are at court over a dispute of some tiny thing.

The goal is to not get in court at all. Whether you win or loose in the court, you already lost: you lost the follow up orders of that customer, you lost reputation, and you lost a lot of energy that didn't went into building something valuable.

How should the contract look like in an Agile manner?

You *can* do Agile projects with fixed price contracts, although it's certainly not ideal.

A good alternative are optional scope contracts: http://www.xprogramming.com/ftp/Optional+scope+contracts.pdf

I also remember a style that I think I've heard from Robert C. Martin: Basically, it was a Time and Material contract with a rather low rate, just so that the running expenses are covered, and big bonuses when certain functional milestones are reached.

[Darya Akbari]

Thanks for the link Ilja.

[Peer Reynders]

You *can* do Agile projects with fixed price contracts, although it's certainly not ideal.

There is an article in Managing Agile Projects (amazon US) by Pascal Van Cauwenberghe Succeeding with Agile Fixed Price Contracts. He emphasizes that is it necessary to keep projects small (i.e. go for multiple small projects rather than one big one) and that there should be a period of time between each small project where the customer uses the software and finds out what features will actually add the most business value on the next small project. While this flies in the face of what sales wants to do (get that big contract), small contracts actually minimize the risk for both the customer and the vendor as their scope is usually easier and more reliably estimated. The customer gets some working functionality earlier and gets to explore what is really necessarily for the next step. As long as this keeps the customer happy, this usually leads to more work for the vendor due to repeat business.
He further emphasizes that you should not allow the usual traditional "change requests". You should deal with changing requirements through "exchange request" (swapping with features of equivalent effort) - that way you alleviate the usual cost and deadline pressures that are often responsible for a strained customer/vendor relationship (the displaced feature can always be added in the next project).
However he also has some fairly strict prerequisites before he enters into a fixed price contract:

Know the domain of the application.

Know the technology (i.e. nothing new or "cutting edge". Stick with tried an true technologies)

Know the team (communication capability, velocity, talent, experience, etc.)

Previous experience with a project of similar size.

One of the problems with the CMM process procedures is that an awful lot of effort is consumed by compliance tracking and checking - this is effort that does not provide any direct value to the customer by building working software. It introduces expensive friction into the project that is supposed to act like insurance when in fact it cannot guarantee the success of the project at all. And a compliant product doesn't guarantee a happy customer. A "first" project�s true value is in the opportunity to build a trust relationship that will lead to repeat business and ultimately to an environment where 'fixed price' is no longer necessary (of course there are some 'customers' you simply cannot (and don�t want to) do business with).

See also:
AmbySoft: Agile Project Planning Tips
Agile Modeling: Agile Requirements Change Management
[ April 22, 2007: Message edited by: Peer Reynders ]