Mixing
What Does “Commitment†Look Like with Agile Projects?
Clash Royale CLAN TAG#URR8PPP
up vote
5
down vote
favorite
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?
agile metrics
asked Aug 27 at 19:34
Mackers
1284
add a comment |Â
up vote
5
down vote
favorite
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?
agile metrics
asked Aug 27 at 19:34
Mackers
1284
add a comment |Â
up vote
5
down vote
favorite
up vote
5
down vote
favorite
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?
agile metrics
asked Aug 27 at 19:34
Mackers
1284
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?
agile metrics
asked Aug 27 at 19:34
Mackers
1284
asked Aug 27 at 19:34
Mackers
1284
asked Aug 27 at 19:34
Mackers
1284
asked Aug 27 at 19:34
Mackers
1284
1284
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
7
down vote
accepted
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:
- 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.)
- We will collaborate with you to deliver a potentially-shippable increment at the end of each Sprint.
- You can adjust the project's priorities at each Sprint boundary.
- 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.
answered Aug 27 at 20:13
Todd A. Jacobs♦
30.4k329107
Thank you for the insightful answer. Do you have techniques for measuring a project's performance on collaboration? If the promise is to collaborate, how do you know you're doing a good job at it? It'd be great if there was Collaboration Index formula that you could measure :). I suppose the measure would be more subjective rather than objective. Would it just be results of customer surveys?
– Mackers
Aug 28 at 14:56
@Mackers You're collaborating, which means you should be in routine contact with them. If you're talking to them directly, why not just ask them directly? There's no substitute for direct interpersonal communications for measuring collaboration.
– Todd A. Jacobs♦
Aug 28 at 15:00
100% agree with that on the team level. The audience of this performance information would be different than the people that are in the weeds on the project. Let's say you have 100+ scrum teams, all working on their promises to collaborate with their respective clients, and you need to know at the macro level, in general, how well your teams are functioning.
– Mackers
Aug 28 at 15:13
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
7
down vote
accepted
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:
- 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.)
- We will collaborate with you to deliver a potentially-shippable increment at the end of each Sprint.
- You can adjust the project's priorities at each Sprint boundary.
- 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.
answered Aug 27 at 20:13
Todd A. Jacobs♦
30.4k329107
Thank you for the insightful answer. Do you have techniques for measuring a project's performance on collaboration? If the promise is to collaborate, how do you know you're doing a good job at it? It'd be great if there was Collaboration Index formula that you could measure :). I suppose the measure would be more subjective rather than objective. Would it just be results of customer surveys?
– Mackers
Aug 28 at 14:56
@Mackers You're collaborating, which means you should be in routine contact with them. If you're talking to them directly, why not just ask them directly? There's no substitute for direct interpersonal communications for measuring collaboration.
– Todd A. Jacobs♦
Aug 28 at 15:00
100% agree with that on the team level. The audience of this performance information would be different than the people that are in the weeds on the project. Let's say you have 100+ scrum teams, all working on their promises to collaborate with their respective clients, and you need to know at the macro level, in general, how well your teams are functioning.
– Mackers
Aug 28 at 15:13
add a comment |Â
up vote
7
down vote
accepted
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:
- 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.)
- We will collaborate with you to deliver a potentially-shippable increment at the end of each Sprint.
- You can adjust the project's priorities at each Sprint boundary.
- 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.
answered Aug 27 at 20:13
Todd A. Jacobs♦
30.4k329107
Thank you for the insightful answer. Do you have techniques for measuring a project's performance on collaboration? If the promise is to collaborate, how do you know you're doing a good job at it? It'd be great if there was Collaboration Index formula that you could measure :). I suppose the measure would be more subjective rather than objective. Would it just be results of customer surveys?
– Mackers
Aug 28 at 14:56
@Mackers You're collaborating, which means you should be in routine contact with them. If you're talking to them directly, why not just ask them directly? There's no substitute for direct interpersonal communications for measuring collaboration.
– Todd A. Jacobs♦
Aug 28 at 15:00
100% agree with that on the team level. The audience of this performance information would be different than the people that are in the weeds on the project. Let's say you have 100+ scrum teams, all working on their promises to collaborate with their respective clients, and you need to know at the macro level, in general, how well your teams are functioning.
– Mackers
Aug 28 at 15:13
add a comment |Â
up vote
7
down vote
accepted
up vote
7
down vote
accepted
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:
- 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.)
- We will collaborate with you to deliver a potentially-shippable increment at the end of each Sprint.
- You can adjust the project's priorities at each Sprint boundary.
- 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.
answered Aug 27 at 20:13
Todd A. Jacobs♦
30.4k329107
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:
- 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.)
- We will collaborate with you to deliver a potentially-shippable increment at the end of each Sprint.
- You can adjust the project's priorities at each Sprint boundary.
- 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.
answered Aug 27 at 20:13
Todd A. Jacobs♦
30.4k329107
answered Aug 27 at 20:13
Todd A. Jacobs♦
30.4k329107
answered Aug 27 at 20:13
Todd A. Jacobs♦
30.4k329107
answered Aug 27 at 20:13
Todd A. Jacobs♦
30.4k329107
30.4k329107
Thank you for the insightful answer. Do you have techniques for measuring a project's performance on collaboration? If the promise is to collaborate, how do you know you're doing a good job at it? It'd be great if there was Collaboration Index formula that you could measure :). I suppose the measure would be more subjective rather than objective. Would it just be results of customer surveys?
– Mackers
Aug 28 at 14:56
@Mackers You're collaborating, which means you should be in routine contact with them. If you're talking to them directly, why not just ask them directly? There's no substitute for direct interpersonal communications for measuring collaboration.
– Todd A. Jacobs♦
Aug 28 at 15:00
100% agree with that on the team level. The audience of this performance information would be different than the people that are in the weeds on the project. Let's say you have 100+ scrum teams, all working on their promises to collaborate with their respective clients, and you need to know at the macro level, in general, how well your teams are functioning.
– Mackers
Aug 28 at 15:13
add a comment |Â
Thank you for the insightful answer. Do you have techniques for measuring a project's performance on collaboration? If the promise is to collaborate, how do you know you're doing a good job at it? It'd be great if there was Collaboration Index formula that you could measure :). I suppose the measure would be more subjective rather than objective. Would it just be results of customer surveys?
– Mackers
Aug 28 at 14:56
@Mackers You're collaborating, which means you should be in routine contact with them. If you're talking to them directly, why not just ask them directly? There's no substitute for direct interpersonal communications for measuring collaboration.
– Todd A. Jacobs♦
Aug 28 at 15:00
100% agree with that on the team level. The audience of this performance information would be different than the people that are in the weeds on the project. Let's say you have 100+ scrum teams, all working on their promises to collaborate with their respective clients, and you need to know at the macro level, in general, how well your teams are functioning.
– Mackers
Aug 28 at 15:13
Thank you for the insightful answer. Do you have techniques for measuring a project's performance on collaboration? If the promise is to collaborate, how do you know you're doing a good job at it? It'd be great if there was Collaboration Index formula that you could measure :). I suppose the measure would be more subjective rather than objective. Would it just be results of customer surveys?
– Mackers
Aug 28 at 14:56
Thank you for the insightful answer. Do you have techniques for measuring a project's performance on collaboration? If the promise is to collaborate, how do you know you're doing a good job at it? It'd be great if there was Collaboration Index formula that you could measure :). I suppose the measure would be more subjective rather than objective. Would it just be results of customer surveys?
– Mackers
Aug 28 at 14:56
@Mackers You're collaborating, which means you should be in routine contact with them. If you're talking to them directly, why not just ask them directly? There's no substitute for direct interpersonal communications for measuring collaboration.
– Todd A. Jacobs♦
Aug 28 at 15:00
@Mackers You're collaborating, which means you should be in routine contact with them. If you're talking to them directly, why not just ask them directly? There's no substitute for direct interpersonal communications for measuring collaboration.
– Todd A. Jacobs♦
Aug 28 at 15:00
100% agree with that on the team level. The audience of this performance information would be different than the people that are in the weeds on the project. Let's say you have 100+ scrum teams, all working on their promises to collaborate with their respective clients, and you need to know at the macro level, in general, how well your teams are functioning.
– Mackers
Aug 28 at 15:13
100% agree with that on the team level. The audience of this performance information would be different than the people that are in the weeds on the project. Let's say you have 100+ scrum teams, all working on their promises to collaborate with their respective clients, and you need to know at the macro level, in general, how well your teams are functioning.
– Mackers
Aug 28 at 15:13
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f24788%2fwhat-does-commitment-look-like-with-agile-projects%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
