Wow, the responses last week from my first “Random Thought Scrum Challenge” were awesome.

Thank you for all who participated. Let’s try another one for the week.

Same rules: You’ll have just about 24 hours to respond, so please post this on twitter and anywhere else (your own blog?) where you think interest may be around this one.

I’ll then post a synopsis of the results like I did for the first Scrum Challenge — Scrum Is…

So… this weeks Random Thought Scrum Challenge #2 is:

“An awesome Product Owner on a Scrum Team will…”

OK… finish that statement via Twitter (@mvizdos) or below in the comments.

Thank you!

- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com

Today is our first try at a new format (in addition to the cartoons) at www.implementingscrum.com.

It is called, “ImplementingScrum – UnScripted” and will feature audio and/or video in different formats along the way.  By the time this goes out, it should be out on youtube and here is a link to the “.mov” format (uses quicktime and is just under 17MB — for some reason this is MUCH clearer — any recommendations???).

Using FeedBurner, it should also find it’s way out to iTunes as a podcast… let’s see together how it all works and continue to inspect and adapt.

Fair? (smile)

This first version of this is with a guy “Down Under” who had some spectacular patience with me this morning (in addition to the fifteen hour time difference!).

His name is James Brett and he maintains a site at www.scrummaster.com.au and recently (with a LOT of help with the people there!) published a survey, where you can see the results at www.scrummaster.com.au/Article.mvc/Detail/43 or download the PDF file from www.scrummaster.com.au/Content/download/ScrumSurveyResultsJan09.pdf.

The video of this is about eight minutes long and goes into the survey a bit and introduces the topic.  It is not meant to be exhaustive — right now it is a test of the technology convergence(s) and as usual we want to keep these things short and to the point.

A few other references made in the video included a retrospective formats article and retrospective why.

You can also check out a few cartoons about retropectives on this site (there is a three part series here:

www.implementingscrum.com/2007/09/04/scary-team-retrospectives-part-one/

www.implementingscrum.com/2007/09/10/retrospectives-not-just-reading-a-book-part-two/

www.implementingscrum.com/2007/09/17/walk-into-the-light-retrospectives-part-3-of-3/

As usual, any errors anywhere on the video or my site — I accept that responsibility.

Take a look at the video and the links above for the survey and other stuff and PLEASE comment about it below.

Inspect and Adapt.

Let’s see where we go.

As usual!

Thank you.

- mike vizdos

www.implementingscrum.com
www.michaelvizdos.com

Thank you for continuing to follow and spread the word about this blog and our cartoons.

Get ready for a blast this coming year.

The last cartoon of 2008 covered the topic of how to handle questions from outside stakeholders during a Scrum (or iteration).

Remember that even familiar chickens can be dangerous to derailing an iteration.

Eek.

Does that sound too dogmatic?

Hmmm.

Let’s think.

Who calls an iteration “Done?”

That would be the Product Owner (look back at this old comic strip from the early days for a refresher on that).

And, the “old way” of doing this — in a waterfall environment — was to bow to the pressure.  That leads to very funny cult-movies; however, in reality it sucks for everyone involved.

Especially if you bow to it while using Scrum.

So.

If you are a Team Member on a Scrum team and you get asked to do something that is outside the Sprint Backlog, you’ve GOTTA turn it over to the Product Owner to deal with.

So, this comic strip shows that.

Our intrepid character Pig did the right thing.

And.

What is the Product Owner now supposed to do with this information?

This is not a blame game.

But.

Someone needs to be responsible for the decisions.

How does this sit with you?

And where does the ScrumMaster play in this situation?

Comments, as usual, are requested and will help guide where we take this in the future (smile).

Thank you,

- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com

For new subscriber via email, facebook, and twitter — Welcome and thanks for the interest in the site.

Please feel free to pass this site on to your friends and talk about it on twitter and other social networking sites.

The problem depicted in this cartoon is something I see a LOT when working with teams around the world.

Even when Scrum is being implemented on teams within an organization.

Hmmm.

So what do we do about this situation?

When asked for a status from a Chicken within a Sprint, Scrum talks about the team members not saying, “No” and punting it to the Product Owner.

The same goes for a new feature request.

In the past… before Scrum… this type of request was a major cause of never getting to “Done.”

This is the main reason to have a strong demarcation point between the Product Backlog and the Sprint Backlog.  The main reason is to help shield the team from the outside “Noise”.

Care to share some real life stories about this via comments below?

How do you do this without committing career suicide?

Who really is responsible for telling outside Chickens to speak with the Product Owner?

What does the Product Owner need to do with this next?

Is this really an important concept or what do you think about it?

Please share with us…

Thank you,

- mike vizdos

If you have any ideas please contact me and we can talk about exploring them via a comic strip or even you writing a guest blog entry!

Here is the scenario:

You are running a Scrum Team in an organization that contains a large contingent of Waterfall Projects and surviving somehow in a command-and-control environment.

Maybe you even have multiple teams running at this point.

You are following the “Combo Approach” of rolling this out, and you have support of the team and a person at the highest level within the organization, so that when impediments are hit they can be cleared if you ask.

All of the sudden, there is a reorganization.

The Chickens have moved around.

Your Scrum Team inherits some very new Chickens with little experience using Scrum and are pretty tight when it comes to command-and-control management styles.

One of the new Chickens walks into the Scrum Team room and asks for status reports to start up again. In writing using the template this Chicken has always used to get control of projects.

Starting today.

You look at this Chicken in amazement.

You ask, “Why?”

This project seems to be out of control in the view of this Chicken.

“We also need to start having daily one hour status meetings from everyone in this group… Fifteen minutes is not enough. I (The Chicken) will run the meeting and set the agenda. It may have to be two times a day.”

The Chicken wants a “all hands” meeting at the end of the day today for a few hours.

The Chicken is thinking about instituting mandatory sixty hour work weeks.

The words “Microsoft Project” are thrown around.

The Chicken also wants to put the teams back into offices because their stature in the company is high — the team members have all been with the company for a long time and want their own offices back (according to the Chicken).

The Chicken wants to have an all day post moderm to determine the root cause of the problems with this team because the boss of the Chicken wants the Chicken to be in charge.

So,

What do YOU do?

- As a Team Member?
- As a ScrumMaster?
- As a Product Owner?
- As “The Chicken”?

Comment on your responses.

Let’s get the conversation going!

Welcome back to yet another week at www.implementingscrum.com.

Thanks as usual for coming back this week and helping me spread the word about this site.

If you have some time today, please tell three or four of your friends about it, and let’s see if even more people can have fun with us.

Ask them to subscribe. Please. There are opportunities all over the site (please let me know if it is confusing in any way!). In fact, you can forward them this note and have them Subscribe to Implementing Scrum via Email!

Now… about “Fun.”

Yeah, I know, I know… we do serious work in the real world Mike….

I know.

I live it, as I hope you can tell.

So last week I wrote a few segments about Fantasy Island, and I really loved that comic strip.

One of the things listed was, “You may be on Fantasy Island” if you play Planning Poker without your Product Owner.

For a quick overview on an introduction to Planning Poker, please see this posting.

And come back! I am not going anywhere.

You back?

See. I told you I’d still be here. I am persistent that way (get it geeks of the world?!?! HA??? Ug… nevermind lol).

OK.

Ug.

WARNING: IF you have a very sensitive sense of humor (or none at all)… PLEASE STOP READING THIS POSTING.

My title tonight varied from, “How Planning Poker is like Unprotected Sex” to the one you see you actually displayed.

Guess it is at least a little more politically correct.

SO.

Um.

How can Planning Poker look like a one night stand?

Let me see if that can be answered sufficiently….

1) When you leave a Product Owner out of the process, you are at risk of waking up the next morning wanting to gnaw your left arm off. Clear?

