Than you.

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

And — THANK YOU for waiting — a BRAND NEW comic strip. I am excited to get this new one out to you. I hope you enjoy…

A Sprint is typically 30 days (can be less — more for another posting) and a lot of places I go to and consult with look at the word “Sprint” as a bad word.

The general idea of a Sprint is for all stakeholders to get into a regular heartbeat of delivery (you know, so the team can deliver potentially shippable products on a regular basis).

For some teams, this looks like a continuous non-stop treadmill or running in a mouse cage (do you get a good visual on that now?).

And it goes on and on and on…. with teams never getting to “Done.”

This is sad.

How can you keep this from happening?

Well, I see a few ways that I’d like to examine today.

I want to examine how this is not a bad word or term and how it can be used effectively for sustainable development.

The whole idea of Scrum is to produce working software on a regular basis.

Working Software.

Say it with me now… “Working Software.”

Nothing else. Everything else is, well, not “working software.”

This does not mean the team has to forget about the differences between the Product Backlog and the Sprint Backlog (hmmm… foreshadowing my next two topics and comic strips) — because this is one of the ways a team usually gets to this point.

Think about it.

Who is committing to the work you are doing as a team during the Sprint?

If you are on the floor laughing, or have a blank stare on your face right now… let me re-frame the question to…

Who is SUPPOSED to commit the the work you are doing as a team during the Sprint?

If all else fails, what is the last thing we do before starting a new Sprint over again?

Stop and think about this.

It begins with the letter, “R”.

A Retrospective is probably needed.

Maybe this means reading a book about it.

And I mean READING it until the end and then actually PRACTICING what you read about.

There is a night and day difference between a crappy Retrospective and a good one.  Retrospectives work.

Use them.

Find out why your team thinks the word “Sprint” is a bad word.

It should not be a never-ending cycle.

Really.

And.

If it is…

Maybe it is time to perform an “Abnormal Termination” of the Sprint, call it a day, and go back to the Scrum Basics.

Hope this helps stop the insanity of never-ending-Sprints.

What else can you recommend to help stop this?

Send your comments and share some of your experiences.

Thank you!

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

I started using “Solo Scrum” again. This means that I am playing the three roles all by myself.

What are the three roles?

1) Product Owner
2) Team Member
3) ScrumMaster.

After only one day (Thursday) of using this again, some big things jumped out at me as lessons learned.

Take a look at the video and please provide comments to what you see so far.

Is this kind of thing useful to you? Do you see similar mistakes?

I’ll see if I can make some improvements on Friday and share them with you.

Have an awesome weekend (or welcome to Monday!).

Thank you!

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

Thanks for reading this latest blog entry at www.implementingscrum.com.

Today I want to introduce you to the latest translated cartoon on the site in Tagalog.

Quick… What country is this the official language for? C’mon… no peeking at Google (smile).

I’ll let you know (since I really did not know either!)… it is the official language of the Philippines.

This brings the total count of translated versions for the Pig and Chicken Story to over a dozen now!

Thanks to all who have contributed so far, including Randy Dichoso for this one!

Interested in translating this into your language?

Contact me and I’ll let you know how to do it.

This continues to show the truly International flavor of Scrum and where it is being adopted everywhere in the world.

I hope you are having a great day (or morning or night!)…

I’ve got three more brand new cartoons in the pipeline over the next three weeks… on brand new topics and exploring even further into this world of Implementing Scrum we are all so involved in.

This is another version of the “UnScripted” blog entry on the site implementingscrum.com.

Today I’d actually like to post a question from one of my readers that I’d like to get feedback from you — the community — via answers in the comments of this blog.  I’ll plan on doing a follow-up to this but as usual, I want to show the community we can all learn from each other…

I have an opinion.   Of course!

—————————–

Hello Mike,

I took your class last year and I am a CSM now. I have not had the chance to be Scrum Master on a project yet, but it is in the near future.

Currently I am on a project that has 2 week sprints and on a team of 8.

The question came up yesterday during our Retrospective that during out last sprint there were a lot of chickens on the scrum calls.

How do we handle this?

I know that if you don’t have any tasks to complete or you have completed your tasks you should be reporting yourself as “chicken”, but with stakeholders on the call everyday hearing 2 people report tasks and the rest of the team reporting “chicken” every day for almost 2 weeks…doesn’t that appear to the stakeholders that only 2 people are working?

IS there another way to still follow the Pig/Chicken rule without appearing to the stakeholders that there are a lot of people not working?

Please advise.

This was a discussion that was placed on the action item list due to too many conflicts between team members.

Have you seen this before?

How was it handled in other teams/projects?

Comments Please!

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

One of the things I hear a lot about (both inside and outside of our little industry in the world) is the differences between coaches, consultants, and mentors.

Which brought me back to a discussion I had a few years ago with John Snuggs (shout out!) who used to poke me about wearing my “Captain Obvious” hat.

Which then lead to the super-hero-wearing-ScrumMaster in the comic strip above.

And.

Then the elephant.

Huh?

What does that elephant represent?

In America, we talk about this thing called, “An elephant in the room” which is something reallllllllllly uncomfortable that everyone knows is there but is afraid to bring it up.  Make sense?

Sooo… besides being the elephant in the room… what does Captain Obvious need to teach us about Scrum “Coaches” versus “Consultants” versus “Mentors”?

This could be one of those epic postings with me talking about the ins-and-outs of the three words and how they not only sound different — but in the real world ARE different.

So.

Question to you… and I will talk and post more about this… in the comments section write more about the good, the bad, and the ugly about the differences you see in either the people you hire, work with, or ARE.

Elephant recognized.

Let’s hear more about what this means to you.  And your teams.  And your organizations.

And of course… this is leading somewhere.  It always does.

And it usually surprises even me (heh).

Time for Captain Obvious.  Pointing out the elephant in the room.

- 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

Non-fiction?  Fiction?  It really does not matter.

And this book you read… what did you DO after you read the book?

Did you put it back on your book shelf?

Did you even finish it (smile — you see, *I* start a LOT of books!)

And there it gathers dust until one day… for some reason… you got the urge to pick it back up again.

Started at the beginning.

Or maybe a few pages back from where you left your bookmark.

And.

What did you learn after re-reading the same book again?

Anything?

Think.  Really Think. [challenge ON my reader!]

Now.

What if you read a bunch of books on a topics after using Google to search for “Scrum.” [Note: Page 1 baby!]

And.

What if you read a bunch of cool blogs on the topic of Scrum (like www.implementingscrum.com or my personal site at www.michaelvizdos.com).

And.

Did nothing with that information.

Until.

One day, you took a class from someone experienced who tied together the real-life version with the book version of the topic.

Then.

You went back and read the “books” again.

What happened?

Was it the same experience or were you able to read it from a totally new perspective?

Please share via comments…. I am looking forward to continue learning with you!

Thank you,

- mike vizdos

And the story I tell is that of an older movie called, “Spinal Tap.”

Ever hear of it?

If not, it is a “Rock-U-Mentary” about a fake band who gets followed around by a camera crew.

Ask anyone in your office about the “11″ line and have them do it in their best accent (they will know what you are talking about if they have seen the movie).

The main gist of that line is that during an interview, one of the band members asks why their amplifiers have an “11″ on them, instead of just the normal “10.”

Blank stare.

