|
|
Hi all.
Well I have done quite a bit of traveling around this great planet of ours, and a lot of time spent in the clouds (thinking of course while I fly to destinations afar).
So, tomorrow you are going to see something that I did not think I’d ever see.
We’ll start with the cartoon and try to turn a story around it related to Scrum — something you all know I am good at doing.
And the next night I will send you the inspiration for the cartoon this week.
Wow.
Inspirational?
I hope so LOL.
Thank you,
- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com
Hi all.
Today I’d like to issue you a challenge and follow-through tasks.
The “winners” get bragging rights.
Huh?
OK.
As you may (or may not know) there are a few regular characters in our comic strips. Each of the characters can be found by, “Meeting the Cast.”
Here is what I’d like you to do for me today — if not sooner.
Please.
Head on over to that page and read about what our characters are fleshing out to be (as “real” characters if we can take it that far).
People — it is OK if you do not understand what a “persona” is right now; basically, we want to have a little fun and see what the characters actually “look like” when they are not working in our comic strips. When they leave the office, what do they do? What are their hobbies? What are their dark secrets? Where do they vacation?
Those sort of questions should be addressed based on what we have already written about them today.
Or… if you totally disagree with what we have come up with — give us a better one!
Good or bad idea?
Who knows.
It will be a little fun. All rights remain ours to use in the future (although we will let people know who added what!).
And.
There will probably be a point to this little exercise.
Feel free to write me off-line or via the comment section underneath the original blog entry (or this one… I can be flexible).
Have fun.
Make it a team exercise.
See where it leads.
And get it done this week!
Thank you.
- mike vizdos
www.implementingscrum.com
www.michaelvizdos.com
Hi all.
Well, I was able to tell you a little about my first two days of this week. If you have not seen it, go here.
Upon arriving into Richmond (my home base) at about midnight, i got the opportunity to make the final preparations for the Certified ScrumMaster Workshop I would be delivering on Wednesday and Thursday.
It would be yet another great class where the attendees walked out of there with a new respect (as did I) for what Scrum can and cannot do.
I have done this course around the world and have trained on my own, with one other person, and with two other people.
Wow.
What a change this makes to both the overall presentation and the outcome to the attendees.
Is this bad?
The easy answer to this is, “No.”
Can every Certified Scrum Trainer co-teach with other people?
Nope.
When it works though….
It is like magic.
I have been lucky enough to work with multiple trainers around the would (and most are not CST’s).
Lucky?
Am I nuts?
Think about it.
If some initial ground rules are set between the two or three people training the class — it can be extremely more powerful at the end of the two days for the attendees.
The first sentence of this is important.
And.
This last one with another Certified Scrum Practitioner (who is looking to become a Certified Scrum Trainer) worked out very well. It was, to be 100% transparent, a surprise to me.
While I was initially looking for the art of the possible, I also knew our styles of coaching in the past has been wildly (sometimes) divergent in techniques.
I made a bad assumption.
Wow.
Like a lot of things in real life that we all live in.
The course got great feedback (sorry about the air conditioning versus the constant heater war going on with the HVAC system… we finally (at the end of day 2) were shown how to useeeeeee the system). Sigh.
So now there are about 11 new Certified ScrumMasters running around Virginia in one place or another.
I’d say it was one of my best classes (workshops) to date.
Why?
Well… let me know why you think this is so….
Gotta run….Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
 |
 |
