I had an interesting question posed on a forum I regularly monitor and respond; I thought it would be interesting to share the response here for the readers who sometimes do not see that I also write in other areas (smile). The entire thread can be found here.

=====

The thread began along the lines of, “How do you measure success from the Customer point of view.”

The first answer I gave did not go over well…

“How about asking the customer?”

A lot of people jumped in on this one. Many people came up with similar answers.

Then, I answered one of the replies along the lines of:

“>>I have a strong desire to make sure that whatever project I work on the customer defines success.

This is an interesting thought. Can you explain that with an example? Have you tried it before?”

This was my reply:

Hi,

Every once in a while I will throw out a statement like that just to see if people are reading my replies (smile).

Let me address your second question first, “Have you tried it before?”

Yes. I have. In fact, after doing this for a while now I will not go into a team or organization without that being defined up front and in clear English (or whatever the local language — as long as I understand it AND the customer understands it!). When I first started doing software development (even before “agile and Scrum”), I tended to not ask this question and just make a lot of assumptions about what the customer wanted. This usually got both me and the customer (if there was indeed a customer) feeling frustrated.

Example(s).

I have many, so here are a few that stick out in my mind (especially at close to three AM and I am up with insomnia)…

Example #1
—————-

The first one I just talked about on Friday with a colleague of mine where we worked on a project that is still talked about today as one of the “best” agile projects people have worked on at their organization. One of the reasons it was a success — from both the minds of the customer and the development team (which includes all the roles) was that we had an engaged Product Owner and we took the time at the beginning of each Sprint to define what “done” looked like for that individual Sprint.

Were we expected to deliver something into production each iteration (or Sprint)? No. Actually, our “first” definition of done could be considered pretty week from people “outside” the team; it was something like, “We will deliver a piece of working code.”

We did this the first Sprint. And wow. The customer was blown away. The development team got focused on delivering working software (instead of traditional waterfall artifacts — some of which have nothing to do with working code).

Did the definition of “done” evolve? Yes.

Example #2
—————–

I was asked to come into a uuber-architecture project that had been “drifting” for years. One of the reasons this was happening was there was a group (a large technical group, by the way) pushing through this large change throughout the enterprise. It seemed like everyone had a line item in their budgets to “donate” to this project (I am joking about the donation — it was a sunk cost almost every project was paying for). When I cam in, customer satisfaction was low.

I wondered why and started going out and asking the people that were paying for the projects. Ummm… I got some surprising answers. Many of them included, “Um, I am not going to use that thing” to, “Mike, it is something I inherited after the last round of reorganizations.” It was almost silly. It took me a while to find a “real” customer for this project. And oh, I found one, and asked them to be committed to the team. We (the team, the product owner, and me (playing the role of ScrumMaster on this team)) burned through three product owners in multiple iterations (or Sprints) to be able to get to the “right” one.

In the end, I think the project got killed. And, it was a good decision for the organization. Why?

And this is important to realize — if you are using Scrum and cannot identify an engaged Product Owner… do not do Scrum.

There. I said it (and have in the past).

If the customer (or Product Owner) cannot define success for the team (or to themselves)… do something different.

Hope these examples help!

More information about the topics above can be found at:

Transparency

http://www.implementingscrum.com/blog/2006/10/16/transparency-and-jessica-alba-a-scrum-connection/
http://www.implementingscrum.com/cartoons/cartoons_files/2006-11-30-Transparency.html

“Done”

http://www.implementingscrum.com/blog/2006/11/27/done-really/

Product Owner

http://www.implementingscrum.com/blog/2007/06/04/whos-your-product-owner/
http://www.implementingscrum.com/blog/2006/10/30/shock-treatment-for-your-product-owner/

Silver Bullet

http://www.implementingscrum.com/blog/2006/09/25/scrum-the-silver-bullet-not/

Thank you,

- Mike Vizdos
www.implementingscrum.com
www.michaelvizdos.com

Gotta run�.Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

Originally Published:
December 16, 2007

Posted in Done, Product Owner, Transparency — by mvizdos on 12/16/07 1 comment

The Blind Leading The Blind. The Debrief.

---

---

Welcome back to another day at www.implementingscrum.com.

Today, as promised, I will tell you about the debrief related to the exercise for the cartoon this week (see above and yesterday for the actual exercise and the day before for the setup of why we are doing this!).

Please read over the past two days so you get some decent context about what I am about to cover next. It is that important (smile).

After everyone is sitting down and breathing they may actually be looking at you like, “OK, Why the heck have we done this exercise?”

First question for you to think about, then I will go about explaining why we do what we do here.

So.

Why do you think this exercise is done.

Take a moment and think about that before continuing.

I will still be here!

OK. Now that you are back… let me go into how I debrief this exercise.

First, I ask people, “How did this exercise feel?”

Leave it open ended.

And.

Shut up and let someone talk.

They will. They always do. Really.

Depending on the answers, I then take them through a guided tour of the three parts, and then ask a lot of open ended questions about the purpose of each section.

One of the things I constantly work on as both a ScrumMaster and Certified Scrum Trainer is learning how to shut up and listen — and NOT answer the questions I ask. This is a constant struggle for me and something that was pointed while I was co-teaching a class about six months ago; since then I have made sure I am aware of when I do this.

Sorry for the small tangent but I think it is important for you, my reader, that this will be a constant struggle going forward (if it is not — let me know how you are handling it!).

So.

For the first section I ask the “managers” how it felt for them. And let them talk.

Then, I turn it around to the “workers” — and how it felt for them. And. Let them talk.

This starts some light bulbs going off in some of their heads. This is a good thing.

And I point out how few (mainly by asking again) how few people completed this exercise.

No matter where I do this in the world — and it is a lot of places — the results do not vary that much.

So. It is not just a “North American” or “European” or “Indian” or “Insert your country here” thing.

Cool to see in action.

Next, I ask people who “finished” the second part of the exercise.

Almost all do.

Why?

Because they were given instructions on what the end goal was, and they knew how to do it.

It is not rocket science.

And.

Think about how to apply this on your Scrum Team.

It is that easy.

The next section was introduced to me earlier this year and I have had mixed results with it — to my surprise (wow… even I can still get shocked at results LOL).

When I ask people to become “blind” (about a third of the people attending the workshop) and give them the exact same directions as part two of the exercise…. teams doing this do one of two things. They automatically help each other or they let the blind crash into things and other people.

Wow.

How true to life is this on your team today?

How can you change that going forward?

This part of the exercises is reflected upon pretty regularly throughout the remainder of the workshop. And as the days go on, people start to see what this means in their current environment.

Is this something that has opened your eyes?

Will anything change?

Who will initiate that change?

Gotta run!.Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

Originally Published:
December 12, 2007

Posted in Cartoons, Certification, Exercise Examples, ScrumMaster, Teams — by mvizdos on 12/12/07 (2) comments

Older Articles »