|
|
![]() |
![]() |
Interested in becoming a Certified Scrum Master?
Come to my next workshop!
The Guest Blogger this week is Michele Sliger, a fellow Certified Scrum Trainer and awesome person in general (smile).
A few weeks ago some of the Trainers got together in a super-secret-location-on-Earth for a couple of days.
We had a lot of fun, I learned a ton, and you can be sure I will write more about it in this blog in the future!
Michele posed the question to the Trainers, “What are the Scrum Values?”
And. Gulp. I could not name all of them.
Shame on me.
Or? Are they something I just *do* like a lot of people already?
Either way, I thought this would be a good platform for Michele to discuss the Scrum Values and give some great examples for you to use with your Scrum Teams.
Keep learning… I do daily….
Here is the write-up from Michele:
====================
Like Mike, I’m a Certified Scrum Trainer and I make my living teaching Scrum and coaching Scrum teams.
One of the things I teach is the Scrum values. Do you know what they are? Take a second and see if you can name them all.
I’ll give you a hint: there are five, they are one word in length, and one of them is not Honesty. Now stop reading for a moment and when you think you’ve got them all, come on back.
Ready?
Okay, let’s see how you did.
I’m sure none of you cheated by going to the first Scrum book, “Agile Software Development with Scrum,” and flipping to the last chapter.
(I can hear it now: “Heck, she said that Honesty wasn’t a value, so where’s the problem?”)
The five Scrum values are, in no particular order:
-
1. Commitment
2. Focus
3. Openness
4. Respect
5. Courage.
Now what do you suppose these mean?
Ask a roomful of people and you’ll get a roomful of answers.
“Openness means that we will tell the product owner ‘no’ when we can’t do any more work in the Sprint.”
“Openness means that we will tell management that we are doing Scrum even though we are afraid they will make us stop.”
“Openness means that when my colleague takes a three-hour lunch break instead of finishing her tasks that I will have a difficult conversation with her.”
“Openness means telling you that I did in fact cheat — I looked up the values in the back of the black book.”
(I once had an argument with a co-worker on what ‘being truthful’ meant. He said that it wasn’t lying if he went to a topless bar and didn’t tell his wife. I said it was a lie, one of omission. We went back and forth, each sure of our morality. So I’m pleased that Ken was careful in his naming with the value of Openness, instead of something like Honesty or Truthfulness, so I don’t have to have arguments over what truth means!)
Because we each interpret the values differently as individuals and as teams, we really need to take a look at each value and decide as a team what that value means to us.
Here are a couple of ways you can do that:
If your group does regular brown-bag lunches, open spaces, or Scrum cocktail hours, pass out copies of that last chapter and say, ‘This is what we’ll be talking about at our next get-together.’
Then have that informal conversation and see what the team thinks about the values.
Are there any that surprised them?
Are there any that weren’t in line with their personal values?
Can they say that the team has been adhering to all the values?
Are there any values that they think should be listed that are not?
And are there any values that they would like to make a bigger, more overt, part of their daily activities?
When working on the facilitation of team working agreements, try this exercise.
List the values, and this simple template that can be used to turn each value into an actionable working agreement:
We believe in [value] therefore we will [do something].
For example, your team might come back with:
“We believe in respect, therefore we will show up on time for all meetings.”
The point is to get those values on the wall somewhere, where they can serve as reminders to the team of the drivers behind the Scrum practices, and of how the team has chosen to work together.
Remember, Scrum is not only value-driven in how it provides the most important features first to the customer, it is also value-driven in how the people choose to work together to get the job done.
====================
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!
March 25, 2008
![]() |
![]() |
Interested in becoming a Certified Scrum Master?
Come to my next workshop!
This is the conclusion of a three part series for the week. It has been interesting for me to write and people have written me some great emails about their thoughts on this.
Thank you.
Two nights ago I posted the first of three comic strips by a guest artist (my son Dominic). You can view that here if you have not already seen it. Part two is here. Please remember that our awesome guest artist is turning eight very soon — and drawing is one of his passions.
So take a look back at the first two panels of the series for the week. I’ll wait.
The first is where the Chicken asks the age old question.
The second, well, the Chicken get attacked by what I will call “reality.”
And.
Reality happens all the time in each of our lives.
Really.
I guess that is why they call it reality.
This final panel shows that Pig (team member) has the back of the Chicken.
What does this mean?
Think about it.
Without the Chickens — or possibly outside stakeholders in your world — the project would probably never have been funded.
Or.
Continued to be funded.
Remember, in an agile world funding really should depend on a team delivering potentially shippable software each iteration.
This is tough to do.
And.
Chickens can help the Pigs remove the impediments.
So.
Why should Chickens and Pigs work together?
Hmmmm.
This panel of the cartoon shows that while the Chicken is being attacked by their monsters (outside the project room where the Pigs are working on the Sprint Backlog), the Pigs (team members) see that sometimes they need to step-up and actually help the Pigs “fight” the monsters.
Even if sometimes the Pigs are left for dead.
Huh?
Think about how this can be applied to what is happening on your team today.
It really and truly is a symbiotic relationship.
That must be fostered.
Who’s responsibility is this?
Think about that and talk to your team about it.
And remember both need the other to survive.
Hope this helps!
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!
February 27,2008
![]() |
![]() |
Interested in becoming a Certified Scrum Master?
Come to my next workshop!
This week is a bit different than the usual…. whatever that may be (smile).
Last night I posted the first of three comic strips by a guest artist (my son Dominic). You can view that here if you have not already seen it. Please remember that our awesome guest artist is turning eight very soon — and drawing is one of his passions.
So.
In the first part of this series, the Chicken looked into the mirror and saw a monster.
Something that the Chicken may or may not have wanted to face.
But.
The question was asked. You know… “Mirror, Mirror, on the wall….”
And.
The mirror answered.
In this part of the cartoon (number 2 of 3), you will notice that the monster is out and attacking the Chicken with full force.
Huh?
What does this mean in the real world?
One interpretation may be that the monsters — let’s possibly call them stakeholders — sometimes are not on the same page as the other Chickens in expectations. And, when it is time to do a Sprint Review, the Chickens may have to face some very difficult questions.
Like, “Who is your Product Owner?”
Like, “What the heck do you think you are doing?”
Like, “Wow. This is the most awesome thing I have ever seen in my entire career since I coded in COBOL in 1963 [expecting emails LOL].”
That last one would be a good monster for those that are paying any attention.
This happens in reality.
At some point, Chickens (and the other roles including ScrumMaster and Product Owner) will have to face down some big monsters.
Possibly, this is because the team has asked them to clear some impediments.
And some impediments are really stinky.
And.
Finally.
Maybe.
Just Maybe.
Someone else on the the team can stand up and help defeat a bad monster for the team. Together.
As a team.
We will cover that topic tomorrow night.
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!
February 26,2008
![]() |
![]() |
Interested in becoming a Certified Scrum Master?
Come to my next workshop!
Tony had the weekend off (his wife / Product Owner took off with some friends) and my son Dominic was very psyched about doing a drawing this week for all of you.
As usual, I gave him a topic and this is his rendition. This comic strip will be given to you over the next three days, in black and white, with no text.
Why?
A few reasons… first…. Dominic was horribly sick this weekend and his daddy (me) is on the road a bit right now. He did an awesome drawing of the series on paper and I was able to bring it with me on the trip for the week. Using the iPhone camera, I took separate pictures of each of the three parts of this comic strip.
Is it perfect? Well… the drawings are. Dominic rocks. The pictures quality (or lower than I expected) is from me; I accept responsibility for that part. They are not optimized for speed of loading, so I also apologize for any “slower” than normal load times.
Is it good enough?
I think so. And that is the reason I wanted to actually use what Dominic and I produced for the week.
I think and hope you will get the message over the next three postings.
Remember. Agile and Scrum concentrates on delivering potentially shippable software.
It is something you and your team can build on.
And.
You should have a place where you and the team can look back (maybe during a retrospective [Part 1, Part 2, Part 3]) in a safe environment.
And.
Not do the same mistakes again.
In this first segment, think back to when you were a kid. Yes, I know for some of us this may have been a loooong time ago. But think — and also start thinking of why I am trying to bring a child’s perspective into this series every once in a while.
The Chicken is looking into the mirror — the magic mirror — and asks that question which always gets asked in the story books.
Paraphrasing, it goes something like this: “Mirror Mirror on the wall…. Who is the fairest of them all?”
And.
Honestly.
The majority of times a Chicken never wants to hear the truth.
The “monsters” that get in the way are usually huge.
Really huge.
And ugly.
And, the Pigs and everyone else on the team knows that this is true.
Wow.
So part of the whole thing with Scrum is to talk about Transparency.
The Chicken tonight at the end of the first panel looks into the mirror.
And.
The Chicken does not like what it see’s in the mirror.
Do you?
Really?
More on this tomorrow.
Hang in there with me… and you may be shocked what we each learn.
Trust me.
I have looked long and hard into some of these mirrors.
Recently, in fact.
Sometimes it is easy to get lost in those mirrors. A fun and scary place to be all at once.
And sometimes.
You need to get out.
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!
February 25, 2008
Hi everyone,
I received some feedback today that the second picture that Mark included in his posting yesterday was not showing up in some browsers.
Guess I was a little distracted last night, as the pilot was landing my plane over the Potomac River last night had to take a sharp bank to the right and I watched as the wing (which I was sitting over) actually graze the water and make waves. Yikes. Guess it is better to make waves then crash and burn into another airplane on the runway. Hmmm… Almost as profound as the posting from Mark last night (smile).
Aneeeeway… I updated his original posting this evening with a JPG version of the file; please let me know if that has fixed the problem for you.
For me, I am in a place that is freezing and am seeing that there will be some really cold white stuff headed here this weekend. At least (I hope) I am on the first flight out on Thursday morning (and back here Sunday night) so I will hopefully miss the mess.
Thanks for continuing to read and respond to these blog entries. I hope you are receiving some real value from what you read here.
- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com
![]() |
![]() |
Interested in becoming a Certified Scrum Master?
Come to my next workshop!
Some of you may be familiar with the term, “What happens in Vegas stays in Vegas….”
Well, tonight I am introducing a new guest writer to the blog, a guy I have worked with for almost the past three years on some major enterprise rollouts of Scrum and co-train with him on a pretty regular basis. His name is Mark Pushinsky and this “enlightenment” came to him a few years ago and we have been waiting on how to actually introduce this to the Scrum Community.
So… without further ado… here is his write-up on the topic (and thanks to Tony as usual for the cartoon!).
I may add something to it later this week (smile).
=================
I was on my way back from Vegas sitting on a plane, with a massive hangover…….and this thought occurred to me.
I know they say that, “What happens in Vegas stays in Vegas” but this occurred to me on the plane ride home and I am pretty sure we cleared Nevada airspace before it did so I feel compelled to share it.
Do you know about the “Cone of Uncertainty”? It is a phenomena that people in software use to describe the fact that when you start a project you have no idea when you’ll finish.
The longer the project goes and the closer you get to finishing the better/more accurate your estimate. Basically you are pretty sure your going to finish it the day before its done.