Then…. the band member says, “Because 11 is louder.”

And then the interviewer basically asks, “Why not just make 10 louder?”

Blank stare.

Band member, “Well, because this one’s got an eleven.”

So I may have screwed it up since it has been almost 25+ years since seeing the movie (I think… yikes!).

I have heard it is best watched in some kind of altered state; however, I would not condone or recommend that to anyone reading this article.

So what does an amplifier with an “11″ have to do with Scrum and introducing it into an organization?

Comments here are welcome again, as it seemed to spark some great discussions last week (scroll down to the bottom to see all the comments people have left… wow!) …. (of which I really need to go back and answer if appropriate)!

Here are my questions, but you can answer them (or your own) any way you’d like (It’s almost like being a moderator for the US Presidential and Vice Presidential Debates this year sigh):

1) What are the top five GREAT things that have been amplified in your organization when introducing Scrum?
2) What are the top five INSANE things (read: Dysfunctions) that have been amplified when introducing Scrum?

3) Was Scrum the cause of them?

4) Did Scrum force a change one way or the other?

Let’s see where it leads.

If anything, go watch the movie if you’ve got some time to kill .

Of course, that is AFTER you respond to the questions via comments back to the site!

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!

I am working with a lot of teams and hearing about this problem coming up again.

Kind of like a cough that will not go away (that is for another day).

Ah… Kids back in school.  Spreading knowledge.

And.

Lots of other stuff.

Germ mines that bring new germs home to their parents, who have not seen most of the stuff out there in the past.. and so on and so on.

Then.

Those parents go to collocated team rooms.

With people who do not have kids.

Germ-o-phobe-hilarity-ensues.

The original blog entry is located at http://www.implementingscrum.com/2007/01/08/sick-stay-home/.

Read it.

Post it on your team room walls.

Send it home to people on your teams who are still calling in (or ask them to call in and GO home!).

Good luck out there.

- mike vizdos

This is a blog entry I have been meaning to write for a while.

Earlier this year I met with Ken Schwaber at his house for an awesome discussion with other people too.

In the past (August 2002 – August 2006) Ken used to issue the Certified ScrumMaster certificates as a piece of paper directly from him.

How times have evolved.

Now, it is an agreement between you and the Scrum Alliance, a non-profit organization.

And.

It is electronic (via a PDF file).

One of the questions that came up while I was there was, “What happened to all the old original certificates?”

He took me down to his basement.

In a dark dark corner, underneath a sweat band was the pile of original agreements.

My question was answered.

I assume mine is somewhere near the bottom of that pile.

And some people say some things never change.

Just thought I’d share this incredibly useful information with you (smile).

Wow.

This is post #200 on the site.  Not bad for just over 2 years of working together.

Thanks for reading!

- mike vizdos

Yesterday I promised I would start a difficult conversation for someone out there.

If this one is for you, please use it.

If it is not applicable to you, bag it and save it for the future.  And maybe hope it does not happen to you.

The original cartoon and blog entry on the topic of “Done” was one of the first I published on the site.  It is something that has been slapping me in the face more and more lately.

Here is one of the difficult conversations you may be facing:

Let’s say you have completed a task on a user story.  You are happy to be moving it from “Work in process” to “Done” on your story board.

It is indeed a happy event.

Pause.

Do me a favor.

Walk into a “Best Buy” right when it opens.  On a weekday.

If you cannot do that, here is what happens….

Right when the doors open, you have about 15 people (all the staff) standing in the door opening CLAPPING THEIR HANDS as you walk in.

Managers are watching the employees like hawks to make sure they clap.

I am dead serious.

Do this.

And.

Notice something.

While they are clapping at you, they are chatting between themselves, some of them are actually texting their friends on the phone, blowing bubbles with bubble gum, or staring off into space.

And that is just the employees interested in you being there.

While I am sure this is meant to be a great welcoming gesture, it is extremely uncomfortable to both the people walking into the store to buy their headset (or other cool technical crap) and the employees who are being “forced” to do this.

Now.

Back to moving tasks from “Work in Process” to “Done.”

I have seen teams who have been told that “YOU WILL CLAP YOUR HANDS” when tasks are moved to “Done.”

Um.

Do you see a parallel here between Scrum Team Members and Best Buy Employees and their Customers?

If this “Ceremony” does not work for your Scrum Team…

Talk to your outside stakeholders about it.

If you are an outside stakeholder on a Scrum Team who thinks “forcing” people to clap when stories are moved to “Done” is a good thing…

Please please please stop by Best Buy at opening on a weekday and feel the experience.

Remember.  Feelings?

They matter.

OK now.

Start talking .

Let me know how it turns out via comments or email.

Thank you,

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

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

Just passed CNN Headline news and heard the politicians in the USA blabbering on about a “Lipstick on a Pig” comment.

Propaganda and political agendas aside, it did remind me of a posting I did back in 2006.

It was about removing the lipstick from a pig.

And it was a good reminder about what a lot of teams are trying to do with Scrum today.

Stuff I am hearing more and more come up — both within Scrum and life in general.

Timely for news junkies.

Start those tough conversations.

Today!

And get the word out about it.

Hopefully this will be of use for both new and regular readers.First, the story of the Chicken and Pig. Read more here. And here if you speak more than just English.

Even if you are not a techie, some of these stories and cartoons at the blog may help tell good stories.

One of the most popular on the site is here. I do not know why, but can imagine some. Whatever .

If you just like looking at cartoons, check out here. There is a thumbnail of all cartoons every created on this site. Just click and enjoy.

Rinse and repeat.

So that gives a good tour of what the site is today.

I’d recommend coming back in the next few weeks. Subscribe now.

Because things are about to change.

There will be a new look and feel to the site.

The site is moving to a dedicated server — faster cartoon loading for you.

You will get more for your money.

OK. Well. The site is still free.

And no advertisements (hopefully that will continue!).

Even if you are not a geek — tell your friends. Or just have fun reading about geeks (that would be me and people I work with).

And strange things that happen in our world.

And.

I promise Tony will be back to work on new comic strips soon. Really. I promise.

Like when my parents come to visit — I know they really just come to see my kids. Just like the cartoons are the lifeblood of this site. I appreciate knowing that and providing those and my blog entries as a bonus (smie).

Have a great weekend (or welcome to Monday) and happy surfing!

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!

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

A cartoon finally! Yeah! Again!

OK, so this one is really a translation for the one I did about Social Networking, something that has been shown to have incredible benefits to Agile Scrum Teams.

Here is the English version for your viewing and reading pleasure.

So what does Me asking You if you’d like to go to bed with me have anything to do with Scrum?

Hmm.

This may require some creative answers.

Or maybe just one.

Honestly I love the French accents and the French [create?!?] some of the worlds best looking women with the best accents (did I say that already) in the world.

That, and besides saying “yes” in French, that is the only phrase I know (back from a hit song in the 1970’s).

So, I want to personally take a moment to thank the French for French Fries (OK… I know… invented and have the best in Belgium) and French Nails and a certain kind of kissing. All goodness.

And.

For someone (Matthieu de Vivie) taking the time to actually put up a translation of what was thought to be a good English version of the cartoon!

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!

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!

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

I am a bit worried about some of the things I am seeing out there.

Um.

The night before a Sprint Review meeting, I am seeing people stay late.

