I have written about some of these concepts in the past, and this blog entry takes it up a notch (so hang in there with me!).
So in Scrum there are only three defined roles….
ScrumMaster
Product Owner
Team Member.
That is all. Really.
And this is your team.
This is the team to deliver the completed work item.
Now, there are people out there who discuss (argue?) about which of the roles above is part of the team.
My answer:
All of the roles are members of the team.
It is critical that the roles are defined on a team, understood by the team (and its stakeholders // Chickens), and enforced by the team (not by the stakeholders // Chickens).
Pigs versus Chickens. See this blog entry for more information about this concept.
I’d say all three of the defined roles are Pigs. You cannot be a Pigkin.
Does this mean Pigs and Chickens do not talk?
No. Of course they talk.
However, it is their interactions between the Pigs and Chickens that may differ among the three roles.
The ScrumMaster must interact with the Chickens to help remove impediments. When the team asks for it. The ScrumMaster is also the facilitator of the process for the team. This person is an active member of the team.
The Product Owner must intereact with the Chickens to make sure questions are answered and addressed (from the team members asking). Remember… the Product Owner “owns” the Product Backlog and is responsible for prioritizing it for the team in order to perform effective Sprint Planning (and execution of the Sprint).
Does that mean the Product Owner is ruler supreme?
No. Of course not.
The Product Owner needs to be available to team members for answering questions and helping lend a hand to the team members when time is available.
Wow. Ummm. This is a debatable area.
However.
I have found that when a Product Owner actually has the time / bandwidth to act as a productive member of the team, both the other team members and the Product Owner learn a ton from the other. So, in addition to blocking and tackling the “noise” for the team from outside stakeholders (which sometimes takes almost 100% of their time), the Product Owner is also negotiating with the other stakeholders about the items on the Product Backlog and the said prioritization with that list.
More information about the Product Owner role can be found here [LINK].
This leads us to the last role, a “team member.”
It is fun (and rewarding for all) to see the evolution of a team from specialists (I am a tester, I am an architect, etc.) to “I am a member of X team” (see generalizing specialists).
And, I’d say the ScrumMaster and Product Owner are an active part of the team.
This happens to a naturally evolving and growing team.
Really.
All teams. Who want it to happen.
Bruce Tuckman has written extensively on the stages a team goes through during its development.
They include:
Forming.
Storming.
Norming.
Performing.
And, as Mark Pushinsky (one of the trainers I co-teach with) has added…
Mourning. (Although it looks like Dr. Tuckman may be calling this adjourning… see we may not be all that creative lol).
The reason for this addition is when a team is “done” doing its work, the team members do need time to decompress and figure out how to “start over” with a new team as they leave the current team.
This process happens with all teams.
And.
You cannot skip any of the stages.
If you try, go back to ground zero and start again at Forming.
Also.
If your team changes at any point during its life (people come and go), guess what?
You need to start over at ground zero all over again.
Is all the above correct? I think there will be debates (ahh… better word than arguments) from people about this minuta for years to come.
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!
February 26, 2007
Welcome back to a new week at www.implementingscrum.com.This week I want to discuss something that does not happen very frequently; however, as a ScrumMaster — or member of a Scrum Team — you need to be aware of its existence and the power you have to use it.
This is something I teach on a regular basis (in fact, just last week in San Diego, California!)…
There is something called a Scrum Abnormal Termination. Here are the “rules”:
- Sprints can be canceled before the allotted thirty days are over;
- Team can cancel Sprint if they feel they are unable to meet the Sprint goal;
- Management can cancel Sprint if external circumstances negate the value of the Sprint goal; and
- If a Sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.
One of the things we teach during the workshop is the concept of a “wailing circle”, where the team lays (lies?) down in a circle with their feet together and cries out in a loud voice. The purpose of this is to make it look ridiculous. It does. Sigh.
Actually, I have personally stopped bringing people up to the room and presenting this as an exercise. One of the main reasons for doing this is the reaction it had during the workshop. Think crickets at night. Then stopping in dead silence.
Ohhhhhhhhhh K. So.
I inspect and adapt. I have learned (smile).
So is this really something that happens in the real world?
Yes.
Do I tell the teams they need to do the wailing circle?
Nope.
How often does a Sprint Termination happen?
Rarely.
Really.
It should be used to make a point. Let’s review the options presented above:
– Sprints can be canceled before the allotted thirty days are over;
We all live in the real world. Because a Sprint starts out to be thirty days (or whatever the length is for your Sprint — as long as it is consistent!) does not mean things do not change in that time period. I have used this once in this case because there was a major reorganization at a client site during the middle of a Sprint. Half the team got whacked. I figured it was a good thing to take a breather and start a new Sprint when things settled down. Was it according to any book? No. Did it make sense? Sure. And the team found its was again. Eventually.
– Team can cancel Sprint if they feel they are unable to meet the Sprint goal;
If you start a Sprint with the a technical choice (for example — batch versus real time solutions) and the team figures out a solution to one choice over the other in the middle of a Sprint… would it make sense to stop things and re-plan using this new information? As a team, they can decide that. As a ScrumMaster, you need to be able to facilitate this.
– Management can cancel Sprint if external circumstances negate the value of the Sprint goal;
OK. This one is not an excuse for the Chickens to run the asylum. Really. However, let’s pretend the team is working for an organization in a highly federally-regulated environment. And, let’s pretend that Congress makes a change that has an immediate external impact on the direction of the team. Now… stop pretending because, guess what, as a team you cannot just break laws at your leisure. Or well… it is not highly recommended. Remind the chickens that this part of the rule is not to allow for canceling a Sprint at their own peril. Think about it. And help guide the Chickens when trying to make a call like this.
– If a Sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.
What do you do at the end of every Sprint? Besides the Sprint Review, there is a Sprint Retrospective. Have one. Then, when the time comes (it may be immediate, it may not), embark on Sprint Planning, Rinse, and Repeat as directed.
And to think, I could have brought Arnold Schwarzenegger into the comic strip this week. I went for the artsy-fartsy example. That being said…
“I’ll be back….”
Sigh. Sorry. Needed to say that (smile).
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!
February 19, 2007
Ug. Nothing can be farther from the truth on this one.
Scrum is not a license to be a hacker.
Scrum is not a license to pick and choose selective parts of the practice for you to implement.
And.
Scrum is not a silver bullet.
That being said, why am I so adamant about wanting to strangle people when they say, “This is Agile. We do not plan.”
I am glad you asked (smile).
From Mike Cohn, we know that in Scrum there are three levels of planning. The first is Release Planning. The second is Iteration (or Sprint) Planning. The third is Daily Planning.
I will examine each planning cycle from what I understand by doing it on a daily basis. For other information about this (more details, etc.) see Mike Cohn’s book(s). Remember the following views are what I have learned through practice….
— Release Planning
This is accomplished through the use of the Product Backlog.
One of the common themes a Product Backlog helps answer is, “When we you be done?”
Remember in Waterfall Projects a Project Manager is handed a date (usually out of thin air) and then, come hell or high water, a project is decalred “successful” on that date. Sometimes to the dismay of the team who knows things were cut (think quality). I know this is just one example of what can happen, but it does. All too often (and before Agile I was guilty on both sides of doing this).
With projects using Scrum, the Date and Budget are fixed. Scope is move able. See this posting. How is this different than a Waterfall Project? For me, it means that the team has an active discussion with the Product Owner about what is happening in reality. Sometimes is sucks. But. These discussions need to happen. Welcome to one of the joys of being a ScrumMaster!
How do you do Release Planning with the Product Backlog? After the first Iteration / Sprint or two, the team has a good idea of the velocity. If you are using Story Points, you take the total number of Story Points, divide it by your velocity, and it will tell you how long the Release will take.
That’s it. It is that simple.
The discussions that take place can be tough. Life can be that way.
— Sprint (Iteration) Planning
This is done by taking the highest priority stories off of the Product Backlog. And the team having a discussion with the Product Owner about what the team can during the Sprint. Estimate out the stories (sometimes using ideal days / hours). And again, have a conversation with the Product Owner about what you can do as a team.
Pretty reasonable. Again…. tough to do.
And stick to it. Keep the Product Owner on task for making sure NOTHING else (other tasks) get into the current Sprint. This is a hard thing. Again, it gets easier with time!
— Daily Planning
Say it with me… “Daily Stand-up Meeting” (or “Daily Scrum”). And… what are the three questions?
1) What have you done since the last stand-up?
2) What will you complete before the next stand-up?
3) What is in your way?
That’s it. People can “talk” to the task cards, or they can talk “to” a user story. It depends on what the team likes doing. Let the team decide. Let the team waffle on this for a while, and allow it to change over time. The important thing is that people are talking. Communicating. And keeping it to fifteen minutes.
Read that last sentence… in case you forgot… Keep it to fifteen minutes!
So, with all this planning happening, can you really say that Scrum has no planning?
If you still do think that… maybe take a look at how your team is implementing Scrum.
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!
February 12, 2007
Sometimes it gets asked as “What do you DOooooooooooooooOOOooooo?” This blog entry will not explain “what” a ScrumMaster does, but more about HOW *I* as a ScrumMaster help get it started.
My style when going into an organization is to watch and listen.
Really.
I have learned that silence can teach me — and others learning with me — more than I can sometimes even teach my talking or yapping away.
And it looks like I am just “sitting there”.
This is a usual pattern of mine since I work with a lot of teams making the transition from waterfall project management to the Scrum framework. And it requires a big shift in change and patterns from the team making the transition to Agile and Scrum.
It — “the shift” — does not happen overnight. Trying to go commando-uuber-religion-Scrum-like is a turnoff to any team. Trust me (licking my wounds).
So… pigs (who are busting their asses sometimes working 24*7 and trying to really see that a work-life balance may work for them) and chickens (who may be paying for me to sit and watch them) ask this question a lot.
Even if it is not to me directly. Actually, people sometimes ask me directly, “Mike, do you even know what you are doing?” Um. Yes. I do. Am I always successful with this technique? Nope. I am human. I make mistakes and move on. And learn from them.
When do I engage?
I usually wind up engaging pretty quickly. But it is the “how” I engage that sets me apart as a ScrumMaster versus a traditional Waterfall Project Manager.
[tangent on]
I have the greatest respect for Waterfall Project Managers. I used to be one. Felt powerful. And “in charge.” I also used to be a work-a-holic and had no work-life balance to speak of. I then made the “impossible” choice to look at — and implement — more agile techniques. It was a personal choice and it is not for everyone.
[tangent off]
How is a Traditional Waterfall Project Manager different than a ScrumMaster?
Well, one way that became very clear to me recently is that Project Managers manage to Budget and Time along the Iron Triangle. With Scrum, those two lines are “fixed” — and Scope is the negotiable factor. It leads to a lot of interesting conversations if you are open to receiving feedback from some Project Managers about how Scrum is non-managable. I literally saw some Project Managers’ head almost blow up when talking to the them about this situation. Wow.
As a ScrumMaster, instead of saying things like, “Instead of doing such and such….” I will talk about ways I engage at a subtle level and allow the team to make a choice.
I think most regular readers will of this blog know that Silence works. For those of you who may be reading my blog for the first time, or have not seen me write about it… think about this. Over my phone (on my monitor) I wrote a sticky-note that reads, “Shut Up. And Listen.”
Huh?
Most people I speak with like the act of talking and being heard. Hey, I like it too (you are reading this blog with no real opportunity to speak with me about it other than via email or picking up the phone to speak with me). But I have found that when I am done “talking” — I stop.
And listen.
This can be hard. Many people do not like to hear the sound of silence, and usually someone will jump in to fill the void. I work hard to make sure that person jumping in is not me.
Try it.
See what you can learn.
“But Mike, people PAY you to give advice.”
That may be the case for a lot of my clients before I work with them. Before beginning any engagement, I do try to set expectations — and this “silence” thing is one that is tough to swallow.
Why do I insist on it? Other than past learnings (ouch)….
I want to help the team — from day one — start to start thinking and acting on their own. Once I jump in to “answer” a question — or anyone does for that matter — it can lead to a dependence on some one person always having the answer. As a Waterfall Project Manager, I thought one of my jobs was to always “have the answer.” Where did that get me? Sigh. That is fodder for another blog entry (smile).
Your job as a ScrumMaster is tough sometimes. This is one area of advice I wish someone had shared with me when I started on this journey.
Is this tact something that all ScrumMasters should start using?
Nope.
Find out what works for you. And the team.
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!
Now… I will shut up. And listen…..
February 5, 2007