OK.

Next one.

2) A Product Backlog does not have to be something that the Scrum Gods (aka Mr. Schwaber or others) think is perfect. Here is a fair question for you…. “Does it meet the needs of your customer?” If yes, all is good. If no, hire me (smile). Um. Dunno what that has to do with a one night stand (sorry).

3) Scrum Planning Poker without a Product Owner lands you in Fantasy Island. And. You cannot get off. Much like drinking and partying which can lead to the one night stand. You know, cannot get off the Island. And… never get to “Done.”

4) You cannot do any type of real release planning. Just like a one night stand, you may wind up with something you will have to live with for the rest of your life in about 10 months with not a clue it was coming (see my “Making Babies” post). Well, you saw it building and growing, but you have no idea what you are in for.

5) Hmmm…. I think the number one reason was the best (lol). Let me think. Oh…. this thing called “Group Think” may take place where everyone makes ASSumptions about the other. Can lead to going back to #1 in this list (smile).

6) Having a Product Owner there is like wearing a…. hmmm… do I dare say it? Nope. Use your imagination if you can. And. If it is missing it may feel fine but your team can wind up catching something that is hard to get rid of – or even cause your team to die.

7) And I guess my final word of advice… If you find yourself out during that “last call” and someone has that “five beer” look… GO HOME ALONE. This can be paralleled to playing Planning Poker without a Product Owner. If the Product Owner is not there… CANCEL THE MEETING.

Wow.

Was that the most inuendo-filled-posting I have ever posted? I think the most inuendo-filled-COMIC-STRIP was the one on CSM Training. Strange how that is the most downloaded comic strip on the site (smile).

Hehe… It was a little fun.

Now… back to the work thing.

And remember your PRODUCT OWNER!

If you or your friends [or enemies] have not signed up for FREE updates to this blog, please Subscribe to Implementing Scrum via Email!

Gotta run! Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

OK.

So what was I talking about a few nights ago with the cartoon posting above?

It really truly is not politically correct.

In no sense of any being.

But.

It is HIlarious to me.

Because it can help me make a point.

Actually tonight, eight points.

Eight Points.

Just for you.

How is that for a Thursday night or Friday morning?

Hmm.

Think about it this way.

You are arriving on “Fantasy Island” if you think…

1) You can stock the Product Backlog without a Product Owner present during Planning Poker

2) The definition of “Done” is not important to anyone

3) BurnDown Charts are useless, actually more useless of tracking tasks

4) The CSM Workshop is a waste of your time

5) You can pronounce the last name for

Ricardo

(c’mon Fantasy Island Buffs (or OK… is there even a “buff” reading this?))

6) Documentation is not needed on any agile projects

7) Scrum is a Silver Bullet

You can get a date with the “Hot” ScrumMaster replacement (smile) or Jessica Alba or with some hot babe with her Bottom Up.

9) This cartoon is about SCUBA Diving [strangely enough this is one of the most downloaded cartoon on this site)

…. OK.

Enough for now.

Man.

I can go on for a while.

But I think you get the picture.

What have I missed?

Now….

Do you see where you can spend a lot of time on Fantasy Island?

Do you want to leave it?

Really?

Why?

Gotta run! Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

OK.

This week may be the week that actually dates people reading this blog.

Tattoo. Not Toto.

Scary.

But true.

Admittedly I have had grey hair for a while (that is one of the reasons I keep it short short lol) and I know I am one of those people “in between” on the high and low-age readership of this group. Next year will be 20 years in the industry for me, so I do have some real life experience. And for you, a lot of this life is lived working with clients on Scrum Projects around the world.

And.

This may be one of my favorite cartoons Tony has done to date. This has been one that has been brewing and talked about for over a year with clients and class participants.

And as usual, Tony nailed it (got it right for the non-Americans — this is a good thing (smile)).

Maybe for tonight I just leave you with the cartoon.

An give you a little more about it as the week progresses.

I am on the road.

And wow do I have some ideas and opinions on this one.

See where this one cartoon strip can lead you?

First… see if you get the context of it!

Here is the cheater link if you have no clue (and THAT is OK!).

Please read part two here

Gotta run Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

Welcome back to yet another week at www.implementingscrum.com.

Wahoo. We made it another week and did not wind up six feet under or having our ashes spread in some remote location of the world. In other words… yipee… we all made it another week to see another great cartoon and continue learning.

OK… so the title of this one is a little twisted. OK. A lot twisted. I guess I should have named it “The ScrumMaster Guide to Picking Up Filing Cabinets” but then who would really want to read about that?

This week I am writing about something that all people playing the role of ScrumMaster must be aware of.

Actually, I’d consider it important for the ScrumMaster on a team to help show the Team Members and Product Owner — through example — what to do when you are in over your head and really need help.

How many times have you been in a situation where you felt like you had to “wing it” or “fake” an answer?

We have learned that as a Product Owner, that can have dire consequences for the team.

Instead of “faking it” or “winging it” or “making up an answer” the Product Owner should feel safe enough to say to the team, “I do not know, but I will find out and get back to you in the agreed upon time.”

And then do that.

Guess what following through on promises helps build?

Trust.

Really.

The agreed upon time should be something that is ummm…. agreed upon by the team — maybe as one of the team norms that are posted on the wall of your team room.

You have those, don’t you?

Right next to the Burndown Chart and team Definition of Done, right (smile)?

So what can the ScrumMaster do to help show the team that they do not know everything (really… we do not!) and sometimes we need to bring in outside help.

Think about Retrospectives.

And.

What if the ScrumMaster is part of the problem in the current system?

You know the answer.

Get help.

Really.

Ask someone else to facilitate the Retrospective.

I have written about this in the past, but have been recently reminded how important this is for all roles of the Scrum Team.

Wow.

Something as simple as asking for help.

That simple.

But.

It does not get performed enough.

As a ScrumMaster, how can you make some simple changes on a daily basis to show the team how to become the best they possibly can?

Remember that the implementation of Scrum should sometimes be taken in small baby steps.

Which small baby step can you take today?

Please share them with us in the comments or on the forum.

Gotta run!.Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

I am announcing another test (remember — inspect and adapt) on our site at implementingscrum.com.

Know what a Product Backlog is?

I am opening the Product Backlog to you — the reader — for input.

Is it the perfect tool for this? Maybe not.

However.

Let’s see if we can get some things started on here.