Uh.

Really late.

Like into the morning before the Sprint Review meeting.

Sometimes, it is minutes before.

Ug.

Oh no.

What does this remind you of?

What is wrong with that picture?

And what is right with the picture above?

Seriously folks.

Don’t kill Scrum this way.

Just go back to whatever you used to call it.

Really.

Or.

Look at what you are really doing.

Remember the objective of Scrum?

Working Software.

On one machine.

Real working software.

Not vaporware or conference-ware or some scripted bla bla bla.

Please.

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.

Wow. I saw something at a client site a few weeks ago that inspired the cartoon for this week.

This is real life.

As it is every week and every posting with me.

And.

Unexpected to say the least.

I’ll let you in on the actual pictures of the inspiration tomorrow… but for now let’s continue with the point for this week.

Sometimes it feels like you are working on the same thing day after day.

At least sometimes it feels that way to me. Maybe it is just me (smile).

Kinda like a treadmill. This is something that you walk on forever and actually get nowhere.

Are you there in your [work] life?

What about your Team?

And your Organization?

What can help you get out of this — or “off the treadmill?”

Umm.

I could sugar coat it with a bunch of inspirational bla bla, and sometimes I do that.

Tonight… zero sugar coating. It is not going to happen, as sometimes you need to hear this and actually take a hard knock of reality (like sometimes people on the team need to be “voted” off the island!).

Here goes.

The only way off the treadmill is for you to make a change.

Take responsibility.

Be accountable.

To who?

You.

The rest of the Team and Organization will follow.

Or will they?

Does it really matter to you?

Worry about you first.

Really.

The rest will follow.

Or not.

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.

I sincerely apologize for the lack of a new posting last week. Sometimes even I need to remind myself that I am human.

And.

The cartoon for this week really says it all.

Keep IT Simple Stupid.

In the past, I have seen the “KISS” stuff look like: “Keep it simple stupid” or “Keep it super simple” or many other variations.

Note the capitalization of “IT”?

That’s where you and I come in a lot of the times.

So.

Really.

Keep IT Simple Stupid.

I am not calling you stupid. If anything, this is a great reminder for “me” to not get stupid.

A few weeks ago I was with a client (actually doing the work thing, which I doooo actually “do”!) and they have been spending a lot of time planning for their agile rollout.

What is a lot of time?

This will vary.

Let’s just say it looked very much like a waterfall process — nothing near agile.

And I had to tell them this.

Will “they” listen?

Who knows.

But.

It was a great reminder to me that taking months and months planning for an agile rollout of more than ten teams at one time is not a good idea for people starting agile stuff.

What is my recommendation?

Get ready for “Captain Obvious.”

Start with one project.

Today.

Now.

And stop the planning game.

Really.

Get good at what you do.

And the only way to do this is to get started.

One project at a time.

Don’t worry about the enterprise rollout today when you have not started even one project.

Scary thought?

Yes.

Reality?

It does work.

Worry about the “enterprise” stuff later.

Start producing working software.

Today.

Think about it and challenge the way you currently do things today.

Results will vary, but all will surprise you.

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.

So.

A few weeks ago had someone in a class explain this. He was trained as an Antropologist — not a software developer.

Interesting dude. Really.

Let’s say your current organizational system is like a river flowing down stream.

How rough varies.

Introduce change.

Any change.

Just one.

Scrum for example (funny how that gets worked into this conversation, eh?).

Pretend that change is a boat (or canoe, as drawn!).

Insert a Chicken and Pig for some humor (smile).

Following along with me?

Now.

Paddle.

What happens when you stop paddling?

The river flushes you back down stream.

That’s the gist.

Easy brilliance.

Does this apply in your current situation?

If you are about to just embark on this journey, remember to always keep paddling!

Stop paddling and you have made a choice to give it up — and make room for something else to take its place.

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.

Remember about a month ago our ScrumMaster got “whacked” and disappeared for a while. Last week he reappeared in the hospital.

Today, he is back at work.

And.

He did not die.

Assuming positive intent, he really wanted to just help the guy in the SUV with directions.

He never got there, as we can see. And is seems like the guy in the SUV made a run for it, not liking what he saw on the ground (what would you do if you saw a fashion forward guy wearing a blue thingee on the ground; wait…. hold that thought…. we also use talking pigs and chickens in this cartoon… never mind).

So what does this have to do with Scrum?

As a consultant, I am constantly working with both prospects (those who have not engaged me for any services yet) and current / past clients. I have a strong relationship with people in the industry, and consider myself a person who is not afraid to speak up and give the honest truth.

Not a lot of people like doing that.

Sometimes, as we saw, clients do not like to hear the truth. They want to keep doing waterfall, and make the conscious decision that in the end they will succumb to what is known as the, “Iterative and Incremental Death March.”

They will then go find someone who will say, “Yes” to anything they ask of them.

And this occurs with most organizations trying to use Scrum on more than one project in an organization.

It is a choice.

What about the small minority of organizations that succeed with implementing Scrum in their organization?

Wow.

Incredible things happen.

To the people as individuals, as team members, and the organization as a whole.

These are the organizations I enjoy working with; however, as you can see, they are a small minority in the world.

You know what I have started doing more and more lately (which uggg is hard for me!)?

Saying “No.”

And working only with organizations and teams and people who sincerely want this Scrum thing to work.

Sometimes I get conned into thinking an organization is truly interested, and get burned. Life happens.

We all learn and move on.

This is not the majority of time though, and yes, even I need to assume positive intent.

Why am I telling you all of this?

First and foremost… think about where you are today on your team and within your organization.

Are you constantly saying, “Yes” even when you know it makes no sense?

Do you need help saying, “No” sometimes?

Where can you go for that help?

And remember… a dead ScrumMaster is a useless one.

DO NOT commit career suicide.

But remember… you DO have a choice.

Always.

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.

About a month ago, our intrepid ScrumMaster seemed to have disappeared and replaced with someone who just agreed with everything everyone said (not really a yes man, especially in the cartoon!).

Well.

He is back.

Or. He never left.

So why is he now sitting in a hospital room with an IV unit, talking to himself?

At least he in conscious and alive.

But now he is saying “No.”

Is this a bad thing?

Remember the entire reason for him getting into this position — or at least why we think he did.

He was saying, “No” to a lot of people, and standing up to the Values of Scrum as he envisioned them.

So we have the Scrum Values.

And.

Each person in the world either knows nothing about them, has heard of them, or is choosing to ignore them.

Which person are You?

Where is your Team?

And your Organization?

Do you see a difference between the current “replacement ScrumMaster” and the one we originally started with?

What do we do next?

Yikes. This is a short posting tonight.

Think about it.

Really.

Think.

Sometimes this can be dangerous.

I call it living.

Something I am continuing to learn how to do.

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!

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

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 am 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 will 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 have got them all, come on back.

Ready?

Okay, how did you do?

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

Welcome back to yet another week at www.implementingscrum.com. We made it another seven or eight days on this earth — congratulations (smile).

So last week the post was a little long, and I put out some real life information that hit home hard for me. I received a ton of great feedback and people offering a lot of great advice. One thing I do want to make clear is that client was not my only client — something I have learned to not do in the past (depend on 1 client 100% of the time). As a consultant, this is a position you want to get yourself into. Really. Look at me as an example!

