For those of you unfamiliar with the practice of Transparency in Scrum, take a look here for a refresher. I’ll wait.
After some serious soul searching this week, I came to the conclusion (right or wrong) that since one of the major Scrum yahoo lists actually “banned” someone for participating in a heated thread that I would open up my own forum on this site. It can be found at www.implementingscrum.com/community and I, as the moderator, will allow just about anything to be said as long as people have fun, do not attack one another, and remain professional. I will not kick anyone off who has a dissenting opinion…. if anything, I think that adds to the value of the forum.
Please feel free to join us at the new forum and let’s see if some real transparency can be opened up in our small community.
Gotta run,
- mike
www.michaelvizdos.com/scrum
www.implementingscrum.com
Please send comments, questions, criticisms, ideas, or whatever here. You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
—————————————
—————————————
Hi all,
Since starting the site back in September, I have received a lot of email from readers regarding the cartoon about the Chicken and Pig. If you are not familiar with the story, please go read it here.
Please note: This is not a story I started. It has been around for a long time (even since before Scrum — applied in different circumstances).
I had one very long email thread (that I may one day publish here) that discusses how I am degrading people by referring to them as Chickens and Pigs.
Three words:
Get over it.
In addition to being a great way to have people recognize the role they play on a Scrum team, the analogy has allowed Tony and I to create this cartoon and website.
Cool stuff.
Maybe it is even something you’d like to pass around to your geek friends and neighbors.
And laugh. We all need that once in a while.
I hope you agree.
I still do intend to continue publishing on this site using Chickens, Pigs, and other “cast members” (including the ScrumMaster, Product Owner, and “Ken”). Who knows what else will appear in the future!
If any real Chickens and Pigs are offended, please tell them I apologize. No Animals, ScrumMasters, or Product Owners are being hurt in the production of this cartoon series (smile).
Have a great day!
- mike
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 ScrumMaster) 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 Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
November 27, 2006
I am opening a new forum today in response to many reader requests. Please take a look around, register, and let me know what you think.
The cartoon this week may seem very “Thanksgiving-ish” at first glance. However, the lesson today is that one of the jobs (notice here I said this is a job, not a role!) of the Product Owner is to provide the Scrum Team with lots and lots of continuous food. Good food.
“What do you mean Mike,” you may be asking yourself?
Product Owner — Find the budget for food. It is miniscule at the amount this team is saving you. And remember, they are happily delivering stuff where you actually may have forgotton people could. For you.
During the first Sprint (or iteration), the project usually has enough in the budget for the Product Owner to actually tell the team they can have some food. As any geek knows, food can be a great motivator. The usual pattern for the first time a Scrum Team can actually order food is like receving manna from heaven to a six-year-old. Twizzlers abound. Milk-duds appear as often as a simple Costco run. Potato Chips — the good ones — Pringles — appear to prove that yes in fact, you cannot just eat one.
A great Product Owner funds food. Say it withe me now. Repeat this oftern. Past the first Sprint.
However, as the first Sprint is over, the Scrum Team realizes that — yikes — their belts are getting a little tighter. The six-year-old mentality then starts to turn back to adults around the end of Sprint 3. All of the sudden, instead of Twizzlers and Milk-duds, the team is asking for “healthier” stuff. Trips to the grocery store begin and all the sudden fruit appears, along with veggie trays (with lots of high-fat dips!) and the “low carb” crappy chocolate.
Now, usually by the third or fourth Sprint, the Product Owner starts to take budgetary heat from the outside noise. Man, stakeholders have short memories. Corporate cards have been known to disappear like Brittney and her marraiges. This means food becomes scarce for the team. Let the scrounging begin.
O Product Owners — who, by the way are on the outside of this strip egging on Chicken and Pig to eat — unfortunately show how incredibly cheap they can become when a team is actually producing. Bad things can happen here, as food is now expected by the Scrum Team but nothing shows up to provide for said team. If the food flow stops now, expect the Scrum Team to start seeing dead people. Really. It is that damn scary.
I have a question to you cheap-ass-Product-Owners. Have you ever seen the movie where the plane crashed and people were eaten? I am pretty damn sure those inconsciounable people who actually ate the others were those very tasty Product-Owners. And the rest of the team survived (OK, maybe with a toe missing, but c’mon!). Scary. Think about that.
I do work with teams that, during each Sprint Review and Sprint Planning Session, the Product Owner steps up and makes sure a celebration is had. This can be something as simple as bringing in burgers to something as cheesy as the CheeseCake factory. With Desserts. And know that the two “ss”’s in Dessert is a huge difference than leaving your team out in the desert by not giving them jack.
Product Owners. Be responsible and stay alive. Otherwise Darwin will prove its existence. Comprende?
And guess what…. because I have personally seen this…. the Product Owners that keep their teams well fed see a performance increase many time what the actual “food” cost for the team.
What’s my closing message this week?
Product Owners…. talk to the team members and see what motivates them. Food is an easy kill and also easier to be pound-wise then penny-foolish. You make the call though, and, as Product Owner, hope you are not taking a plane trip across the Andes with them anytime soon. As others found out (in a tasty way from the team), your role as Product Owner can easily be replaced with another who brings food.
I want to thank Mark P. for the metric analogy this week… as well deserved as it was to start, I take responsibility to where it ended!
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here. You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
November 20, 2006
Older Articles »