You can read more about it (see the product backlog and be able to enter your ideas into the product backlog) here.

Thank you.

- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com

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 Scrum Community to discuss this entry and other Scrum topics. Thank you!

OK.

I surrender.

Please.

Let’s stop the misquotes and fires about the virus-like position that has been taken by multiple people I quoted and see if we can come up with an answer that makes sense for all of us.

Especially you — the reader.

If you recall… two nights ago I presented a comic strip and blog entry about something I had seen over the weekend.

Wow.

I did not even come close to expecting the traffic and responses related to that one.

The first response (of many) came in yesterday morning:

Hi Mike,

I didn’t see Jason’s post, but as a preacher’s kid (make that double preacher’s kid) and ScrumMaster (woof), I would take Jason’s comments as a complement. I DO think you are like a preacher – but like you said – not preachy, more like a spiritual leader. Scrum and spirituality are very much linked in my mind because of the emphasis on continuous improvement.

As Ghandi said – “Be the change you want in the world.” I believe that you do that by helping people question their beliefs, behaviors and discuss them. Like you, my pastor does not us what to think or how to think it, but ask those probing questions to help us come to our own core values. I find this to be generally true in the UCC – United Church of Christ.

Anyway – I read your site religiously (ha ha). I use your cartoons to prompt discussion and to keep the humor in the air when things get hard. Please continue to post.

Thanks,
Christy Zuzelo

Ohhhhhhhh K. Um….. Daughter of two preachers kids? Yikes. I will not even delve into THAT topic here (smile) but I am sure Christy is a well-adjusted adult who loves my comics.

[Christy thank you for the note -- yours was one of many I wanted to post up here as a follow-up!]

So then,

Out of the blue I see this posting. Ashwin has been a great supporter (albeit it quiet up to his posting!) as most of you are.

Really?

You?

Quiet on this topic?

Why?

Plenty of others are joining into the fray..

HL Arlidge here.

And then someone named Ashwin (another long time reader of the blog) posts this entry.

Wow.

Jason Gorman got the guts (this is an Americanism) to put up his original posting with the cartoon, located here.

Phew. I do not need to post it here! I have permission to do so by the way… but go to his site to see what is happening!

Arlin fired more back here.

And then Jason more here.

Following all of this?

Wow.

Will it continue?

Probably.

is this a good thing?

What do you think? Post a comment or on your blog and let me know!

I do understand that getting stuff like this is important to everyone inside — and “outside” the Agile Software Development Community.

And, for the record, check out my posting on “ScrumMaster and Snake Oil.” A fun read. Or at least I think so.

Thank you.

- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com

PS — I may have missed something here. But please post comments to this posting at the end!

Gotta run….Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

The posting from yesterday seems to have started some additional conversations today.

And people are taking a stand.

More tomorrow as I see where it leads… and will send you an update on the fun conversations happening around this topic.

Thank you!

- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com

Gotta run….Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

Welcome back to a new day at www.implementingscrum.com.

So this past week I have watched Scrum be called a lot of names and publicly flogged for some of it’s practices.

Um.

People.

Get over it.

Please.

Remember, Scrum helps people, teams, and organizations transform their business to be the best it can be.

Are there other things out there that can make that claim?

Absolutely.

However (you knew one was on the way!)….

Scrum works in a lot of different environments.

This is from personal experience. With teams working and using Scrum around the world.

Then I see this blog entry by a guy named Jason Gorman (a great chap from the UK); the title of the entry was, “How Scrum Spreads – The Scrum Viral Life Cycle.”

I thought, wow, that is an interesting way of looking at things, and sent him a note to let him know I liked the article (maybe not agree with everything there) and then asked him to come to my site to check it out.

Oye.

At it he came. The posting where he replied is currently down, because it seems like some people were offended by what he wrote. So, I will summarize (from my recollection) of what he said about this blog (www.implementingscrum.com) in his blog:

[This struck me, but wow.... the parallels he made were pretty good from my perspective -- I did not even realize I was doing this]

This is from my vantage point and memory…

He created a little cartoon with some religious overtones (this is what I think ticked off some of his readers). I thought it was kinda cute. Not our style in the least; however, any time I see someone attempting to create a cartoon on any agile topic I usually get a good laugh (as long as I am not drawing them). The blog entry talked about how I write my blog in a way a lot of preachers talk at the pulpit.

I do not see me as a preachy sort of person. Heck, I laugh when I see some of those late night Church Folks (anyone remember the Church Lady from Saturday Night Live??).

Annneeeway…. over the weekend Jason took down the postings because he did not want to offend anyone on his site.

Two words to his reader:

“Lighten Up.”

This blog is meant to poke fun at what a lot of us actually do for a living. It is pretty edgy sometimes — on purpose — and tries to get its readers into a mindset where maybe — and this is a big maybe — they will question the way they are working today and see if it makes sense to try something new.

So.

I will close this blog entry with an invitation to Jason to re-post his original entry over the weekend over on our site here. I will post it un-edited and may comment on it after that is posted here. I’ll take any “heat” from the community, and want to really find out if this really is a problem within the Agile Community.

And if it is…. why is that?

So.

This could be a total dud.

Or a great way to open up some discussions with the readers of this blog and many others in the Agile Software Development Space.

[Updated February 6, 2008 -- More Here!]

Gotta run!.Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

After leaving town on Sunday late afternoon I arrive in Atlanta (yeah… it was not a hub for me… an actual destination!) and hopped on the MARTA (their train system) to one of the outward bound stations; I arrived around 9:00 PM. Spent the night in a decent Holiday Inn Express (non-smoking, thank you!) and got started at 7:00 AM to head to the training center via the hotel shuttle.

The first class this week was geared toward, “Agile Project Management” and about 14 people had signed up. We had 8 show up.

So.

Eight it would be.

This course talks a lot of Agile from a much different perspective than just “Scrum” — which of course I normally teach to certify new ScrumMasters.

It was a great two day course that I facilitated discussions about topics such as the origins of Agile, Agile Project Management basics, Lean and Agile, XP, Scrum, and a few other topics. As with most of the courses I teach, the feedback was great (OK… so the projector at this site sucked but I could do nothing about it turning black text into blue text).

One good story that came out of this that I feel like sharing includes a story from a company that is implementing XP (Extreme Programming... remember… the Agile Practice that actually talks about engineering practices — Scrum does not by design!). This is not a Fortune 50 company; instead, it is a company that is looking at revenue (religiously??!!) and had brought in Scrum.

What is happening in their shop?

Hmmm…. Something I did not expect.

See. The development team was/is using a modified version of Scrum and XP; and they are blowing away the quality standards that have been measured in the past (however that was).

And.

People starting seeing that the customer was astounded.

That’s a great thing, right?

Uh.

Not really.

Why?

Well…. the company using this modified version of Scrum and XP became so good at producing software without defects that….

… take a breath please….

…. the support team in operations had nothing to do.

The customers had nothing to report as not working.

Fabulous some people would think.

Including me!

But.

The majority of this organizations revenue comes from support and maintenance contracts.