This week.

Um.

Where is our “old” ScrumMaster?

I kinda liked him. He was a little “off” at times; however, he started to grow on me and help with a lot of examples.

He seems to have disappeared last week.

Seems to have gotten himself whacked by some shady characters.

Oh no.

What has Tony done. What have I done?

At this point, there is now a [hot] ScrumMaster who has no problem saying, “Yes” to anything and everything asked of her.

Um.

Is this dangerous?

One word.

YES.

Notice the usage of capital letters above.

YES I AM YELLING THIS TO YOU THIS IS DANGEROUS.

I am trying to make a point (smile).

And, you may be asking yourself, “Mike… What point are you trying to make this week?”

Really?

You do not see it?

Look hard.

Read the comic strip above again, and again, and again.

Then, send me an e-mail (or write a comment on this blog entry) about what you think it means.

Really.

C’mon.

Take action and do it.

It will take you less than three minutes.

Please.

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!

This is a hard story to tell.

You may want to grab some Kleenex.

OK.

It is not that bad.

But you may want to read this through a few times and pass it on to people in your organization.

There are some great lessons learned (for me anyway).

Names and places have been changed to protect the innocent.

But.

It is a story that must be told.

Since.

Well.

It involves me.

As the ScrumMaster.

And.

I wound up becoming a “Dead” ScrumMaster today.

How did that happen?

About three weeks ago I got called into meet with the CIO of a large private company somewhere on this planet (actually it was through someone who knew him and I and trusted us both).

The company is professing itself as “Doing Agile” and has a few small projects started up.

The CIO had a particular project in mind [for me] and we spent about a half an hour having a conversation about what he wanted me to do, and discussing some of the implications (including implosion of the project).

Basically at the end of the conversation my direction was set — in the next day and a half… figure out fast how to make the biggest impact.

Boy.

I guess I did. In retrospect.

You see, the project they were getting ready to kick off as “Agile” was still not an officially funded project.

Read that last sentence loud and clearly — they had no approved budget. This was all supposedly under the radar.

So, as with a lot of organizations, people spent months and many many many hours creating the “perfect” power point presentation for their senior leadership team to review. This was prior to me coming in.

It was not good enough yet, and the team had two weeks to clean up the presentation.

I boldly asked for a team that could produce some working software during those two weeks, while the parallel effort of the funding presentation went on.

We started gaining the needed resources (wow.. did I say resources [yes... PEOPLE and the other stuff to DO a project??!!) and ideas.

We were going to take their highest priority customer and run a [one] real transaction set through a real working architecture (not on power point).

It was approved by a VP on Friday afternoon, just before a holiday weekend. I went home excited.

I arrived back on Tuesday morning and the team starting getting wind of this, and we got together in the afternoon to talk about what would happen in the next 8 business days.

Lots of blank stares and smiles, but people started getting excited.

It was something the team could focus on.

Technical people working on technical stuff — not power point presentations.

We reviewed the basics of Scrum and that during the next two weeks we would get a course — by doing the work — on what it looks like to actually do it.

Once we delivered, we would have a Retrospective and see what we could improve once the project was funded and actually “officially” started.

We talked a little about User Stories — this is a Use Case shop — and we wound up writing very basic user stories that were tasked out. No owners, no estimates. This is “normal” [real world] from what I see on the first cut in situations [and timing] like this.

Should I have put a stop to the project (or un-project) then? I made a call not to do that.

We went home.

The next morning we had a temporary conference room and we had an effective stand-up meeting.

Kept it at 15 minutes.

People were off and doing real work.

It was cool to see. I stood back.

We had an impediment with getting some dev machines that was taken care of by the team and outside stakeholders in an incredibly quick manner. Kudos for getting that first impediment out of the way!

The parallel process of getting the project funded (via the power point presentation) was happening outside of the room.

We started talking about the “Cone of Uncertainty.”

I left town that evening and the team worked for two days focusing on the tasks and items on the wall.

All highly visible to the people walking into the room (or by it).

The team got moved around a bit each day, but we had our eye on one room for the “final week” of this part of the project (or is that pre-proect?).

Not all the team members were there all the time. Hmmm…

Stand-ups stayed focused and on track. No more three hour status meetings to schedule status meetings with the entire team.

People (including me) were calling in if they could not be physically located in the team room.

I arrived the next Monday morning to the new location for the team. It was “ours” for the week. The five business days remaining on this part of the project.

New building. But we could have all the players collocated in one room or on the phone. Things were humming along.

Impediments came up and were handled by the team. Awesome. We even got a temporary AC unit put in the room to cool us off — 12 people in a small room with lots of computers… you know how that can get.

The parallel process of getting the project funded was happening outside of the room. Still. Small concern, which, in retrospect, I should have dealt with better.

During the few days I was there that week, I did what I told the CIO and others I would be doing — a lot of observation on team interaction.

I did not want to jump in and be the answer man for coding [nor did I really feel like me getting into the code would help anyone -- including the people that really needed to be in it (which was awesome to see how people recognized this and stood up and took ownership without being directed!)].

I did a little nudging along the way to fill out the task cards with owners and estimates (so we could start having what looked like a Burn Down to see what that represents); however, I mainly stayed out of the way and let the technical team dive in and watch them do what many thought to be impossible.

The goal now was to deliver working software, not a methodology (a tough balance in this situation).

Get to “Done.”

Before leaving, the Project Manager and I came up with a plan for the following week.

Assuming the project was funded, the Project Manager would start assembling the team and getting them lined up to start the “real work” the next week (people had to be lined up to work on this project).

I would not be on site this week, and meeting notices started coming into my inbox as expected and according to our plan.

Then, Thursday night I get a call telling me the client probably does not want me back. It came to fruition today.

Partly because I “sat in the corner” watching.

Partly because people heard me say things that did not tow the party line (and I did not do the Schwaber, “You Suck and that makes me Sad“).

Partly because I did not code.

Partly because I was not engaged with that team doing the request for outside funding.

I am sure there are a lot of reasons.

Go back and notice a key role missing. One that was unfortunately a key to this part of the success — or lack thereof — of this part of the project.

I did not do a good job of managing and communicating expectations with all of the stakeholders — known and unknown.

Funny thing happened though.

I hear the team delivered working software.

And.

I had a lot of great conversations with the people on the team and saw negative energy transform into a powerful focus of delivering working code in a very short period of time.

Is it perfect?

No.

Is it something they can show to outside stakeholders that has true business value for them today?

I think so.

So in part I have failed that team, and I am sorry. I am doing the failure bow now — hoping they understand.

And.

I have learned [again] that any ScrumMaster can be taken out and shot at any time.

Hopefully this is a lesson learned that does not happen to you.

It has happened to me before.

And.

Will again.

I do this at a lot of places around the world, and I know I cannot please everyone all the time.

Is it any wonder that most teams fail using Scrum?

Yet.

I try.

As do others.

Yet.

I will not blow smoke or be a “yes man” (or woman, as in the last panel of this cartoon).

And.

I am OK with that.

In some places people call this career suicide — so YOU be careful.

Read this lesson.

Read this real world situation.

And.

Talk about it with other another ScrumMaster or two or three in your organization.

Talk about it with your stakeholders.

Talk about it with your Scrum Team.

Talk about it with your Product Owner.

Talk.

Have the conversations.

BEFORE things implode on you.

Because remember.

A Dead ScrumMaster is a useless ScrumMaster.

I am going to go eat some humble pie and hope that someone learns something from this posting.

I apologize if it was a long one this week.

Lots for me to learn.

Still.

I may post more on this during the week.

And if you want to hire me (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!

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

I am writing this blog entry from the beautiful city of Portland, Oregon. Nice place and I am having a great time teaching a CSM Class here earlier today and tomorrow.

Wednesday early early in the morning, I am “off” to Santa Clara for SD West. It is an awesome conference and one that I look forward to attending and speaking at each year.

Now, as most of you may know, I am a total introvert.

Or. This may come as a total surprise to you.

This makes it challenging for me to get up in front of people to speak (imagine that… and I am a Certified Scrum Trainer who does this regularly).

Does this mean it is impossible?

Nope.

I do it.

Why?

Because I really do love what I do for a living, and I hope it shows (from writings here and the public speaking that I do around the world).

Another “insider” tip — most of the times the speakers do not get paid or reimbursed in cash or expenses to speak at the conferences. Big names and Key Notes — probably different.

But folks like me, well, guess where this expense comes from?

My own pocket. Not some corporate expense report either.

Really.

And.

This is OK with me. I truly love what I do and am willing to spend my own money to talk about it.

Yeah, there are “perks” like a shirt and a pass to other speakers and working with an awesome professional conference staff… and what can really beat that (smile)?!?!?

I try to set an example for other introverts around the world to see that anything is possible if you are willing to try.

And learn.

And get over the feeling of wanting to barf in your shoes or die than rather talk to people.

So.

Today’s posting is about the topic of making the most of any “Conference” event.

You know, where there are a lot of similar people congregating in some city trying to learn some new things and and and….

Yes, even if you are an introvert, these things can be fun and actually help you in the future.

Here are my Seven Conference Survival Tips for Geeks

1) Network. Network. Network.

This means bringing along a good supply of current business cards to hand out to everyone you meet (people make fun of me for handing out cards… if that is the worst I can be known for, well….).

Keep an eye open for a “Networking Section” at conferences. This is where you may actually have to talk face-to-face with others.

Suck it up and do it. You may be amazed.

It is a small world.

Work on making contacts — there are people from all over the world here and it is amazing the contacts I have made over the years.

Bring a current copy of your resume or be able to email it to someone if they ask — you never know who you may bump into (for me, I can just say “google me” and well, I am out there now…. something that did not happen overnight.

2) Attend Workshops.

And go to some of the night sessions or BoF’s (“Birds of a Feather” – usually an informal gathering with key people in the industry to chat about a specific topic — some like Star Trek (how much more geek can you get LOL?)) and keynote speakers you can grab a beer with. Or buy one for .

Figure out what courses / workshops / trainings / keynotes you want to see.

Conferences can be overwhelming. Listen to feedback from other attendees.

Be flexible and go with the flow when needed.

Maybe… and this may be a big leap for you… attend some workshop or talk on some technology or methodology or bla bla bla that you have never heard about.

Open your mind.

Make some connections to things out there in other parts of the world that may actually have something to do with what you are doing today.

Or…. something you may want to do tomorrow.

3) Spread out.

