What Does "Commitment" Look Like with Agile Projects?

Question

When engaging with a client on a project that will be developed using agile methodologies, what is being promised in the delivery of the project? How do you know if that promise is objectively met?

Context:

In a typical client/service-provider interaction, a transaction takes place where the client asks, "can I have a solution that helps me do X?" Then, the provider responds with, "yes, we can build that for you!" The next thing the client says is, "awesome, how much will it cost and when will I have it?" Finally, the provider gives an answer, or a promise, to deliver.

In the traditional waterfall-managed project, as the provider, we can easily see if we've met our promise by comparing our "committed" timeline, budget, and scope to the actual timeline, budget, and scope.

In the agile world, where there is inherent recognition that the plan of what is going to be delivered changes, what are we actually promising when the project starts? Can it be measured?

Waterfall: "I promise to deliver X scope in Y timeline with Z budget." (In the hopes of solving W business need.)

Agile: ?

If I were to take a stab at it, I'd probably say:

"I promise to help solve W business need by iteratively developing and adapting X scope within the confines of Y timeline and Z budget."

The problem with this answer is I'm having trouble understanding how I can objectively measure whether or not this promise is met. How can I reasonably compare committed vs. actual Y timeline and Z budget if I know that X scope will change. How can I measure whether or not X' scope actually solved W business need?

Answer 1

What You're Offering

This is a good question, because it highlights a common misunderstanding of agile principles and contracting. In practice, you aren't promising to deliver something with a fixed scope, budget, or timeline. What you're offering to do is to collaborate with the customer in iterative increments, and using framework features to manage scope to fit the budget or schedule on an ongoing basis.

Using Scrum as an example, a typical agile approach is to say something along the lines of:

1. Each team costs n dollars per Sprint. (You don't have to do this, but I find it adds predictability and averages out for all involved.)
2. We will collaborate with you to deliver a potentially-shippable increment at the end of each Sprint.
3. You can adjust the project's priorities at each Sprint boundary.
4. You can terminate the project at the end of any Sprint where you've achieved enough value or decide that the project won't meet your expectations.

The rest is contractual fine-tuning. The point is that you are working together with the customer to build a product, rather than creating an externality for them. The agile framework that you choose provides some rigor and visibility, but is almost never bounded by fixed scope.