Uh.

See the problem?

Do you?

Really?

And this was from bringing in Agile / Scrum / XP.

Interesting learnings.

I will cover our Richmond CSM class tomorrow.

It was awesome and I did some co-teaching with a non-CST (Certified Scrum Trainers) who should soon be a trainer. Tomorrow I will tell you more about co-teaching with another instructor and why I feel this is something everyone should try.

And try again.

And again.

Again.

I got home from Atlanta at about midnight so I could prepare the for the next days of classes — a CSM class in my home base of Richmond, Virginia. More on the tomorrow. Gotta keep you in some suspense. Or whatever we call that in geek-speak blog worlds.

Have an incredible Friday!

I will be putting in cabinets into the kitchen with my wife. For all those who have taken the course, I’d rate that a 20+ for story points (smile). Hope you understand that reference!

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!

I hope this posting challenges some of your current thinking. If it does, please share it with others in your organization. It can be a great conversation starter (like a lot of the postings on this site!). If it does not challenge your current thinking or beliefs… think about why that is so.

Ready?

There is a saying I’ve heard in the past that goes something like this:

“The farther away people get from the money, the less they live in reality.”

Think about this for a minute. I’ll wait (smile).

In most organizations I work with — no matter what the “size” — there always seems to be a divide (sometimes a chasm) between the “Business” versus the “IT” side of the house. This includes government clients and both for-profit and non-profit organizations.

Huh?

When people in the outside world hear about this “divide” in an organization, eyes glaze over when I try to explain this.

Really. They don’t care.

They are consumers.

They buy your product or service.

That’s all.

If you are a Developer (this includes all the various roles like architect, tester, coder, and other names like that) let me ask you a serious question:

“When was the last time you picked up an industry trade rag or read a “real” business magazine or newspaper?”

The trade rags exist for every business domain out there.

Really. I have worked in many industries and there is at least one specific to your business no matter what you do.

This is scary but true.

I am not talking about technical journals (well… keep reading those AND start looking at the business perspective).

I am also not talking about Playboy (although they do have great articles and cool gadget reviews).

Think about resources like The Wall Street Journal, Business Week, Fortune, Forbes, and others.

Why should Developers care about keeping in touch with what is happening in the business world?

Think about the statement I made above… About “Customers”…

“They don’t care. They are consumers. They buy your product or service.”

What does this mean?

Think.

Again.

Please.

Who are your Customers?

Most Developers I speak with about this answer, “The Business Side” of the organization (for example, Business Analysts or Sales or Support or some muckity-muck Vice President or other bigwig).

Uh.

No.

Your Customer in your organization is the person that pays for the ultimate product or service your organization sells.

What?

Think about something simple, like umm…. Sugar. As a product.

[Side note: I have actually worked with a major company that produces sugar and now know more than I need to know about what they actually do to make and deliver it!].

There is a ton of stuff (from an IT and Manufacturing perspective) that goes into getting that five pound bag of sweetness into your pantry at home.

The people (Customers) who use the sugar want it for something specific… to make things sweet.

Do they even care — or even think — about what went into getting that sugar there?

Here is an answer that is tough for IT and Business people to swallow, but I am going to say it.

Probably not.

I may even go as far to say, “They do not care.”

They paid for a five pound bag of sugar and moved on with their life.

When they need more, they will get it from a neighbor or go to the store and get more. They consume it.

And are willing to pay for it.

Wow.

This means your Customer is actually someone who has to part with their cash and put it into the organization bank account.

This is not…

… a budgetary or imaginary number.

… some mystical “divisional spend” you may receive.

… a VP or some higher up.

Think of it this way.

The customer could actually be YOU.

What if you looked at whatever you do to actually add value from the Customer perspective?

Would that change the way you work today (or tomorrow or the next day, week, or month)?

So.

Why am I harping on getting out there and doing some reading about what is happening in your industry — or the business world — in general?

Why do you think?

Gotta run!.Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

I am sorry I was unable to write about this topic further last evening. Life happens and I thank you for staying with us.

You know how some days you just know things will not come out sounding correct? Last night I had one of those feelings.

So. I stopped.

Until tonight.

Without further ado….

I am blogging about Social Networking Sites.

Now…. before you think you hear crickets singing in the trees from the dead silence you may think this topic deserves…. please hold on and let me explain. There is actually a reason for using Social Networking Sites when you are on Scrum Teams.

Can you think of some off the top of your head?

Seriously.

Think of the possibilities!

Got some? Write them down, as that list — I hope — will motivate you to sign-up or become more active in some of the sites I mention this evening.

Trust me. I know there are a ton of Social Networking sites out there (heck, I am working with a few clients who are developing their own portals for niche markets today!).

I’d like to talk about the main Social Networking sites I am using today, along with “why” I am using them, and for how long. Will it be an exhaustive list?

No.

Do they work for me?

Yes. In different ways.

And.

In an Agile fashion, if it is delivering the results you expect, maybe that is “good enough” for now.

Will these change in the future?

Of course.

So.

Here is a snapshot of a few “Social Networking Sites” I use today (along with my links to them) with the main reasons why I use them.

I use three main Social Networking Sites today.

They include the following:

1. Plaxo
2. LinkedIn
3. FaceBook
4. Twitter.

I use Plaxo to keep my address book on my computer and iPhone up-to-date.

Why is this important?

I see a lot of people move around quite a bit — both personally and from company-to-company. As people become members of Plaxo, it keeps me up-to-date. If I have a business relationship with a person who moves from Company A to Company B, at least I am aware of it. As people then move from Company B to Company X, I know about it and stay informed.

From a Business standpoint, I find this information valuable so I can keep in contact.

Or at least try.

Which brings me to the next one I use, LinkedIn. I have been a member of that service since the product was in Beta many years ago. My personal network has over 500 people (who I have worked with in the past!) and the way this works is to “link you” to other people’s connections — out to what they call “degrees.” From spending the time using this tool, I am approaching almost 4 MILLION other people I can actually contact through the connections my direct contacts with me have.

My link to this profile is just below on the button.

This has been a powerful tool for me at the business level both for introductions to others — and making connections for people that I know and trust. Also, this is a place where people can find out more about me at a professional level, and even feel free to leave (or read) comments from people I have worked with in the past. It is something that I also use when talking to new people I meet and may want to do business with.

At the personal level, I got pulled into 2008 with FaceBook. OK… so this is what I thought would be a totally “personal” kind of site. It turns out that a lot of my contacts from the two services listed above also use FaceBook… and I am learning more about them too.

My “profile information” can bee seen in the little signature thingee below.

Are there other Social Networking sites out there?

Yes.

Will I join them.

Maybe.

I do think as the “open standards” (where the different Social Networking Sites start “talking” to each other and “sharing” information) come about in this space, it will be a lot easier for people to become even more involved.

If they want.

I have personally not hopped on the Twitter bandwagon yet, since I really do not think people need to know everything I am doing every second of every day. Um. I don’t even want to remember that sometimes LOL.

OK. I am now on Twitter. Follow me! Man, how hip am I now!?!?!?