If you have multiple people from your organization attending – spread out and cover multiple sessions during the same time; when you return to reality (work) following this conference, the stuff you learn can be great input for brown bag lunches.

Or talk about via IM or blogging or even back to talking to yourself (smile).

===========================================
WARNING WARNING WARNING WARNING WARNING WARNING
===========================================

A lot of what you hear may get you fired up and excited about making swift changes within your organization. Please remember do not make any career ending moves when your return to reality the following week.

===========================================
WARNING WARNING WARNING WARNING WARNING WARNING
===========================================

4) Leave feedback.

Always.

Most conferences take the feedback of its customers (you and I) very seriously.

If some speaker is awesome — let them know about it.

If someone is absolutely terrible — let them know about it (and why).

Conferences are continually evolving and get better every year with feedback from you and me.

Even as introverts we have a say. Let it be heard! It only takes a few minutes…. and REALLY makes a difference.

5) Have fun.

Yeah, sometimes you are stuck hanging with fellow geeks.

So meet people and start talking to them. It is amazing to see that other people may have the same “problems” as you do in your development shop today — creative solutions flow freely here.

And if you are into male Dolly Parton Cover Bands… well…. I can tell you a story from a few years ago.

Expect the unexpected.

Really.

6) Learn.

Stretch yourself. There are plenty of topics here that you may not know about — now is the time to learn something about those topics.

7) Network. Network. Network.

Oh, I said that.

Hmmmm….. That is the most critical thing in my opinion (smile).

Here is a “final ask” before signing off tonight — if you are attending the SD West Conference — or any other one where I am attending or speaking around the world — PLEASE contact me to see if we can meet face-to-face.

And I promise as long as you are not some hot six foot four supermodel with some name I cannot pronounce, I will not barf on my shoes (I may barf on your hot shoes — shoot…. YOU are the six foot four supermodel).

Kidding.

Really.

Would love to meet fellow introverts.

Or.

Learn from friendly extroverts!
Got any other ideas? Share and leave copious comments. Consider it practice for real-world-networking!

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!

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

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

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

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!

Today I am addressing something that has been bothering me — and others in the industry too — and maybe even you, my great reader!

Scrum talks about having having working software at the end of every Sprint (or iteration).

Wow.

Not a Requirements Document. Working Software.

Not a Design Specification. Working Software.

Not a great Architecture PowerPoint Presentation. Working Software.

Not Compiled Code. Working Software.

Not an incredible Test Plan with Automated Testing and complete coverage. Working Software.

Yikes.

Get the point here?

Not too preachy I hope (smile).

That is awesome, right?

“Working Software” then became recast or known a, “Potentially Shippable Product.”

Huh?

Is there a difference?

Yes.

There is a difference.

Think about it.

In your Scrum Teams today, do you have someone from your Production and Support areas involved with your Sprint on a daily basis? How about the Daily Scrum (or Daily Stand-up meeting)? What about in your Sprint Planning? Planning Poker?

Any planning?

At all?

Hmmm.

Now OK.

We may have different definitions of Production and Support people. You can look at them as one separate team, two separate teams, or actually part of your Scrum Team.

In Agile and Scrum, I’d argue that the Production and Support people should be an integral part of the Scrum Team.

In the end, it is the Scrum Team agreeing on the definition of, “Done” for the Sprint (or iteration).

And where does Working Software actually spend most of its usable life?

Say it with me now… “In Production and Support.”

Wow.

What a paradigm shift in the way you are working today.

Or is it?

And.

Think about this.

If your Scrum Team does not include the Production and Support people into your Scrum Team, you may be creating more “Working Software” than the rest of organization can handle.

What? You may be asking yourself?

Are you kidding me?

Nope.

I see this.

Often.

And.

One way I advise clients about handling this situation is to include the Production and Support people into the Scrum Team.

Do they always listen?

Nah.

And then they have a big dump truck full of stuff (waste…. work in process…. inventory….).

What does this cost an organization?

What is this costing your organization today?

Do you care?

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!

Hi.

Wow. I just did an informal count (and recount) of all the comic strips that have been posted on this site. This is comic strip #65 since we started with the initial comic series of the Chicken and Pig since September 11, 2006.

