I do agree with what you are saying.
"The team should do all it can to realize product owners vision and the first step towards the same could be to ask her to articulate the vision clearly enough and bring her to address issues from technical architecture perspective which would enable realization of these issues. If she is still not listening enough, too bad."
However, as a product owner I would possibly not work with a team who would not question my vision, priorities and help me articulate them better. I am not asking them to do my job, just help me do my job better and my job really is not just to chalk out this great vision but also explain this vision to the team so that they can realize this. Otherwise, how different is it from just having a vision myself, dividing it down into tasks and asking the team to just come up with it?
I think we have digressed enough from the thread. Original question was "How to measure success on an agile project". I suggested to give up the idea and if at all this is to be done then just do a simple poll and ask people involved on how successful they think the project was. Also, I have been trying to make a subtle difference between project's and product's success.
To illustrate, let me explain this: my project could really be to make this 1000 storey building which I hope to sell to United Nations - the team organizes itself beautifully and they help me realize my vision in time - but United Nations does not buy the same and I don't want to sell to anyone else. Is the project a success - I would say yes. Is the end product successful? I would say no. Who is at fault here? Product Owner most certainly.
The original question asked how to measure "the success of the project". Is it by simple equating to "end products success"? Is the fact that did we really gel together as a team or really do Scrum to meet that end not important?
Thanks
Mike Dwyer <mike.dwyer1@...> wrote:
Think carefully about the impact of making the team responsible for anything other than what they are asked to – and agree to – do. They can anything beyond that is out of their control. However the tools they have to monitor and control what is theirs to do are more than the sprint reviews. First and foremost there are the retrospectives. Here the team measures itself against what it holds as their own goals and experience in translating the Product Owner’s priorities into useable functionality that the Product Owner can accept. The team also creates a metric as to the consistency of the Product Owner’s growth of the product. Here the team can evaluate their ability to incrementally improve their grasp of what the Product Owner is trying to create. If the team cannot see improvements in the clarity and direction of the Product Owner’s vision, there will be conflicts and disconnects in how the functionality is developed. This is an impediment of the first magnitude.The team also has the Sprint Planning session to negotiate the stories and tasks they commit to for the next sprint. If the PO priorities shift in a consistent manner and a clearer picture is created about the emerging product then the team can improve its focus. If the PO priorities shift erratically, leaving some functionality incomplete or undone in the team’s opinion then this is an impediment that needs to be discussed.Finally the team has the daily scrum meeting where each member can report on how well they are doing in developing the functionality. Again if there is inconsistency between what has been done and what they are doing it too is an impediment that needs clarification.Michael F. Dwyer"Planning constantly peers into the future for indications as to where a solution may emerge.""A Plan is a complex situation, adapting to an emerging solution."-----Original Message-----
From: scrumdevelopment@yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Vikrama Dhiman
Sent: Friday, December 21, 2007 11:28 AM
To: scrumdevelopment@yahoogroups. com
Subject: RE: [scrumdevelopment] Re: How to measure success on agile projects from customer point of view>>So what is a project to do. First, understand that the success of the effort is beyond the team to accomplish. It is too far away from the decision point to have anything impact on it other than influence and advice. This is why Scrum insists that the PO be the one to make the decisions about what priorities are and they control and report on the budget.Thats beautifully put up but I would rephrase this "success of the effort is beyond the team to accomplish" with "success of the effort is beyond the team alone to accomplish". Rest I agree with completely. Its almost what I was saying earlier : "the project success" has just too many factors for team to get involved in for measuring. If they want to track how well they realized product owners vision - all they need to do is go to sprint reviews.
Mike Dwyer <mike.dwyer1@comcast.net> wrote:You are asking me the same question that a surgeon asks. Am I doing a good job if I follow all the steps and if the patient gets well or if they die is not my concern? My response is what is the goal here? A well patient or a successful procedure? How do you know? The answer is a multi-layer multiple tier issue that is sure to offend, alienate, and in general lead to distrust, cynicism, and general malaise as the moral, ethical, professional, humanistic, and legal concerns clash. Rather than wander into that valley of doom I’ll just cut to the chase and offend everyone. If the customer accepts the outcome and their check cashes, then the work was successful enough to be accepted. If the work was immoral, illegal, unethical, or repulsive then someone should have thought that through before accepting the job, doing the job, or delivering the job. That is an entirely different subject and needs to be treated as an ethics and moral discussion.At one time PMI was attributed with the statement that a project was a success when it was on time, on budget, and met all the specifications. Now I think this is an urban legend to working project managers as the only success is when the PO or the customer acceptance of the product defines it as success. But even that is a weak answer. Take the “BIG DIG” in Boston. Was it a ‘success’. Well it did put one of the busiest interstates in the nation under the city of Boston, Overall the traffic flow has greatly improved, no buildings collapsed during the construction, and overall the users of the largest construction project in the country are more than satisfied. Except, the people who were crushed by the ceiling unit falling on them, the taxpayers who watched the cost grow by orders of magnitude (well almost) and ongoing water leaks in parts of the tunnel. All of that is fodder for the ‘success’ conversation. So much for the term success.Did the City of Boston, the Department of Transportation, and the various agencies monitoring this agree to the acceptance and opening of the roadway? Yes. Do people use it? Yes. Were the traffic and the pollution, and the noise goals measurably attained? Yes. Were the bills paid? Yes. From these measurable points I can state that the project was deemed acceptable and therefore am able to assume that it was successful enough to accept.So what is a project to do. First, understand that the success of the effort is beyond the team to accomplish. It is too far away from the decision point to have anything impact on it other than influence and advice. This is why Scrum insists that the PO be the one to make the decisions about what priorities are and they control and report on the budget.Michael F. Dwyer"Planning constantly peers into the future for indications as to where a solution may emerge.""A Plan is a complex situation, adapting to an emerging solution."-----Original Message-----
From: scrumdevelopment@yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Vikrama Dhiman
Sent: Friday, December 21, 2007 7:19 AM
To: scrumdevelopment@yahoogroups. com
Subject: RE: [scrumdevelopment] Re: How to measure success on agile projects from customer point of viewMike;
Would you agree that "PROJECT SUCCESS" rather than "PRODUCT SUCCESS" comprises of both:· Product owner defined "success criteria"· Team self evaluating itselfThe above is probably not the most important question that comes out of recent posts. What that is - "if a product owner defines the products success criteria badly, team does all it can to realize this bad vision - and product eventually does fail - product owner's neck is on the line obviously. The product obviously failed but did the project succeed? I would say no." Thats what is going on in my mind. If at all you are looking at project success, just one paradigm of a product owner defined success it too restrictive [ideal obviously is to focus on product success but not project success].
Thanks
Mike Dwyer <mike.dwyer1@comcast.net> wrote:I think I am reading three different conversations in this. One conversation is about Product Owners, a second is about a team self evaluating their progress, and the third is measuring ‘success’ from the customer’s point of view.The measure of success from the customer’s point of view is filtered by how your company values the relationship with the customer. The type of customer measure for success I think you are talking about is capable only over time. What do I mean by this? Suppose your company defines success as the customer buying the product. Ka-Ching, success is not measured by the customer but by cashing their check. Suppose your company measures success by the support contracts it sells to the customer. Ka-Ching success is measured by the ability of the company to inspect and adapt the product to overcome the limitations the customer finds when using the product. Alternatively if your company measures success by the increase of business with customers and the increased use of the product in the marketplace and demonstrates this with collaborative activities with the customer’s and the market. Now you are at a point where the customer, the company you work for and your team are all on the same side.What does that mean about Product Owner’s? the Check cashing product owner is going to want flash and sizzle. The support Product Owner is going to want knee jerk response to customer issues. The increase business Product Owner is what we all hope for.It’s a fact that the quality of product owners have the same distribution as the quality of team members. Poorly performing product owners are impediments to meeting the criteria of success from the customer’s point of view. As such their lack of input needs to be moved up the organization. Sorry about that ScrumMaster, that is your job – removing impediments – how you do it is a measure of how good a ScrumMaster you are.About the team self-evaluating their progress; I am confused here, but what do you do in your retrospectives? If you are saying that the team should be able to say they are 24.7% complete, then I have to ask what difference is there between this and the stop light mentality that is employed. IMO, the difference is that we are looking for measurable and verifiable metrics. That is why DONE as in accepted by the PO or the customer is the only independently verifiable measure. Imbedded are all the children DONEs that need to be completed in order to have the customer and the PO accept the delivery. Why? Each tier of DONE needs to be paid for and thus needs to show some value add to the customer. The Product Owner has the budget and makes that call.In closing, Scrum works in all types of companies. The question you have to ask is which ones can you work in.Michael F. Dwyer"Planning constantly peers into the future for indications as to where a solution may emerge.""A Plan is a complex situation, adapting to an emerging solution."-----Original Message-----
From: scrumdevelopment@yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of Vikrama Dhiman
Sent: Friday, December 21, 2007 4:36 AM
To: scrumdevelopment@yahoogroups. com
Subject: Re: [scrumdevelopment] Re: How to measure success on agile projects from customer point of viewI still think that even with "a brilliant product owner" - its still going to be better if we can poll the whole team on how they are doing. Maybe this can be converted a bit into something which can be used in retrospectives every now and then. Someone can raise their hand and say - "I would like to know how everyone else feels about the project." The only problem with that is the product owner wont be present. Maybe shift it to sprint review. Number of options.
What I think our team would do is that [if at all it does that], success won't be measured just from customers or product owners point of view for "a project". Yes, the "products/ final deliverables success" could be measured from customer/ product owners perspective but the overall project's [which actually made the product] success would ideally be measured from all the team members perspective? A better goal would probably be keeping everybody aligned towards common goals [most of these would probably be product oriented, but some team oriented as well].
Joseph Little <jhlittle@mindspring.com> wrote:Vik,
This is an involved topic. I think there are few truly wrong answers.
But to be more direct...
I think I agree with you. I think you are saying that some Product
Owners can be very weak. Agreed. And to that issue, my suggestion of
"go and talk to the Product Owner" is not a useful solution. Go and
get a good Product Owner might be.
I like your proposal of polling the team. More and more I find "the
wisdom of teams" book was right. That the whole team will find the
truth (if one allows them). Still possible for a given team to
collude to avoid the truth, but less likely.
If by "ask the customer" you mean ask the end-customers of your
product, I can see no better way to understand success. To me, that's
what businesses do...satisfy their customers within the constraints of
satisfying their other stakeholders (eg, shareholders). If the firm
don't satisfy customers, why does the firm exist?
In most business situations, I find we must put the locus of
decision-making about business value in one person (perhaps advised by
one or more people). Typically that person would be the Product Owner
on a Scrum team (at least tactically), but there are other possible
solutions.
Let me explain why I answered that way in my earlier post. I find too
many people who want to "measure something" to determine success. I
too often find this unhelpful. Conversations are usually more
productive that collecting a bunch of numbers. So my answer was an
indirect way of saying: Go and have the conversation. Now. Don't
avoid the conversation (which, as Mike Vizdos pointed out, many of us
secretly want to do.)
Are all numbers terrible? Of course not. But one must use a great
deal of judgment. One usually gets what one measures, so measure the
(very few) right things.
Regards, Joe
--- In scrumdevelopment@yahoogroups. , Vikrama Dhimancom
<vickydhiman@...> wrote:
>
> The obvious and wrong answers is "just ask the customer".
>
> I know of projects that were 2 months late [and still useful to the
customer as he had kept a buffer from his side while planning the
release]. However, we never got paid for additional 2 months. Customer
was happy - infact thrilled, this team was only 2 months late while
earlier one was about 7 months late.
>
> Is that project a success? Not really!
>
> A simple method that can be used [I haven't tried it but only
thought about it] - everyone involved in the project gives it a
composite rating on a scale of 1-5 [or whatever]. Its no use having a
successful project with team attrition during and after being 50% or
having zero attrition and 10 month late deliveries. You can compile
the score at the end. Anything less than 3, should get you going in
more depths. I have not been able to come up with something more
simple but making it more complex is entirely possible.
>
> - Vik
>
> Matt <maswaffer@...> wrote:
> --- In scrumdevelopment@yahoogroups. , "Joseph Little" <jhlittle@>com
> wrote:
> > "Go ask the customer" is consistent with the Lean idea of Genichi
> > Genbutsu (if I spelled it right). AKA "go and see for yourself" or
> > "don't manage from behind the desk".
>
> I think the original poster was trying to find a good way to ask the
> customern... the title of the post contains "from the customer point of
> view". Usually developers try to measure success from our point of
view
> but I think the OP really was trying to "go see for themself".
>
> > At the end of the day, are the customers satisfied (more satisfied)?
> > (Usually it's a customer set you are helping. Not one person.)
>
> And at the end of the day, depending on what kind of customer set you
> have, an unsatisfied customer may not show up in your result set
because
> they may no longer be your customer.
>
> > Are the shareholders (stakeholders) in your firm considered
> > "customers"? Should they be? Do they care about or are they
> > significantly impacted by the success of the effort?
>
> Excellent point... I usually think of "measuring success" in the
context
> of a PO or someone else within the firm but they are simply one set of
> "customers" that are measuring success. Interesting point of view.
>
> Matt
>
>
>
>
>
>
> --------------------- --------- ---
> Looking for last minute shopping deals? Find them fast with Yahoo!
Search.
>
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Offline 
Send Email