What does this all have to do with Scrum?

Remember.

Scrum deals with what?

People.

Not technology. There are plenty of other Agile Software Development techniques out there for that.

People.

People.

People.

Are you beginning to see how there may actually be a connection to these Social Networking sites and Scrum?

Do some thinking about it.

And get out there and do some personal and professional networking.

It is a small world.

Trust me. I travel it regularly (smile).

Gotta run!.Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

As I wrote about yesterday, this is probably the last comic strip of 2007. Tony and I hope you enjoy it and learn from it; this is a question that comes up pretty regularly from both the readers of this blog and at client sites I visit around the world.

[Full Disclosure ON]

I have been working with Scott in one capacity or another since September 11, 2001. Scott is one of my many mentors (he is also one of my most outspoken mentors) within the agile community. While everyone may not agree with him, he has (co)-written almost twenty books on various agile topics (one was with me!) and a lot of my learning style can be seen by his acts. For that I thank him sincerely — and often.

[Full Disclosure OFF]

This is what has been posted publicly by Scott Ambler:

My December 2007 print column entitled “Scaling On-Site Customer” is now online at http://www.ddj.com/architect/204801134. It examines the challenges surrounding having a stakeholder(s) actively involved with an agile project in the role of an on-site customer or product owner. This role is hard enough for simple projects, but at scale it becomes extremely difficult. The article provides
advice from Agile Modeling for how to augment this role and address the challenges associated with it.

I’ve also blogged about this topic at http://www.ibm.com/developerworks/blogs/page/ambler?entry=agile_stakeholders_at_scale.

- Scott

Scott W. Ambler
Practice Leader Agile Development, IBM Methods Group

http://www-306.ibm.com/software/rational/bios/ambler.html

Agility at Scale: http://www.ibm.com/rational/agile/

To read the DDJ article, you will probably have to register as a user — and they seem pretty good about not spamming you. Scott will not spam you from his other sites mentioned.

Will you agree with everything he has written?

Probably not.

Is he OK with that?

Sure.

He totally understands that people will not always agree with him.

And.

This is something I have learned from him.

It has come in handy over the years.

Gotta run!.Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

Please note:

Tomorrow will most likely be the last comic strip for the end of 2007. Tony (our artist!) is planning on taking a two week hiatus between now and the new year. This is good stuff and shows he works on having a life (something we talk about a lot on here). While he is gone, I may do a little refactoring on the site and add some additional material and ideas.

If you have any ideas about the content for the remainder of this year, please contact me anytime and we can chat, email, or meet face-to-face.

I have a lot of great plans to be unveiled for 2008.

For those of you who are “stuck” doing the work thing over the upcoming holidays — spend some time surfing the net — specifically at this site and learn more about your craft and how to get better at it. Find something you like? Pass it on to your friends (they do not even need to be geeks!).

So… Tomorrow we will introduce the last comic strip of 2007.

Hope you enjoy it!

Gotta run�.Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

I had an interesting question posed on a forum I regularly monitor and respond; I thought it would be interesting to share the response here for the readers who sometimes do not see that I also write in other areas (smile). The entire thread can be found here.

=====

The thread began along the lines of, “How do you measure success from the Customer point of view.”

The first answer I gave did not go over well…

“How about asking the customer?”

A lot of people jumped in on this one. Many people came up with similar answers.

Then, I answered one of the replies along the lines of:

“>>I have a strong desire to make sure that whatever project I work on the customer defines success.

This is an interesting thought. Can you explain that with an example? Have you tried it before?”

This was my reply:

Hi,

Every once in a while I will throw out a statement like that just to see if people are reading my replies (smile).

Let me address your second question first, “Have you tried it before?”

Yes. I have. In fact, after doing this for a while now I will not go into a team or organization without that being defined up front and in clear English (or whatever the local language — as long as I understand it AND the customer understands it!). When I first started doing software development (even before “agile and Scrum”), I tended to not ask this question and just make a lot of assumptions about what the customer wanted. This usually got both me and the customer (if there was indeed a customer) feeling frustrated.

Example(s).

I have many, so here are a few that stick out in my mind (especially at close to three AM and I am up with insomnia)…

Example #1
—————-

The first one I just talked about on Friday with a colleague of mine where we worked on a project that is still talked about today as one of the “best” agile projects people have worked on at their organization. One of the reasons it was a success — from both the minds of the customer and the development team (which includes all the roles) was that we had an engaged Product Owner and we took the time at the beginning of each Sprint to define what “done” looked like for that individual Sprint.

Were we expected to deliver something into production each iteration (or Sprint)? No. Actually, our “first” definition of done could be considered pretty week from people “outside” the team; it was something like, “We will deliver a piece of working code.”

We did this the first Sprint. And wow. The customer was blown away. The development team got focused on delivering working software (instead of traditional waterfall artifacts — some of which have nothing to do with working code).

Did the definition of “done” evolve? Yes.

Example #2
—————–

I was asked to come into a uuber-architecture project that had been “drifting” for years. One of the reasons this was happening was there was a group (a large technical group, by the way) pushing through this large change throughout the enterprise. It seemed like everyone had a line item in their budgets to “donate” to this project (I am joking about the donation — it was a sunk cost almost every project was paying for). When I cam in, customer satisfaction was low.

I wondered why and started going out and asking the people that were paying for the projects. Ummm… I got some surprising answers. Many of them included, “Um, I am not going to use that thing” to, “Mike, it is something I inherited after the last round of reorganizations.” It was almost silly. It took me a while to find a “real” customer for this project. And oh, I found one, and asked them to be committed to the team. We (the team, the product owner, and me (playing the role of ScrumMaster on this team)) burned through three product owners in multiple iterations (or Sprints) to be able to get to the “right” one.

In the end, I think the project got killed. And, it was a good decision for the organization. Why?

And this is important to realize — if you are using Scrum and cannot identify an engaged Product Owner… do not do Scrum.

There. I said it (and have in the past).

If the customer (or Product Owner) cannot define success for the team (or to themselves)… do something different.

Hope these examples help!

More information about the topics above can be found at:

Transparency

http://www.implementingscrum.com/blog/2006/10/16/transparency-and-jessica-alba-a-scrum-connection/

http://www.implementingscrum.com/cartoons/cartoons_files/2006-11-30-Transparency.html

“Done”

http://www.implementingscrum.com/blog/2006/11/27/done-really/

Product Owner

http://www.implementingscrum.com/blog/2007/06/04/whos-your-product-owner/

http://www.implementingscrum.com/blog/2006/10/30/shock-treatment-for-your-product-owner/

Silver Bullet

http://www.implementingscrum.com/blog/2006/09/25/scrum-the-silver-bullet-not/

Thank you,

- Mike Vizdos
www.implementingscrum.com
www.michaelvizdos.com

Gotta run�.Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

Originally Published:
December 16, 2007

]]> http://www.implementingscrum.com/2007/12/16/interesting-question-asked-outside/feed/ 1 http://www.implementingscrum.com/2007/11/28/implementingscrum-forum-done/ http://www.implementingscrum.com/2007/11/28/implementingscrum-forum-done/#comments Thu, 29 Nov 2007 02:47:05 +0000 mvizdos http://www.implementingscrum.com/blog/2007/11/28/implementingscrum-forum-done/ Hi,