I was having a conversation with another “Scrum Person” last week over lunch and the topic of this site came up. He was surprised that this blog has been updated on such a consistent basis since we started the site. Turns out a lot of people in the industry thought this idea had no staying power. I met for dinner with an ex-CIO of a past client this evening (just got back and am writing this now!) who was surprised we only had 60-something cartoons up there… so…. information is taking off in all different directions about this site.

Back to my pundits…. [Still getting over the fact that I do have people out there that want me to fall flat on my face!]

“This is Scrum… how much can you really talk about this each week Mike?”

“Scrum is a simple framework. That’s it. Duh!”

And.

I agree.

It is.

A simple framework.

It is designed to be that way.

For a reason.

What makes this fun for me — and I hope for the people who read this on a regular basis — is the fact there is almost a never-ending product backlog of ideas for me to write about and Tony to illustrate new comic strips for us.

Huh?

Remember… Scrum deals with people. Not resources. People.

This is not a static topic that will go away. People will continually show me there is new material to write about in the context of Scrum.

And for that, I thank you sincerely.

In fact…. over the time we have been publishing this blog, it has grown in popularity (we consistently receive over a million hits per month) and some of the comic strips have been translated into over a dozen different languages.

What amazes me is that the comic strips (most of the times without the write-ups) are showing up in other Scrum Training presentations and being used selectively in team rooms and corporate presentations.

When I start seeing these posted in team rooms, seldom do people in the rooms realize I am the author of this site.

I ask, “Why do you post this (or these) comic strips?”

A consistent answer to me is, “They are great conversation starters with our outside stakeholders.”

“Oh, and they are funny and our team really relates to them.”

Wow.

Um.

When I started the vision for the site I originally thought I’d connect with an illustrator (it took me six months to find Tony) and start to see if we could push the envelope on some topics that a lot of people in the Scrum Community have been avoiding.

Or.

Should I say, “had” been avoiding.

Why do I say “had”?

I have seen that these comic strips and blog entries are now bringing out some very tough conversations about transparency or real-world issues between team members, product owners, ScrumMasters, and outside stakeholders.

Wow.

Bringing the fringe to the forefront.

In my case, one comic strip and/or blog entry at a time.

Do you see this happening in your team, organization, or enterprise today?

Has one — or more — of the comic strips help create some change that was really effective for your team?

What about thinking if one of the comic strips has been disruptive to your team?

I hope you do not agree with everything I write or Tony illustrates.

I do a lot of what I do to help people start thinking about the ordinary in an unordinary manner.

Is this happening for you?

If not… Why not?

Meanwhile, my plan is to keep cranking out new comic strips and blog entries no matter what my pundits are saying. I’ve never been one to follow the crowd. While it may not make me popular…. I stopped worrying about that sometime in high school and now think about how well I can sleep at night — and feel good about me. And not only about me (that sounds selfish in retrospective)…. but does this stuff add value to you (the person or group of people reading this blog and our comic strips)?

Is that a bad thing?

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 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!

So today we are talking about something called Agile Modeling.

It is a concept that has been spearheaded in our industry by a guy named Scott Ambler. It is not some place for hot young women to send their modeling portfolios (when I worked with Scott, this happened on many occasions [if there are hot women who want to send me their pics please send them here (smile)]).

Sorry got a bit off topic.

So.

What is this Agile Modeling stuff and how does it pertain to Scrum?

Think about how we do things in Scrum (and a lot of other agile software development techniques).

We inspect and adapt.

Agile Modeling uses a lot of the same concepts.

Except this is looking at the documentation and modeling techniques within agile software development.

Something that Scrum does not really talk about but it something that is needed when actually developing software for a living.

There is a concept called Agile Modeling Driven Development (AMDD). More information about it can be found here.

Read it. Learn it. Use it.

Really. It is an incredible resource for agile teams.

One of the things that irks me (bad) when I walk into an agile team and they say, “Oh, we are using Scrum we do not DO documentation.”

What?

Ug.

Everyone does.

We do some type of modeling throughout the entire project lifecycle; this includes project initiation (or startup or “Sprint Zero”), during Sprint Planning, and on a just-in-time basis throughout a Sprint (Scott calls this “model storming”).

And this leads to Agile Modeling. Something more of us can all learn a little more about.

It will also help keep you out of heat with your “Compliance People.” You can read a little more about that here.

And what about this reference to Luke and Leia in the cartoon this week?

Ah.

You will have to keep coming back to learn more about that connection.

The plot thickens.

Have a great day!

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 sincerely appreciate it.

And please feel free to help me pass on the word about this site to your friends and co-workers around the world who may be interested in the new — and existing — rich content on this site about Scrum and how I see things when working with clients around the world and training new ScrumMasters for their roles.

Today I am going to start with an introduction of a new character for our site. All of the other characters are introduced in more detail here.

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.

So, starting tomorrow you will get an introduction to the character that is Scott Ambler in the first official cartoon for 2008 on implementingscrum.com.

This should be another fun year.

Hang on for the ride.

Get involved.

And help us all learn more about Scrum and other agile methodologies.

And remember, like the other characters, what Tony and I say in the cartoons use purely artistic license and may not reflect their real world views or opinions.

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!

Today, as promised, I will tell you about the debrief related to the exercise for the cartoon this week (see above and yesterday for the actual exercise and the day before for the setup of why we are doing this!).

Please read over the past two days so you get some decent context about what I am about to cover next. It is that important (smile).

After everyone is sitting down and breathing they may actually be looking at you like, “OK, Why the heck have we done this exercise?”

First question for you to think about, then I will go about explaining why we do what we do here.

So.

Why do you think this exercise is done.

Take a moment and think about that before continuing.

I will still be here!

OK. Now that you are back… let me go into how I debrief this exercise.

First, I ask people, “How did this exercise feel?”

Leave it open ended.

And.

Shut up and let someone talk.

They will. They always do. Really.

Depending on the answers, I then take them through a guided tour of the three parts, and then ask a lot of open ended questions about the purpose of each section.

One of the things I constantly work on as both a ScrumMaster and Certified Scrum Trainer is learning how to shut up and listen — and NOT answer the questions I ask. This is a constant struggle for me and something that was pointed while I was co-teaching a class about six months ago; since then I have made sure I am aware of when I do this.

Sorry for the small tangent but I think it is important for you, my reader, that this will be a constant struggle going forward (if it is not — let me know how you are handling it!).

So.

For the first section I ask the “managers” how it felt for them. And let them talk.

Then, I turn it around to the “workers” — and how it felt for them. And. Let them talk.

This starts some light bulbs going off in some of their heads. This is a good thing.

And I point out how few (mainly by asking again) how few people completed this exercise.

No matter where I do this in the world — and it is a lot of places — the results do not vary that much.

So. It is not just a “North American” or “European” or “Indian” or “Insert your country here” thing.

Cool to see in action.

Next, I ask people who “finished” the second part of the exercise.

Almost all do.

Why?

Because they were given instructions on what the end goal was, and they knew how to do it.

It is not rocket science.

And.

Think about how to apply this on your Scrum Team.

It is that easy.

The next section was introduced to me earlier this year and I have had mixed results with it — to my surprise (wow… even I can still get shocked at results LOL).

