Keep the questions coming… you never know when a thread may wind up on this site (or in a cartoon)!
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 ScrumMaster — 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 ScrumMaster 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 Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
October 30, 2006
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 ScrumMasters 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 ScrumMaster) 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 ScrumMasters 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 Scrum Community 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 ScrumMaster 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 ScrumMaster 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 Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
Originally Published:
October 16, 2006
More:
Want one place to see all the comic strips?
You can continue to get updates via this blog entry, but rest assured you can see all the illustrations in one place now. Enjoy!
Welcome to another Monday (albeit it late — or Tuesday morning — for my European readers). Today’s comic strip represents a common misperception that a Chicken and a Pig can be one person. It really does not work.
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 ScrumMaster) 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 Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
October 9, 2006
Older Articles »
