Re: [scrumdevelopment] How to measure success on agile projectsfrom customer point of view

Expand Messages

George Dinwiddie

... That s a good measure of Lean Waste. Are your customers aware that this is also measuring them? Off the top of my head, I see that this easily includes

Message 1 of 3
, Dec 17, 2007

0 Attachment

ANIKET MHALA wrote:

> Thanks everybody for your important suggestions and guidance. I found it
> very useful.
>
>
>
> However my customers want matrix which consists of parameters (may be
> more….) such as
>
> * Cycle Time (Total time to execute an E2E Delivery) – ( Measured
> from the customer’s point of view i.e. calendar days, not working
> days)

That's a good measure of Lean Waste. Are your customers aware that this
is also measuring them? Off the top of my head, I see that this easily
includes the quality and small size of the stories requested by the
Customer. It's not good, from a Lean point of view, to optimize one
part in isolation. It can be suboptimal to optimize software
development without optimizing the business processes around it.

> * % Right First Time (percentage of time E2E process/delivery cycle
> is completed correctly)

Here, again, the Customer is being measured with the development team.
How well do they provide feedback during the development cycle?

> * Cost Reduction

Cost reduction of what?

> * Productivity Improved

How are you measuring productivity? Business value per sprint?

> My customers are saying they liked what they saw. However they are
> basically looking for generic parameters (parameter list for agile
> projects – as a standard) which they need to consider measuring the
> success on agile projects after delivering it on production.

Do they have a firm idea of the business value of the delivered features?

> Can we have single definition of “done” (Development Team plus
> Customer) or two separate definition of “done” to measure success of
> project one from development team point of view and another from
> customer point of view?

You can do that if you want to have two different goals for the Customer
and the Development Team. I'm not sure why, as a business, you'd want
those goals misaligned.

> I think PO/customer/developer should not change their definition of
> success during the sprint so that there would not be any impact on
> sprint delivery. However during/after Sprint Retrospective they can
> change/alter it.

If your Customer is thoroughly engaged during the sprint, then I think
the Development Team will welcome feedback that fine-tunes the goal.
This is a subtle thing, however.

If the Customer holds himself separate from the Development Team and
jerks the goal around to prevent the Development Team from achieving
success, then they're not only being unfair to the Dev Team, but
counterproductive for the business.

If the Customer wants to measure the success of the Development Team in
isolation, ignoring the contributions of the Customer, then I think
you've got a similar problem. The Customer and the Dev Team, together,
form the Whole Team that's developing new business processes. That
Whole Team is what should be measured and improved.