When I ask people to become “blind” (about a third of the people attending the workshop) and give them the exact same directions as part two of the exercise…. teams doing this do one of two things. They automatically help each other or they let the blind crash into things and other people.

Wow.

How true to life is this on your team today?

How can you change that going forward?

This part of the exercises is reflected upon pretty regularly throughout the remainder of the workshop. And as the days go on, people start to see what this means in their current environment.

Is this something that has opened your eyes?

Will anything change?

Who will initiate that change?

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!

Thanks for sticking with us last week. We lost a few subscribers but by the end of the week we saw a large net increase. So thank you for helping me get the word out on this site and blog.

I also got some great feedback and ideas for content in the future.

Keep it coming please.

This week we conclude the three part series on the process of hiring a new ScrumMaster.

Part one is here.
Part two is here.
Part three is below (smile).

Part one talked about what a typical HR department posts when frankly, they are clueless on what they really need. The point here is to remember to work with the people posting the positions to make it realistic to what your team is looking to hire.

Really.

Part two talked about the interviewing process. Wow. This can be complicated – for both the potential scrummaster and the team that person may be working with.

Make it fun if you can.

Notice in the comic strip this week that the chicken did not make the final call for selecting a ScrumMaster.

Who should?

The pigs (or the scrum team).

Really.

Why?

Remember this person who will be filling the role of a ScrumMaster for the team is going to be working with the team on a daily basis.

What does a certified ScrumMaster do?

It depends on the circumstance. As I was reminded in a comment from my last comic strip (see the comment at the bottom and feel free to add to it!).

Some teams may actually like and receive a ScrumMaster who professes Scrum as the Silver Bullet.

Personally… I have not seen this work effectively; however, remember that is what I have found working with the teams around the world.

Remember though… everyone is different and we need to remember situations and teams need different things depending on their — or your — needs.

The last part of this comic strip talks about the possible need for a ScrumMaster to have to sit through the class for training anyway (and no it is not just to learn the “Secret Handshake of a ScrumMaster” (sigh).

Or.

Whatever training the Organization requires.

Read that last sentence and remember it!

Sometimes it is like the Dilbert comic I think many people have seen (and sent me!) this week. More on that later I think (smile)… this posting is long enough for today!

So.

What are you going to do differently when hiring your next ScrumMaster?

Anything?

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!

So. Last week I wrote about the atrocities I am seeing out there today in trying to fill new spots with the role of a ScrumMaster.

Wow.

It is amazing what people are doing.

As the comic strip above depicts, it is not always an easy thing to do.

So what should you be looking for in a new ScrumMaster — or someone to come in and coach some of your new Certified ScrumMasters?

One word.

Sorry… make that two.

“Fail Fast.”

This is something I have found as a trait that successful ScrumMaster candidates I have worked with show as a great attribute.

“Huh Mike?” you may be asking yourself.

Let me put it to you this way.

If you are interviewing some Super-Duper-ScrumMaster who appears to walk-on-water and always-has-THE-answer, can I give you a solid word of advice?

RUN!

Fast.

Or throw the candidate some stupid, off-the-wall question like they used to do (maybe they still do) over at Uncle Bill’s house of pain?

I consider myself a good ScrumMaster and Certified Scrum Practitioner and Certified Scrum Trainer. I work with many clients around the world on those thorny “Scrum Issues” and, in reality, I do not give them the answers.

Instead, I try to work with them to see if they can come up with their own answers.

Now.

Many of my prospects (or sometimes clients) do not like that way of working with me. They want me to come in like “Captain Obvious” and save the day.

Over time, I have learned this is not the best way for me to be effective.

Or.

Some teams do not like to have to “figure out” their own issues.

Some teams do not like how it feels to, “Fail Fast.”

And.

This concerns me.

If someone comes in spewing some Scrum Religion BS silver bullet theory — be very cautious.

If someone comes in with some war wounds and is humbled to be in your presence…. it may be worth a further look and more conversation.

This is only my opinion.

But I have seen it start to work in the real world.

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!

One of the topics I see a lot (in fact, after Tony sent me the comic over the weekend, I saw a similar question on one of the yahoo groups) is, “What is the value of a Certified ScrumMaster?” I have written about the topic here (wow this is the most popular comic strip on the site!) and a summary of others here (and talked about it in person all around the world).

This is not just a question I see in the USA. This is worldwide.

Remember this!

And.

The other question I see coming from this is, “Do I need to hire a Certified ScrumMaster help me?”

This week the comic depicts what a lot of Chickens struggle with.

And Pigs.

And even newly Certified ScrumMasters.

Really.

And it is OK.

But. And you knew a “but” would be coming….

I want you to help me get the word out to the various people looking to hire a Certified ScrumMaster that it is not as easy as “just” placing an ad on one of the online job boards and hoping you will come up with the right person.

Huh?

Just to remind myself that I am not totally insane (just a little, as people who know me can attest), I went out looking on some of the more popular job boards and did a search on a few keywords — like “Certified ScrumMaster” and “Scrum” and for kicks I did a combination of “PMP (or PMI) and Scrum” in various combinations.

Ug.

It is scary what is out there today.

As I was reminded last week during a CSM Workshop I was teaching, I should not keep promoting the “divide” between traditional waterfall method Project Managers and Certified ScrumMaster roles.

It got me thinking.

Wow. I do this. And it is not a good thing.

So. I will try — and this will be hard for me (and think about it… possibly anyone in the agile community) to compare “traditional project managers” with “Certified ScrumMaster” roles.

It is easy to do.

Should we keep doing it?

No. As it was pointed out to me, this keeps the two “camps” separate on a lot of occasions.

Wow.

OK.

So.

Read the comic strip above.

Are you — and your HR or purchasing people (for contractors) doing the same thing today?

The sad thing is this instance is not made up (it is a mixture of various ad postings we see today).

Next week, I will dive a little deeper into the process of interviewing people for the ScrumMaster position.

And why this Certification is of value. Really… there is value in having it!
This week, while I am teaching and working with clients, I will make sure I stop making the distinction between “traditional project managers” and “Certified ScrumMaster” roles.

Can I do it?

How about this.

I will try.

And. I will ask for feedback during the workshops (and please send it to me!).

And.

Next week I will report on my progress AND tell you about various interviewing techniques for hiring a Certified ScrumMaster.

It may be a few more comics before we are “done” with this topic.

It has a lot to be examined.

Where are you with doing this today?

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!

More to the point — useless meetings.

You know the type. Let’s have a meeting to have a meeting to discuss what we talked about at our last meeting and review what we have not completed but might get done before we have the next meeting in a few weeks.

Ug.

Breath.

This idea started with an email my wife got from a friend last week that basically said, “I am in a meeting and want to stick a pencil through my eye.”

I know the feeling.

This familiar to you?

Then… I am reading one of the copies of CIO Magazine (specific link here) from when I was gone last month and….

Let me recap what Scrum and “Meetings” have in common (this is correlating an the “five tips” talked about in the brief article I read by Diann Daniel):

1) Schedule only when necessary.

OK. In Scrum, you have a daily standup meeting. Fifteen minutes max. This is your daily planning.

You also have a Sprint Review meeting — where your outside stakeholders can come and see what is happening — working software is preferred.

You also have a Sprint Retrospective — where you and the team work on things that went well, went not-so-well, and what specific few items you can work on improving in your next iteration.