Hi,
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 Forum to discuss this entry and other Scrum topics. Thank you!
Originally Published:
December 16, 2007
|
|
Hi,
Thanks for continuing to read the series this week about the ImplementingScrum Forum and the entries I’d like to highlight for you. Hopefully also you take the time to register as a member - it is FREE and I do not sell or rent your name or email address to anyone!
Good day.
The topic today is “Done” and what that means on a Scrum Team.
For those of you practicing Scrum today, think about how important this is.
For those of you who are not yet practicing Scrum today, remember when you start that it is a very important topic to discuss with each of your Scrum Teams.
Today we continue examining some of the postings and related comments at www.implementingscrum.com and the forum.
This entry is going to ask you to look at the topic, “Developer Done, or all done?“. Go ahead and take a look at it.
Any new ideas or comments you’d like to add to this topic?
You may also want to check out the following blog postings and comments related to this:
Done. Really?
Who’s Your Product Owner?
Welcome to Oz.
Thanks for continuing to read this — or welcome new people reading and subscribing to this forum!
- mike vizdos
Have a great day and thank you for your time.
- mike vizdos
www.implementingscrum.com
www.michaelvizdos.com
PS –> Want to join the Forum? Click here!
|
|
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
Everyone take a sigh and a breather. Sometimes I think you need it. I do.
A few years ago, when I was still starting out using Scrum, I got this idea that Scrum could be used outside of the IT world. And even the “business” world.
So I posted this. And it has generated a lot of comments and thoughts over the years. People have even organized weddings using this technique.
I tried to implement it at home. So have others.
Over the years, we have been able to do this with some sort of success.
Is it totally Scrum?
Nope.
Can I still talk about it?
Sure. And I hope even one of you walks away with an idea or two about how (or how not) to implement this at home.
Go out an buy yourself a white board, some markers, and some index cards. If you want to go really gung-ho, get those large wall-sized sticky-note-pads.
Start your Product Backlog.
Could be like the cartoon… but I am sure there are other things that need to get done.
Remember.
This Product Backlog continues to evolve and change. Anyone can have input into it.
Anyone.
Now. Also remember….
There is one Product Owner.
Only one.
Really.
Your Product Owner is responsible for prioritizing this list before each meeting. We wind up now calling them “family meetings” to keep it non-IT centric.
Our Sprints are supposed to be week-long. They do not work out that way in reality. And, we have a tough time with the demarcation between the Product Backlog and the Sprint Backlog.
Reality sucks some times, eh?
Deal with it and move on. This is your family… not a company (smile).
Talk about the Sprint Goal and what User Stories (don’t jump right to the tasks!) need to be done. THEN define the tasks and have family members help figure this out.
You can assign story points and hours.
You can track your progress via a burn down chart.
You can then have your Sprint Review.
And a Retrospective.
It can be fun.
And…. stuff actually can get done.
Like at work when Scrum is working “right”.
So.
This is great. Right?
Maybe you are implementing Scrum today at work. Maybe you got a good laugh about the idea of running Scrum outside of Work.
But.
Think about the world outside of IT.
Your business.
You know, the thing that creates customers who pay your salary?
What can you start doing differently using Scrum today?
Heh.
Gotta run….
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
June 4, 2007
For all those in the USA who “celebrated” Turkey Day last week, I hope you are enjoying your leftovers. Make sure to call it quits and either make soup or put them all in the trash by the end of this week. Food poisoning sucks. Know when to call it done.
Which is a nice transition (if I do say so myself) to the topic of the comic strip this week.
So, today I am going to talk about “Done.” Not how much to cook a turkey “done” — but how a team defines done in a Sprint. From experience working with many many many teams, I can tell you this — not one team has ever had the same definition.
Why does defining “done” really even matter? Think about it this way… how will you ever know you are finished — really finished — and not at that eternal “we are 80-90% done” I see on many traditional waterfall projects.
“Mike. Are you kidding me? How hard can this really be?”
Here is an example I use when teaching a CSM (Certified Scrum Master) Workshop:
I go around the room and ask each participant how long it will take them to read the latest Harry Potter book. Usually this is universal enough for people to use as an example.
The answers I get range from two or three hours to six or seven days to six months or more. Others — only a few — say, “Harry who?”
The round of answers (remember… this is a relatively “simple” answer) range from “Gasp… are you kidding me?” to actually opening a great facilitated discussion.
This simple exercise show the people in the workshop that such an easy task can have relatively different views of results.
Some people are speed readers, some people have kids to read it to, others pick it up once in a while, and others just don’t like reading.
Now, apply this to an agile software project using Scrum.
When a team is just starting out (let’s use an example of ex-waterfall-specialists). There are testers, developers, analysts, architects, and other roles on “the team.” At this point, they all associate themselves in that role (OK, not all, but most). At some point in the discussion, I send people to an article by Scott Ambler about Generalizing Specialists. Good stuff there. Read it if you are not familiar with this concept.
While facilitating the discussion about “done”, people usually get one of their first uncomfortable experiences using Agile. That is, having to commit to something. Ouch. This is hard, especially if some Chicken in the past has held their cajones over the fire about past dates being missed.
This is hard for teams to figure out. Really. And, the first time a team attempts to define “done” it will probably suck. And that is OK. Get enough of a definition of the word for the team to agree, and get started with the Sprint. Accept the fact that the definition will change from Sprint to Sprint. And that is OK. Inspect and adapt. Rinse and repeat as needed.
In reality, the team will soon figure out that the Product Owner has the final say as to what “done” really means. Using various tools like User Stories (by Mike Cohn), the team gets to negotiate the acceptance criteria of a story with the Product Owner. Notice this is not with the Chickens. If Chickens want to have a say as to the acceptance criteria of a story, they can hash it out (negotiate it) with the Product Owner outside of the team room.
The one voice the team turns to for the definition — and acceptance — of “done” for a Sprint is the role of the Product Owner.
Period.
End of story. For now, I am done.
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here. You can also enter The Forum to discuss this cartoon and other Scrum topics. Thank you!
November 27, 2006