Thanks for continuing to read the series this week about the ImplementingScrum Forum and the entries I’d like to highlight for you. Hopefully also you take the time to register as a member – it is FREE and I do not sell or rent your name or email address to anyone!

Good day.

The topic today is “Done” and what that means on a Scrum Team.

For those of you practicing Scrum today, think about how important this is.

For those of you who are not yet practicing Scrum today, remember when you start that it is a very important topic to discuss with each of your Scrum Teams.

Today we continue examining some of the postings and related comments at www.implementingscrum.com and the forum.

This entry is going to ask you to look at the topic, “Developer Done, or all done?“. Go ahead and take a look at it.

Any new ideas or comments you’d like to add to this topic?

You may also want to check out the following blog postings and comments related to this:

Done. Really?
Who’s Your Product Owner?
Welcome to Oz.

Thanks for continuing to read this — or welcome new people reading and subscribing to this forum!

- mike vizdos

Have a great day and thank you for your time.

- mike vizdos
www.implementingscrum.com
www.michaelvizdos.com

PS –> Want to join the Forum? Click here!

]]> http://www.implementingscrum.com/2007/11/28/implementingscrum-forum-done/feed/ 1 http://www.implementingscrum.com/2007/06/11/ya-got-to-know-when-to-fold-em/ http://www.implementingscrum.com/2007/06/11/ya-got-to-know-when-to-fold-em/#comments Tue, 12 Jun 2007 01:25:16 +0000 mvizdos http://www.implementingscrum.com/blog/2007/06/11/ya-got-to-know-when-to-fold-em/ ]]>

---

Welcome back to another week at www.implementingscrum.com.

This week Tony (the artist) and I take a fun poke at the world of “professional” poker players. They seem to have their following, and wow is the money big.

Personally I find watching paint dry on my walls — or grass grow in my yard — more interesting than watching someone else win at poker, but hey, this proves there is something for everyone!

So what is my point with using Poker Players tonight in my comic strip?

Two words you should become familiar with:

Planning Poker.

There is a lot of great stuff written about this on the web and in books already today.

The first place I’d recommend stopping by is Mike Cohn’s sites (www.mountaingoatsoftware.com and www.planningpoker.com) and a gentleman named Henrik Kniberg posted something recently at www.crisp.se/planningpoker/

Now.

Regular readers may recall that I am not a big “tool user” or “proponent” of tools for implementing Scrum. This is one area where I take exception. There’s one in every crowd now, isn’t there (smile).

Why?

Please. First, go read the links that I have given you above. Come back.

Back?

Now… did you read the Divinci Code? One of the cool things brought out in that book was something called the Fibonacci Sequence. Check it out // google it if you do not understand it. Basically it takes the number before and adds it up to the next number, to look something like this:

0, 1, 1, 2, 3, 5, 8, 13, 21 etc…. (or something pretty darn similar!). The key here is that the numbers go start going up pretty quickly.

You can use these numbers to help do something called “relative estimating” when coming up with your Product Backlog. Remember the difference between the Product Backlog (constantly changing) and the Sprint Backlog (the work the team has pulled off the Product Backlog to work on during this iteration!).

Use Planning Poker to help come up with relative estimates for the size of your Product Backlog.

It can tell you some sobering things about what it is you are working on.

Remember, with Scrum (in this blog entry at least), the goal is for a team to produce working software. And, it would be awesome if the team could do this in iterations that continually build upon the past iterations and bring money / customers into your business to help pay for even more development efforts.

The rules are out on the various links I have provided, and they are pretty straight forward.

Read them. More. Really. I can wait.

Now….

Here are some ideas I find useful when playing Planning Poker.

First. Make sure the Product Owner is there. If the Product Owner is not present, skip this exercise. Guess what… doing this exercise without the Product Owner can bring back memories of how some of us used to try and develop software… by making assumptions for the Product Owner or customer. This can be bad. So do not proceed without one present.

Really.

Next.

Time box this exercise. When it says one or two minutes per topic, stick to that timeframe. Really. Otherwise you get into analysis paralysis and start going down possible political mind fields or rat holes you have no interest in jumping into.

Next.

Finish it in one sitting. Trust me.

Next.

Do not. Do not. Do not hold one “user story” as the “gold standard” of cards. Remember this is relative estimating. And um…. estimating is used as the world for this because well, that is what it is (smile).

Next.

If some of the team votes a 5 on a story while others vote an 8, make a team norm that says go with the higher or lower number and just move on. Statistics has proven (thankfully) that in the grand scheme of this thing we call estimating…. guess what…. sometimes a 5 takes as long as an 8 and wow, sometimes an 8 takes as short as a 5. In the end, it evens out.

Next.

Do not panic when you add up your numbers and it looks like hell will freeze over before this project will ever get done.

Guess what.

It is what it is my friend. You are sharing data that was not there in the past.

Does this mean go out and try to screw with the iron triangle? NOPE.

Does this mean you’ve got to get better tracking your Burndown Chart? Possibly?

Does this mean you’ve gotta start having some tough conversations?

Most likely.

As strange as this “game” may look to outsiders, I have personally used this technique with multiple teams around the world with a ton of success.

Is it easy to do?

Who said it should be easy?

Remember as a ScrumMaster or even as a member of a Scrum Team, Scrum exposes though things sometimes. You have to deal with them and not hide from them.

Move on.

And develop working software.

By the way… when you do not follow some of the simple advice I give in this blog entry, feel free to contact me to come in and help with it; I am amazed that people actually pay me to come in and help “fix” some of these types of problems. Don’t get me wrong… I love what I do and enjoy the fact that I can make a living working with teams that truly are interested in what I can offer to help (thank you to all my current and future clients!).

Gotta run….

Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

Originally Published:
June 11, 2007

]]> http://www.implementingscrum.com/2007/06/11/ya-got-to-know-when-to-fold-em/feed/ 2 http://www.implementingscrum.com/2007/06/04/whos-your-product-owner/ http://www.implementingscrum.com/2007/06/04/whos-your-product-owner/#comments Mon, 04 Jun 2007 20:08:30 +0000 mvizdos http://www.implementingscrum.com/blog/2007/06/04/whos-your-product-owner/ ]]>

---

Welcome back to another week at www.implementingscrum.com.

Everyone take a sigh and a breather. Sometimes I think you need it. I do.

A few years ago, when I was still starting out using Scrum, I got this idea that Scrum could be used outside of the IT world. And even the “business” world.

So I posted this. And it has generated a lot of comments and thoughts over the years. People have even organized weddings using this technique.

I tried to implement it at home. So have others.

Over the years, we have been able to do this with some sort of success.

Is it totally Scrum?

Nope.

Can I still talk about it?

Sure. And I hope even one of you walks away with an idea or two about how (or how not) to implement this at home.