2) Reduce the frequency.

So it may seem that Scrum has a lot of “meetings” to some people.

Hmmm.

These “meetings” should ideally start turning into how people do work together on a daily basis.

3) Create an agenda.

This one is easy.

Daily — The three questions. What have you done since yesterday, what are you going to do today, and what are your impediments.

Keep it simple.

4) Recap.

If there are impediments (things in your way)… the ScrumMaster is responsible for making sure the impediments get removed. This does not mean the ScrumMaster must remove them; however, it usually takes a ScrumMaster role to make sure that things are getting out of your way. One of the ways this gets accomplished is by working with the team in showing them how to remove their own impediments. Cool when it works.

5) Do the minutes.

So in Scrum (and agile in general) one of the items in the Agile Manifesto is, “Working software over comprehensive documentation.” To me, this means that you should not ignore the fact that risks (possibly impediments) need to be tracked in an organization (see my blog entry on compliance!). Remember though… do not overkill it. Do what is needed and move on.

When people are transitioning from “old waterfall” development techniques to this agile stuff (Scrum in particular), sometimes they have a hard time remembering that the old ways they did meetings were ineffective and gave people a bad taste in their mouths (translation: UGGGGGGG WHY AM I HERE?!@@?).

As a ScrumMaster, part of your daily workings with the team will involve them in talking to one another.

Some people call that “meeting.”

Time to get over it and start working together.

Getting some ideas of how to help get this working in your organization?
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 introduced each of these topics during the month (with a blog entry about my trip to Russia, and no real follow-up from Kyiv — which was awesome too!). I received some feedback that some people may have been offended by the “picture” used in the “Bottom Up” approach. Oh well. I have learned long ago that I will not be able to please everyone. And for those of you who are still hanging around — and passing around this site to your friends and co-workers — remember my more controversial comic strip is the one I published at the beginning of this year; it is located here and is the most popular comic strip on this site, exceeding all my expectations and proving that controversial topics — at least with this audience — is working to get the message across.

So.

I told you two ways NOT to do it. Well… you can — and many do — but (or AND) do this with your eyes open.

One of the best ways I have seen at organizations being able to successfully implement Scrum in their environment is by using a combination of the two methods already discussed.

It is about common sense after all.

And.

It is about people. Not technology.

So.

What can you do if you are interested in rolling out Scrum and have a chance at successfully doing this?

Remember. 75% of organizations FAIL at implementing Scrum; they die a slow iterative and incremental death. You can read more about this here.

If I were implementing Scrum (which, by the way, is what I actually work with teams around the world doing in real life (smile)), I’d make sure that the executives within your organization have a clue of what this is going to take.

Be honest with them.

This is not a Silver Bullet.

Just because people go to a CSM Course (or, as I call it, a workshop), does not qualify them to run a Scrum Team.

If you can get to the executives within the organization, have them pick someone to be the executive sponsor of this thing.

Read the above sentence again.

Someone.

One person.

And make sure this person has some large shoulders and political clout to help provide “cover fire” when the team hits their first roadblock.

When.

Not, “If.”

And.

This executive sponsor needs to be able to let the team fail. And learn from their failure. And help soften the blow if it is a bad thing for the organization.

The team needs to be responsible and not let this person “hang” in the future by making the same mistake again.

Really.

The last thing you really want to do is have an executive sponsor who continually gets burned by their Scrum Team(s).

And.

The people actually doing the work (Pigs) need to REALLY have skin in the game.

The Scrum Team needs to act like responsible adults and understand what they are getting into.

It is not all fun and games.

OK. Sometimes we have fun and play games.

But.

Remember.

The goal is to always produce business value to your organization.

What does that mean?

It varies by organization type (the different “types” are listed above).

What does this mean for you as a ScrumMaster?

Keep your eyes open.

And.

Remember.

“A Dead ScrumMaster is a useless ScrumMaster.”

Enough said?

Have fun out there!
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!

Guess what?

A purely “Bottom Up” approach will yield much the same results.

Huh?

You may be asking yourself.

Mike…. what can you mean by this statement?

Here is a typical scenario I see using the “Bottom Up” approach….

A developer (and by this I mean anyone in the role of a tester, business analyst, coder, architect, bla bla bla techno-type-person) goes to a conference and gets fired up about some new methodology or framework to use in their environment.

Or, maybe they do not have a “conference” budget and can squeak a book budget out of their current manager (or wow… even buy it themselves!). You can check out great Agile Book recommendations here.

The point is, this person gets excited.

About Scrum. Of course.

“Wow.” They think.

“We have been doing a lot of what Scrum says but not calling it Scrum.”

[RED LIGHTS AND BIG DANGER SIGNS GO OFF IN MY HEAD WHEN I HEAR THIS.....]

It usually means there is nothing in place at this time to help the organization and they are hacking their way through a problem and looking a some major death marches [THAT makes me sad].

Or.

“Wow. This Scrum stuff looks like it is a Silver Bullet and will fix all my problems.”

It does not.

Scrum is not a Silver Bullet.

In fact, Scrum starts amplifying the dysfunctional areas within your organization.

Ouch.

Really?

Yes.

See…. the “problems” that usually start surfacing “because” of Scrum have always been there. Scrum is actually just making them more visible — and sometimes painful.

So.

It is doing the job it is supposed to do.

Now.

How does an organization handle this amplification of problems and issues?

Hmmmm….

Notice I said, “Organization.”

If one team starts trying to do this on their own and “fight” the current organizational boundaries…. to quote my last statement….

[Political Correctness OFF]

You are screwed.

[Political Correctness ON]

It is unfortunate and I have seen this time and time again.

A team is successful at implementing Scrum.

And.

All of the sudden, the rest of the organization starts seeing that they are successful.

Yikes.

Sometimes too successful.

And.

They get taken out behind the shed and, how can I put this…. get shot.

The organization rejects it.

And Scrum “fails.”

Hmmm.

So what to do?

I am saying a pure “Top Down” OR “Bottom Up” approach are not usually successful.

The next comic will address how to actually use a combination of these in order to be successful at implementing Scrum within an organization.

There is hope.

It can be done.

It is done every day!

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!

So if you are reading this post, I was not able to get to a computer this week to post a new cartoon.

I am on a vacation with my family where I may not have any internet access, so this is using some of the cool power of the new blogging platform on the site to send this to you.

Why would I even bother to post an entry when I am on vacation?

This is a reminder folks.

Talk time out and spend time with your family.

This work stuff will be there tomorrow.

I saw something interesting on TV the weekend before I left (my seven year old was sick ug)… we were looking at one of the Public Broadcasting stations and there was a continuous loop that was running with a message that said something like:

“Hey, it’s a great day outside. Go take your kid outside and play. Do something with them. Together. We are off the air from noon until three today so you can do this.”

I thought wow, that is neat.

And, because my poor kid was sick, I just changed the channel.

But.

The message came across to me.

We all need to spend time with our families.

And friends.

And significant others.

THAT is what is important.

Make a commitment THIS WEEK to do something different.

More next week…. I am bringing the family home to Washington, DC, and then flying out solo to Moscow and Kyiv to teach some classes for the following two weeks.

No rest for the weary.

So.

Take a break.

Breath.

It is good for you.

And everyone else!

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!