We have been trying to make it go away in software for many years. Fancy new estimation techniques, months and months of analysis, and brute force have not materially changed the fact that software projects are unpredictable!
Period!
Managers having been trying for decades to make it disappear/pretend it doesn’t exist/figure out how to make it turn from a cone into a cylinder.
Yet time and time again the uncertainty in projects remains.
The epiphany that occurred to me is that Agile or Scrum flips it around. This means that if you ask me what I can deliver in the next 2-4 weeks I am pretty accurate, if you ask me what I am going to deliver 3 months from now I have some uncertainty, but I can give you a reasonable guess, and if you ask me what I can deliver 6 months from now I have no idea…….

When we teach Estimation and Planning in class, we make a point of saying that Agile does not make the “Cone” disappear.
Nothing will!
We use light weight, proven techniques to make our best guess at long term plans.
We don’t pretend to know the end…….in fact we are pretty sure it will change……and we commit to be back in 2-4 weeks to tell you how its changed.
Then we focus on short term commitments, doing the right things, executing well, and delivering real business value.
I have found that after a couple of iterations of working that way we get customers focused more on prioritization, the next release, and getting impediments removed.
They begin to worry less about when the whole thing will be done.
I think the best way to end a project is to stop working on it before all of “The Requirements” have been implemented.
The 80/20 rule, right?
=================
So there goes.
Mark is an awesome person, trainer, and mentor by the way…. While our opinions do not match 100% I love the opportunity to provide an outlet for different opinions and thoughts (even if we are competitors and collaborators in the marketplace).
Let me know if you are interested in contributing in the future!
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!
February 18, 2008
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
And, it stresses the importance of an agile practice (not talked about directly in Scrum) called “pairing.”
This blog entry could take a dozen different tangents on this topic; however, I promise to try to stay on point about what I am trying to get across. Yes, O people who know Scrum… Scrum does not talk about “engineering practices” (this is by design).
So why am I even breaking out of the “World of Scrum” to talk about pairing? Because, my friend, Scrum must play in a big bad world of Software Development and well, people need to realize this.
So… what is pairing and why is it important?
I am going to tell you my definition from experience.
My idea of pairing is NOT having two people sit together for 8 (or more) hours a day at a computer banging away at code code code and not focusing on anything else. Nor does my definition of this include sitting by the computer together (as a pair… getting this??) for 3 hours a day joking around, surfing the Net, or playing online games. As cool as that may be to get paid for (and yes, some gamers who use Scrum in their development shop may have this opportunity and not even realize it!), neither of these two things describe pairing for me.
Here is an example we can use that is “outside” the Software Development world.
This site is developed using Scrum as a framework.
Do we do it perfectly? Nope.
Do we continue to strive to improve? Sure.
Now… please stick with me through this. There is a point. I promise.
Right now, remember… the site is developed and maintained by only two people (Myself and Tony). And, this is the process we go through to get you the comic strip and blog on a weekly basis:
Usually by Thursday evening, I get a rough idea about what I want to write about the following week (to be published on Monday evenings). I email the idea over to Tony. On Friday, Tony and I answer any clarifying questions about what we will try to get across… and by Saturday mornings Tony has a rough idea of the text and format of the panels in the comic to me. That’s usually the last we talk about anything until Monday afternoon when — pop — in comes the latest comic strip for the weekly blog. I’ll go back to my original outline for the idea (that I emailed him the previous week) and then — after the kids go to bed on Monday nights — I refine (as much as possible) the bog entry for the week.
Publish. Rinse. And Repeat.
I usually am totally shocked at the results. In a good way. And, most of the times, the comic strips that go along with this bog entry write-up take things to an extreme (with a lot of references to pop-culture and humor in ways I could never think about).
Over the time of working on this site together, Tony and I have come to a balance and understanding that he provides the [awesome] comics and I will provide the text and writings behind them.
This is an example of pairing.
Is it the classic example? Nope.
Does it cost me more than doing it alone? No.
Is the product better?
Does it work? You tell me (please!!!!).
Another interested fact on the idea of pairing.
Most people think you need to collocate in the same room and computer in order to do this. I will let you in on another secret, and think about this for teams that are not collocated today — Tony and I live in different states (not of confusion, but locations) and we have yet to meet face-to-face. If I passed him on the street, I would not even be able to say “hi” to him.
We will meet someday, I am sure. However, as with many Software Development projects these days, Scrum teams are using offshore resources on a more regular basis (I will not go into this topic on this entry, really!). The point here is that, in reality, we are all going to have to work with people we may never meet face-to-face. And it somehow needs to work.
Does this increase the chances of failure?
Absolutely.
Another factoid…. I had the idea for this site in early 2006. It took me almost eight months of speaking to my personal network of contacts — and then to networks of people and their networks — to “find” what both an artist and I considered a good fit.
Could I have launched the site earlier than September 11, 2006?
Sure.
Would it have had the same tone and impact it is having today?
No.
However, once we figured out that we could get started… we did.
And, weekly — come hell or high water — we deliver on a consistent basis. Sometimes the results vary widely.
As for Software Development projects using Scrum, realize that you are dealing with people — human beings (not Resources!) and you cannot do everything by yourself. And, with all the constraints that are out there for not getting things done or delivered…. remember that Scrum talks about the “Art of the Possible” and try to keep that in mind as you get mired down in your day-to-day work.
I hope the current blog entry was helpful to you. Share it with others, as I see happening quite a bit now (and thank you for that!). And hopefully you enjoyed this week’s guest artist!
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!
May 7, 2007