Go out an buy yourself a white board, some markers, and some index cards. If you want to go really gung-ho, get those large wall-sized sticky-note-pads.

Start your Product Backlog.

Could be like the cartoon… but I am sure there are other things that need to get done.

Remember.

This Product Backlog continues to evolve and change. Anyone can have input into it.

Anyone.

Now. Also remember….

There is one Product Owner.

Only one.

Really.

Your Product Owner is responsible for prioritizing this list before each meeting. We wind up now calling them “family meetings” to keep it non-IT centric.

Our Sprints are supposed to be week-long. They do not work out that way in reality. And, we have a tough time with the demarcation between the Product Backlog and the Sprint Backlog.

Reality sucks some times, eh?

Deal with it and move on. This is your family… not a company (smile).

Talk about the Sprint Goal and what User Stories (don’t jump right to the tasks!) need to be done. THEN define the tasks and have family members help figure this out.

You can assign story points and hours.

You can track your progress via a burn down chart.

You can then have your Sprint Review.

And a Retrospective.

It can be fun.

And…. stuff actually can get done.

Like at work when Scrum is working “right”.

So.

This is great. Right?

Maybe you are implementing Scrum today at work. Maybe you got a good laugh about the idea of running Scrum outside of Work.

But.

Think about the world outside of IT.

Your business.

You know, the thing that creates customers who pay your salary?

What can you start doing differently using Scrum today?

Heh.

Gotta run….

Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

Originally Published:
June 4, 2007

]]> http://www.implementingscrum.com/2007/06/04/whos-your-product-owner/feed/ 1 http://www.implementingscrum.com/2007/04/23/the-cast-of-implementingscrum-infamous-yet/ http://www.implementingscrum.com/2007/04/23/the-cast-of-implementingscrum-infamous-yet/#comments Mon, 23 Apr 2007 20:45:41 +0000 mvizdos http://www.implementingscrum.com/blog/2007/04/23/the-cast-of-implementingscrum-infamous-yet/

---

Welcome back to another week at www.implementingscrum.com.So I have been meaning to get to this for some time (it has been on my Product Backlog [smile]), and we had an Abnormal Sprint Termination this past week because of some things that came up in both of our lives (Tony, the illustrator, and Mike Vizdos (me), the author of this blog).

Without further ado, I present to you the cast and characters of the site www.implementingscrum.com. Think I missed something or need things to be added? Please let me know!

Otherwise, please enjoy and drive responsibly….



ScrumMaster

Our intrepid ScrumMaster is very passionate about his work. Scrum is not just “work” to him — it is a way of life. While gentle and thoughtful most of the time, he has his moments and gets on his soap-box every once in a while. In life outside of being a trainer, he has a wife and family, a dog, and 3.14784845 other various pets (on average). He also is a Certified Scrum Trainer and loves traveling the world spreading his larger mistakes (which, by the way, sometimes teach you the most). He is very introverted and an ex-command-and-control-a-holic.



Chicken

This is your typical stakeholder. If there is such a thing. Others may see the Chicken as their manager (we may add a character to the cast in the future if the Chicken Role needs a specific stand-in). Either way, Chicken does really try to “get it” and is continually looking to learn to improve. And, most of the time, the Chicken takes things out of context and winds up getting the Pig in some type of trouble in the future by their collective actions. Chicken is single (spends a lot of time on the net and playing World of WarCraft and searching for Jessica Alba pictures) and is always looking for other available Chickens who have not had their heads cut-off just yet.



Pig

The Pig in this series is a hard working team member. With real life issues at stake. Unfortunately, as true many times in life, the Pig winds up taking the fall (or blame) when things go horribly wrong. Yet the Pig stays with it. And gets results. Pig is a widow and lost its mate on a trip to the Dole Pineapple Farm during a VIP Pig Roast in Hawaii; no further comments can be made on this impending action. One other fact — since inheriting the insurance money, Pig REALLY does not have to actually “work” for a living. Hmmm…. will it one day walk out, or continue to stay and learn — or teach — as the case may be?



Product Owner

The Product Owner does a great job shielding the team from the outside noise of what the team needs to get done on a daily basis. Is this the right person for the role? This is something teams continually must address with the person in that role. When originally casting for this position, I had a super-hot model-type in mind; however, as with all casting calls, it wound up that this Product Owner REALLY was the right person for the role (OK… so in reality Tony (the illustrator) voted against this — something I will have to thank him for someday!). Semi-clueless on life (we actually do not know anything about his life outside of work at this point in time); however, this Product Owner understands his business like nobody else we know… which makes him an awesome Product Owner. And he knows that working with all the outside stakeholders on a project sucks (in real life too sometimes!); however, the team respects him and looks to him for priortization of the Product Backlog and being collocated with the team throughout the day to answer any questions they may have. See — he really is awesome!



Ken

Every methodology, framework, or process [whatever you want to "call" Scrum] needs a thought-leader. The other characters look to him occasionally for his “by the book” answers. All in fun, of course. And please do not ask me if the man wears black turtle necks to bed… you will have to ask his wife that one (smile… because you see, I have never had a “Ken Sighting” without him in his trademarked black turtleneck top).



Scott

His name is Scott Ambler and he has been one of my personal mentors for many years. We co-wrote a book a few years ago and have traveled to some pretty cool places on the globe over the years. In addition to Scott being a friend and mentor, he has also published about 20 books (either as author or co-author) and now, as he likes to say, “IBM joined me.” He now works for IBM as an Agile Practice Lead (pretty cool job I think) and we still keep in touch. His profile can be found at www.ambysoft.com/scottAmbler.html.

So why have I included him as a character on this site? He knows a lot about various different agile methodologies. In fact, he is the leader in the industry on a lot of them (because like Ken Schwaber, Scott Ambler has helped get the word out about different agile software development methods.

And.

He is a bit on the controversial side. For instance, he is not a big fan of the current certification model that I (and others) teach; this should add some good content for the cartoons (smile). Sorta like I approach things in life. Coincidence? Hmmm.

Gotta run…

Please send comments, questions, criticisms, ideas, or whatever here.

You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!

Originally Published:
April 23, 2007
Updated:
January 7, 2008

]]> http://www.implementingscrum.com/2007/04/23/the-cast-of-implementingscrum-infamous-yet/feed/ 2 http://www.implementingscrum.com/2006/12/26/burn-baby-burn/ http://www.implementingscrum.com/2006/12/26/burn-baby-burn/#comments Wed, 27 Dec 2006 02:21:22 +0000 mvizdos http://www.implementingscrum.com/blog/2006/12/26/burn-baby-burn/ ]]>

---

Welcome to a new week at implementingscrum.com.

One of the ways a Scrum Team tracks their progress is through the use of a burn-down chart.

It is used to tell you how much work is left to do in a Sprint. Right or wrong, this is the purpose. Now, keep this in mind as we move forward on this one…

I’d like to focus on some of the ways it should not be used….

If a burn-down approaches zero only at the end of the Sprint, it is not�being utilized by the team.

If a burn-down uses an “ideal line” to help trending (something I tell teams NOT to use), and the actual burn-down is tracking exactly, something is wrong.� Really.

