|
|
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***Today we introduce the role of Product Owner. Not necessarily a Pig, and not quite a Chicken. And, as we have covered in the past, definitely not a PigKin!
Why is this role soooooooooooooo important, you may be asking yourself?
Ask.
Go ahead.
Or at least play along. Thank you.
When I explain the overall flow of Scrum to new teams — or new team members — I am sure to emphasize the difference between a Product Backlog and a Sprint Backlog. What are the differences between the two? And um, Mike, what does this have to do with the Product Owner role? Hang with me….
A Product Backlog (in Scrum… remember… this is all about Scrum) is a list of prioritized stuff that the Product Owner wants “done” for the entire project. It is owned by the Product Owner. Now, the Product Owner is the person responsible for negotiating the priorities and items on that list with both the Scrum Team and all the outside stake-holders on the project (the many many Chickens).
I affectionately call this “The Noise” to the team. Why is that? Because the working list for the Scrum Team during each iteration is not the Product Backlog, it is the Sprint Backlog. Let me explain the Sprint Backlog to you, and then we can delve into the reasons why the team desperately needs this distinction of work items.
A Sprint Backlog is a list of prioritized stuff that is taken off the Product Backlog for completion during a Sprint, or iteration. It is compiled and agreed to by the Scrum Team (Pigs) and the Product Owner. Chickens have no say as to what the Scrum Team can commit to completing in a Sprint. Thus, the distinction. Say it with me now — a Sprint Backlog is owned by the Scrum Team doing the work within an iteration. The Product Backlog is owned by the Product Owner and can be — should be — constantly negotiated outside the team room with other Chickens. Thus the reason for the Product Owner shielding the team from “The Noise.”
Why should the Pigs and Chickens actually care what the difference really is?
The Product Owner role can suck.
There. I said it. Why?
Well, this role – in conjunction with the Scrum Master — is responsible for making sure that the various Chickens and Pigs understand the differences between the two types of backlogs. Here is where the role — or more specifically the person playing that role — can break down…
During a Sprint, while the team is working off the Sprint Backlog to burn down stories and tasks, the Product Owner must be available to the team for answering questions about such-and-such feature. Must be. This is non-negotiable. Now… during the Sprint, the Product Owner must also work outside the team room to continually negotiate and re-negotiate the list of items and their said priorities on the Product Backlog. Again, the Product Owner can shield the team from, “The Noise.”
Read that last paragraph again. I’ll wait here. Whooo deee dooo. [Kidding — I really am a patient person!]
Where can people implementing Scrum screw up this concept? Oh, my dear reader, in a myriad of ways.
Sometimes during a Sprint Planning Session, a team will try to sneak in something called “Kickers”.
What this really should mean is the Scrum Master should be kicked in [the place the sun does not normally shine] if “kickers” are allowed into a Sprint [contact me if you need help!].
“But Mike [insert whine here]…. We are difffffferent.” Ugh. There is that statement again. May I remind you — every team is different…. that kind of makes you the same (wow… how so very Zen, eh?).
What is the correct answer when you see this happening, and how can you tell this is even happening during a Sprint (because sometimes teams get “sneaky” and lo and behold, their burn down chart is not heading toward zero, and people are working and doing “stuff” [kind of like a gerbil running on that round thing in their cage]).
The first clue is the burn down for the team. Trust me, the team needs to understand it is a guide for them to use — not for some compliance wonk to check off a box during an audit (an unfortunate symptom) or a Chicken Manager walking into a team room and having a coronary over the fact that the team is not working at the “ideal time” displayed on the burn down sometimes).
I usually work with teams during a Sprint Review and Retrospective and ask them… “Hmmm… You did not burn down to zero again…. why is that so?” The stock answer — after the whine described above — is something along the lines of, “Oh Mike, it’s OK, we never reach zero.”
Now, instead of going right-wing-religious-Scrum-Masterish on the team (trust me, whenever I try this it does not work)…. go back to some of the basics of Scrum. Explain the difference between the Product Backlog and the Sprint Backlog. The Product Owner needs to back you on this. If the Product Owner does not back you on it, the team is probably screwed anyway and needs more than just help interpreting a burn down chart.
The team needs to focus on finishing the work they committed to on the Sprint Backlog. If people are sitting around bored or surfing the net (and the Product Owner, who is actually writing the check for the team is not OK with that) during a Sprint, and if say a developer could not possibly help a tester [ding ding ding red light alert here too!] then said developer should say something at the next standup, own up to the fact that they need work, and negotiate taking something out of the Product Backlog and bringing it into the Sprint Backlog to be worked on.
So how is this “different” than a “kicker” story (or, as I usually see, cherry-picked stuff that is low priority for the business but fun to work on)?
It causes people to start thinking like a team. Hmmm… Insert some cool music you like right here….
Maybe a developer pairing with a tester is not such a bad idea. Maybe saying, “I need something to do,” takes some major-brass-lined-cajones. Maybe people can start working as a team instead of thinking in their old silos.
“But Mike… [insert whine here].”
If you get to this point [I have]… shut-up, walk out the door, and let the team do whatever they think is right.
Whatever that is really is not Scrum.
And that may be OK.
So….
If the team is happy with it, go ahead and let them hack away at it. Work with teams that sincerely want to learn how to improve. They exist. Trust me.
When [or IF] the team gets sincerely interested in working as a team again (sometimes they do not, and no “methodology” can help here) be there to help them.
Shoot. I hope that was not a major tangent.
But I hope it shows you how delicate a role the Product Owner must play.
Welcome to the team!
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!
October 30, 2006
Getting off the Island
I define Self Selection [in this context] as the ability for an individual on a Scrum Team to be able to have the maturity to conclude that Scrum is not for them, and allowing individuals to leave a Scrum Team between any iteration going forward. This usually gets a good laugh (if Chicken/Manager is in the room) or a stern look from the Manager of the “Resources” (AKA “PEOPLE”) in the room (along with no laughs — just some uncomfortable silence).
This is another tough topic to talk about; it is especially true for teams that are currently being run by an iron-fisted micro-manager in a highly ineffective waterfall environment. This is one of the many topics that Scrum Masters will encounter when introducing Scrum. At first glance, Chicken will come to me after the meeting with a pissed off look on their face and sit me down to “talk about how we are different here.” “You see Mike,” says Chicken, “I am responsible for making sure my team is 100% allocated and productive, and making sure my people do not get under utilized.” At this point, I usually whip out my very effective — shall I say “patented” — pause (some people call this silence). And let them dig themselves in further.
[Tangent ON]
I am well known in small circles for being quiet when needed. Very quiet. I do this purposefully and understand this is a hard thing for people to do. Heck, this is hard for me. I practice this on a daily basis. If you think this is something you’d like to try, do this in your next exchange of information with someone…. shuddup and listen. Really listen. And when you want to say something. Shut up. Do anything… but do not talk. Count to ten (quietly — remember, you are l-i-s-t-e-n-i-n-g). By the time you are done counting to ten (usually well before then) the person you are speaking with will have filled in the silence. Fun stuff.
[Tangent OFF]
So how can a team really hold themselves accountable to being able to Self Select themselves off the team, and that person does not see this? One of the best techniques I use (as a Scrum Master) is to actively coach the Chicken in the room to hold off any commentary to the team for the first iterations. Then sit back and watch. Really. Actions do prove to be louder than words in this case. It is usually that easy. Can it blow up in your face? Sure. It has mine. But, I blow off the dust and keep trying. When it does work though, the Chicken will usually come back to me after the second or third iteration and say, “Oh Mike, on that Self Selection topic… nowwwwwwwwwwwww I get it.”
How do I help new teams with this concept? Again, simple stuff. Active daily coaching of individuals. Person to person. Not hiding behind a MS Project file and allocating resources and re-baselining schedules bla bla bla. Yawn. If a person does not want to stay on a team, I usually ask that they commit to staying at least through the end of an iteration and see how it works out. Disrupting the team mid-Sprint is a bad thing you see. At that point, I can work one-on-one to see if this person really can work in this environment. I have seen some of the best team members and new Scrum Masters coming from teams where this rule was one of the team norms.
What if the team decides a person really needs to be voted off the island?
Either this person sucks at their job, has no interest in being on the team, or really is just the type of person who will bitch and complain about anything and likes being heard. A team can be a powerful [good] force. Usually with some one-on-one coaching with this person, and the team — through daily stand-ups, working through user stories or tasks, or other techniques — the person usually can find some other place within the organization where they can make a difference.
Note: If you are having a hard time figuring out how to tell a person they need to leave the team, you can always print out this article or send them a link to this page. My feelings will not be hurt. Proceed with caution.
And when that team member leaves, there is a breath of fresh air. The team continues to improve.Notice here that the Chicken/Manager did not make the call. The team and the individuals on the team (Pigs) make the call. And like a good little Chicken, the manager can then help the self-selected person find a new role within the organization and help place new individuals on the team as they request it. It is a win-win strategy for everyone involved.
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!
October 23, 2006
Again, more often than not.
What can you do to make sure transparency is used to your (and the teams) advantage?Realize that transparency is a good thing. Really. That being said, some enterprises do not accept transparency within their culture (see above). If you are starting a Scrum team in a heavy command-and-control environment, where the leaders (Chickens) are rewarded for acting that way, you may have a tough ride up the hill. Let’s assume for a moment that your environment is that perfect little happy place where transparency is embraced. How would that look?
The team understands the impact of transparency and can communicate it to the outside stake-holders (Chickens). The team has been trained by the Scrum Master and learned by “doing” Scrum what transparency means. It has learned that they can indeed expect middle managers and muckity-muck executives to actually attend stand-ups, understand a burn-down chart, and participate in a Sprint Review. Wow. And it has learned it through trial and error, working with both the Product Owner and Scrum Master in communicating with the outside stake-holders I affectionately call “Noise.” It is not like the comic strip above, where you can request anything — or anyone. But Scrum is set up to help the team ask for help from the Chickens when the team realizes this is necessary.Not the other way around. Think about it. Close you eyes and imagine the above scenario in the two different ways it could play out. I’ll be here when you get back. Go.
Welcome back (smile). What questions did that bring up in your mind? Now, what are you going to do to answer them?
I will have some suggestions in another article.
The story continues soon. Come back for more….As you can tell, the site is starting to reach some regular feel to the delivery and content presented. 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!
Want one place to see all the comic strips? Here is the place. You can continue to get updates via this blog entry, but rest assured you can see all the illustrations in one place now. Enjoy!
Do I see this happening in reality? Unfortunately, more often than not. The largest crowd I have to work on coaching for this “affliction” is the line or middle management. If they are coming from a typical command-and-control // waterfall methodology environment, the middle managers are used to giving orders and having them fulfilled. This Scrum thing can be perceived as a large threat to them. Can you understand why?
Think about this. At some point in a “typical” middle management career, a person taking on this role was “rewarded” for being a super effective sole performer (insert role name here — programmer, team leader, analyst, or having pictures of their boss in a compromising situation (I am kidding on the last one, really!)). Once the sole performer has made the leap to a middle manager, the game in large corporations change to mostly pure politics and making sure that they get next year’s budget by spending the budget they have this year (another common thread I see with clients — spend like there is no tomorrow in the fourth quarter to “use up” the money that will disappear by January 1st (or whenever their fiscal year ends)). I usually shake my head and sigh, but this seems to be reality.
Now, take this middle manager and start that person with a new Agile methodology (in this case, Scrum). Typical response from said middle manager, “Oh, I have been doing this with my teams for years. We get them together, put them into a room, give them food and lots of compressed deadlines and viola…. out comes a product at the other end. Really Mike (patting me on the back), I know how to do this…”
Now comes the story of the Pig and Chicken. For a refresher read here. Go read it and come back. I promise I will not go anywhere… just come back real fast. I am waiting!!!!Done with the refresher? Good. So, please recall…. a Pig has SKIN in the game. Their bacon. Their asses-to-the-fire. Accountable. When relating the Pig/Chicken story to a middle manager starting with Scrum, I get to tell them they are a Chicken. They lay eggs. They contribute. Responsible to deliver the project? Sure, but not accountable on a daily basis to get it done. This naturally leads to contention.
[Tangent ON]
OK… remember… I am a consultant. I can say things that some people (maybe you) may not feel comfortable saying. If you are not comfy talking to a middle manager (or above) about this topic, feel free to use this as a job-aid and send it to them for review. I’ll take the heat. They will laugh (and maybe want to hire me — google is a good thing — spelled VIZDOS). Remember, I am an outsider with only opinions (of which they pay dearly for, and I sincerely appreciate!). Also, I am not knocking the middle manager role; it is just an easy on for me to use for the Pig/Chicken analogy. Laugh guys and gals. This is good stuff and you know it![Tangent OFF]
Where was I? Ahhh.. yes. Contention. See, remember in the corporate world there is huge game of politics that must be played — on a second-by-second basis — in order to “win” at the end of the year [they have to beat their peers and look better than the others so the next promotion can come to them]. Does this happen in all corporations? Surely not. However, since I get called in most of the time when things are blowing up, I can tell you it occurs more often than I care to talk about. Does it matter if it is a large or small corporate environment? Probably not. In smaller companies, I have a better chance at speaking and working with the “C-Level” executives (CIO, COO, CEO, CxO, etc.) but in a lot of cases those smaller companies are as large as some of the smaller divisions I work with in the larger corporations.
Basically contention can occur anytime more than one person is involved. Sometimes it only takes one, but that is why doctors can write prescriptions for Xanex (smile). So in the eyes of a middle manager, they now see some outside consultant (or internal Scrum Master) coming in and rocking their comfy world. This is not the best place to be for most people. I enjoy it. Really. Gives me great content to write about and share with you….
So, the conversation usually winds up with the middle manager agreeing to be a Chicken. “Sure Mike… no problem.” Until the first time the team blows chunk (for those unfamiliar with the term, think about the last time you went fishing and the ocean had some really large waves and the porcelain princess was your only true cold friend).
The story continues soon. Come back for more….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!
October 9, 2006
First, you can get your Monday “fix” of the comic.
Second, it will allow me to ease off the pressure of having to deliver everything in one big up front design. Wow. Sound familiar? This is one of the things agile promotes; so in reality, I will start eating my own dog food.
We will both learn more in the process. Let’s hope.
So today’s comic is meant to invoke some answers to the age-old (OK, since 1990-ish) question, “What is Scrum?”
There has been a lot written about what is — and is not — Scrum. During this week I will give you my thoughts about what is out there, and what still must be addressed.
Sound fair? Let’s see how it goes. Oh, and thanks again for joining me on this journey.
[tangent on]
Scrum is a journey actually… and there is no “end point.” This is something to remember as you either start or continue to practice this way of working (don’t want to say “life” because I *do* promote a work/life balance and I do not want to sound uber-cultish like some of the uber-Scrum-People out there).
[tangent off]
This comic portrays what “typical” people around the world think of when they hear the word “Scrum.”
In the first panel, generally people outside the USA think of Scrum as something that happens in a Rugby match. You can read more about it at www.scrum.com [I have no relationship with that site]. I cannot even pretend to understand it (much like cricket or football (what we Americans call Soccer)), except that it looks like at least three people trying to cram at least one other person up another poor soul’s posterior. Ouch. I guess some would call that fun. I’d say let’s just skip to drinking some Guinness.
To the average Joe (or Jane) American, I generally get a look of, “Huh” followed by glazed-over-eyes when I try explaining it. I’ll address more later, but suffice it to say that even if one were to look on www.wikipedia.org for a definition, the closest to a non-Rugby or non-IT answer again lies in something pretty gross… “A slang term in American English for the perineum.” Umm, if you need to look that word up, go ahead. For those of you who have had a baby or have had the [opportunity] to see one (or more) being born, you may know what it is. OK, so not gross, but pretty explicit. Strange thing though…. I am an American and have NEVER heard that used as a slang term before. Maybe I just do not hang with the “right” group of people (or maybe thankfully I do and just don’t realize it!).
Finally, the last panel shows what a lot of the IT community — internationally — now knows. It (Agile, Scrum, etc.) is a good thing to have on your resume. Even if it means getting calls from a software company that produces some product called “agile” or hearing from recruiters all around saying, “Hi, I have the perfeeeeeeeccccttttt position for you.” Only to the point I ask them what it actually “is” — and they cannot answer. Or make something up. Click. That noise they usually hear is the dial tone. To tie in the above references about shoving people where the sun does not shine and the perineum, think about this… who’s posterior gets routed on IT projects when they do not get delivered? Heh.
This is a good start. More coming soon to a web browser near you.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!
October 2, 2006