If a Chicken walks into a room and wants to know why the team is not tracking to the “ideal” line, and proceeds to tell the team what to do to get there, something is wrong.� Really.

If there is no burn-down chart displayed in the room, or it is out of date, something is wrong.

OK…

Now I will review each of the statements above and backup the reasons for why I said them like I did. You may disagree. And that is OK.

If a burn-down approaches zero only at the end of the Sprint, it is not�being utilized by the team.

I have worked with many Scrum Teams that have thought the main purpose of the burn-down chart is to “report their status to Mike.” Ug.

Um. No. This is one of the signs of a dysfunctional team. I guess if some of the teams I work with are dysfunctional, this will keep me busy — but that is for another topic.

When a burn-down chart approaches zero only at the end of the Sprint (or at all), it tells me that the team is not effectively using the simple tools available to them. Mainly, these “tools” include user stories and task cards. Nothing high tech.

The burn-down should show movement — up OR down — on a daily basis. Remember the purpose of a visible burn-down chart is to help show the team how much work is left in the Sprint. That is all. It needs to move some direction each day. If I see a flat-line most of the Sprint…. it tells me the team is spinning and probably dead in the water. And they are only going through the motions of updating the burn-down chart. Sad.

If a burn-down uses an “ideal line” to help trending (something I tell teams NOT to use), and the actual burn-down is tracking exactly, something is wrong.� Really.

OK, any burn-down I see that uses an “ideal line” usually signals something is wrong with a Scrum Team. The “ideal line” is usually drawn in red (or some other color) at a nice perfect angle.

Um.

Think about this.

Life is never perfect.

A “perfect” burn-down in my mind is one that goes up, down, up, down, and eventually takes a dive toward zero. This shows active communication between the Product Owner and the team.

If it is perfect, someone is gaming the system. Nothing is life is perfect. Nothing.

Reality is real.

If a Chicken walks into a room and wants to know why the team is not tracking to the “ideal” line, and proceeds to tell the team what to do to get there, something is wrong.� Really.

Oye. A Chicken wants to become a Pig. Ug. Remember the PigKin?

Hopefully enough said on this topic. Really.

I know I know I know… Chickens want to help. They see a chart with that darn “ideal” line and…. what has their old training taught them…. go into command and control mode to and give the team answers for their problems. “Add more people to the team.” “Work overtime.” “Work weekends.”

No. No. No. No.

The correct answer is for the team to have a conversation with the Product Owner. Reduce scope for the Sprint if you need to do that. Read that last sentence again.

Remember… when using Scrum…. imagine the Iron Triangle with three edges — Scope, Budget, and Resources. In Scrum, only Scope is negotiable. Think about it…. Your budget per Sprint is pretty much fixed (resources*hours*length of Sprint). Adding Resources — we all know this — does not work. You cannot make a baby in a month by dividing it into nine women. Really. Duh.

So… have that [tough] conversation with your Product Owner about Scope. Even if people say, “Scope cannot be changed.” Guess what. Reality sometime sucks. And reality deems the discussion of Scope something that must happen. A good ScrumMaster will facilitate those discussions.

If there is no burn-down chart displayed in the room, or it is out of date, something is wrong.

If no burn-down chart is displayed in the room, this is a sign that a lot of things are wrong. If the burn-down is from Sprint #2 and the team is in Sprint #5. Um…. Think about it.

Look at the other artifacts — or information radiators — in the room. Are they also stale?

Time to bring in someone else to facilitate a retrospective. The ScrumMaster has lot his or her objectiveness (is that a word?) and has become part of the problem. Bring in another ScrumMaster to help turn things around. IF that is possible.

So, I think that is a good amount of information for now. I am sure to re-visit this topic.

For now…

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!

Originally Published:
December 26, 2006

]]> http://www.implementingscrum.com/2006/12/26/burn-baby-burn/feed/ 3 http://www.implementingscrum.com/2006/10/30/shock-treatment-for-your-product-owner/ http://www.implementingscrum.com/2006/10/30/shock-treatment-for-your-product-owner/#comments Mon, 30 Oct 2006 11:38:29 +0000 mvizdos http://www.implementingscrum.com/blog/2006/10/30/shock-treatment-for-your-product-owner/ ]]>

---

Welcome to a new week at the Implementing Scrum World. Things here have been going very well, and I’d like to welcome our new subscribers (either via the RSS Feed or email).

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!

Originally Published:
October 30, 2006

]]> http://www.implementingscrum.com/2006/10/30/shock-treatment-for-your-product-owner/feed/ 2 http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/ http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/#comments Mon, 11 Sep 2006 22:29:07 +0000 mvizdos http://www.implementingscrum.com/blog/2006/09/11/the-classic-story-of-the-pig-and-chicken/ ]]>

View a translated version here — now available in 10+ other languages!

---

Welcome to the inaugural cartoon on www.implementingscrum.com.

Since the original publication of this cartoon series (starting September 11, 2006) I have made a few updates to the content of this page.Nothing has materially changed since we started the series; if anything, I hope it adds clarification to the overall content! This story is the first in an ongoing series to help explain what Scrum “is.”

And.

What Scrum “is not.”

Will we get it correct all the time?

Probably not. And that is OK. The plan is for all of us to learn.

Your comments are always welcome.

So, why are we using a Chicken and Pig? The story depicted above, as weird as it is, helps me — and others — explain two of the main types of people in Scrum.

I am amazed that the Human Resource Departments of many companies I consult with have not shut down this example; it is probably only a matter of time. This is still the best example I know of to explain the roles, and this is what our cartoon series reflects.

The basic premise of the Chicken and the Pig can be seen from the cartoon example above.

Here is an easy definition of the Chickens versus Pigs.

A Pig is someone who has skin in the game. Mike Cohn aptly refers to the people in that role as, “Having their Bacon on the line.”

Pig roles are considered core team members. Performers. People who “do” work.

Get it?

I would consider the roles of both Product Owner and the ScrumMaster to be pigs on a team.

A Chicken is someone who has something to gain by the Pigs performing, but in the end, really do not contribute day to day to “getting things done.” Their “eggs” are a renewable resource, and many get laid (eggs that is).

I get asked the following question by many people when starting to use Scrum:

“Can I be a Pig and Chicken at the same time?”

No.

You cannot be a Pig and a Chicken at the same time.

This is something I work with middle managers who struggle with this on a daily basis. The concept takes coaching, and constant [gentle] reminders that they cannot be a Pig/Chicken. I call this a Pigkin… and it is something you do not want to see in any organization!

A video commentary of this cartoon can be viewed here (it was posted February 16, 2008):

Meet the rest of our cast in this series!

We will examine this and other issues in this series, as this is fun to see happen (sometimes sad WHILE it is happening, but funny to imagine).

I do hope the simplicity of the cartoon above gets the point across. Remember it. It will serve us well in the journey ahead.

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:
September 11, 2006
Updated:
May 1, 200
October 23, 2007
February 16, 2008 (with Video)
More:
November 29, 2006

]]> http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/feed/ 37