Modifying Scrum is a bad idea.

Do you hear me?  Do you REALLY think modifying Scrum is a good idea?

Why?

Scrum is a simple framework.  It works.

Yet, in most places I get called into for consulting with clients around the world, this is one of the major causes of projects failing.

People try to mess with it.  Because they know better.

OK… do that… then call me to come in and tell you to go back to the basics.  I make a great living doing this — but this is FREE advice.  Hey… if you still want to bring me in, call me and I will happily deliver this message to whoever you want (heck — I can even do this over the phone for you — what’s the worst that can happen, the receiver can hang up on me — not too bad for a five second telephone call!).

There is a reason that Scrum is a simple framework.

It’s supposed to be.

Think about it.

Most organizations — from very small to the largest enterprises — hire, employ, or contract very smart and intelligent people.  These very well-meaning very smart and intelligent people then think they can improve Scrum… before even understanding what power Scrum as a framework brings to the table.

Think about it.

Your organization is probably a political quagmire.  Most are.

If you are luck enough not to be in this situation, think of one of your favorite Dilbert Cartoons and laugh — this does happen in most places.

So… you have this political bullshit going on in the organization before Scrum.  As dysfunctional as it is, people have learned to thrive and succeed in this environment.  Actually the people that are dysfunctional created this dysfunctional system.  This could be you (ouch… hard to look in the mirror sometimes — trust me — I KNOW!!!).

Then you introduce Scrum.  And then an amazing thing happens.

Take a guess?

“Mike – Scrum is causing a lot of problems so we HAVE to modify it and make it better.”

“Mike – WE are different.”

OK.. on the first one… really really really look at what problems you think Scrum are causing.  I do a root cause analysis workshop with clients and usually almost ALL of the problems were there before Scrum was implemented.

Scrum exposes existing problems.

Get over it.  As a ScrumMaster, this is something you get paid to work with the Scrum Team, the Product Owner, and outside stakeholders to manage.  Put on your big kid pants and start having those tough conversations.

Yeah.

You are different.  And special.

But.

Um.

Use Scrum as the basic framework.

Watch.  Observe.

Inspect and Adapt.

Sound familiar?

Now does this comic strip make sense?

Let me know your thoughts!

Or… do as the majority of organizations who try to implement Scrum and fail — go back to what you were doing before and blame Scrum.  It’s a cop-out the industry (read: meaning people like you and me) still allows to happen.  Sad… but true.

Grow a spine and try to have a tough conversation TODAY!

[By the way - the original posting for this cartoon is located at http://www.implementingscrum.com/2008/05/06/kiss-keep-it-simple-stupid/

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

I hope you enjoyed last weeks posting and are looking forward to learning something new this week with me.  This is an important concept — we learn together (thank you!).  Please post comments below or tweet about this (or whatever other social media thing you use today!).

One of the big problems I see people talking about (and talking and talking — NOT DOING) is the concept of planning in Scrum.

Bottom line.  Instead of talking about it (and becoming stuck in analysis paralysis and NOT DELIVERING), do it.

How much time?

Enough to get started.

Really.  Get started on Delivering Working Software.

The original posting for this comic strip was about 2.5 years ago and um… wow… it was pretty politically incorrect.  Oh well… Blogs are timeless (smile).  That original posting talked about the rules for planning poker, about being on Fantasy Island (you may or may not be old enough to remember that show — google it), and quickly devolved into possible sexual innuendo.  Oops.  Or you are welcome (smile).  You can take a look at the original posting here.

So what really is “enough” to get started?

When you look at Scrum, there are so many opportunities to plan.  And execute.  And Deliver.

Remember the reason for using Scrum — DELIVER something of value to your customer and end users.  Reduce Risk.  Whatever.  Deliver.  Inspect and adapt.  Really. Hmm… Seems like I may be over using the words DELIVER and REALLY.  Wonder Why?  It needs repeating.  Really (smile).

You can do long range Release planning at the Product Backlog level.

You can do short term Sprint Planning at the Sprint Backlog level.

You can do Daily Planning and adjusting at the Daily Standup level.

You can track all this planning on different Burn Down Charts.

Plan plan plan.

Bla bla bla.

What does your customer really want?

Really?

Really?

ASK.

You can get stuck PLANNING for a long time.

DELIVER.  Get to DONE.

Yeah… you still need to PLAN in Scrum.

But what is REALLY important to your end users and customers.

Do they really care about the plan?

Hmmm… not if you keep missing deadlines and deliveries.  Plans then become a CYA (cover-your-ass) thing that opens the gulf of distrust even more between the team, the customers, and other stake holders.  Traditional Project Managers then use it to beat people over the head about missing dates.  You know the cycle.

So.

Stop it.

Plan enough.

This is one of the *tough* conversations you need to have with your stakeholders at all different levels.

I can promise you (from experience) — these conversations SUCK at the beginning.  Mostly because a traditional Project Manager has been making excuses for the team about missing dates (and using the Project Manager Whammy Stick to do strange things to the team).

As a ScrumMaster though — remember — who is REALLY responsible for delivering on a Scrum Team?

The Team.

Yeah, as a Scrum Master you are responsible for facilitating the process (or framework or whatever you want to call Scrum) AND making sure the Scrum Team understands their roles.  Oh… and also working with the Product Owner.  And Oh… the outside Stakeholders.  Welcome to reality.

This is real world stuff.

So how can you keep it from sucking?

Deliver.  Team — do you hear this? DELIVER.

And guess what… once you are delivering on your commitments the conversations shift to AWESOMEness.  Really.  This is not just my dream fantasy world.  It happens.  Daily.

It will suck wind at the beginning.

Plan.

Enough.

Execute.

Deliver.

Inspect and adapt.

That’s enough planning in Scrum.  Yes… DO IT.

AND.

Deliver!

Scrum is not a Silver Bullet.

Delivering builds confidence.

Try it.

Welcome to 2012.

Here we are.  Another year to look forward to.

Another year to look back on.

Looking back on 2011 for the blog at www.implementingscrum.com, I did not publish a lot of information.  However, an interesting thing continues to occur — people viewing the content (some of it now almost five years old) and subscribing to the updates has increased dramatically.

So.

Looking forward to 2012, here is my commitment to you, a valued member of this community (THANK YOU) so much.

I’ll take it up a notch and start paddling again.

Like any great ScrumMaster or Agile Coach, I have to keep at it with this blog because there is so much information we all still need to share.

That’s my commitment for 2012.  You’ll be hearing from me at least on a weekly basis with new cartoons (or at least new commentaries from me!) and updates on my latest and greatest stuff.

What’s yours?

Are you going to start paddling again?

Good luck.  Commit here if you’d like, and let’s see where we go this year together.

Thank you!

- mike vizdos (Follow me on twitter @mvizdos and Facebook)

PS – You may remember this original comic strip from 2008 (wow time flies), it is located at: www.implementingscrum.com/2008/04/21/up-the-creek-without-a-paddle/ 

Scrum Training today is available in many different flavors and formats around the world.

People are always debating the values of “certification” and this will be an endless discussion.  While everyone is having these discussions (yawn to me), I continue to travel the world training people on Scrum.  And other agile techniques.  I also *use* this stuff daily  to run my company (more on this in another posting) and coach individuals to help us both keep improving our skills.

Welcome back to the ImplementingScrum site.  If this is your first time here, take a peek around.  There is a TON of information here.  This site has been around for almost five years now, and while some of the ways I implement techniques today are different (they keep improving) the comic strips here usually start some good conversations.

So I selected one of the most popular and un-politically-correct comic strips from a posting I published a LONG time ago (take a look at it here — cute, and wow that was so long ago in this internet age we live in today).  I have mostly been using things like Twitter and FaceBook (and others) to get information out — but also realize this channel of communicating with people (via the blog) is important… so it is [again] restarting with more postings of my [possible rants] in the future!

And. I titled this blog posting pretty provocatively.

I know the combination of un-politically-correct and provocative will help open conversations.  Who knows what kind of conversations, but hey that is up to you!

THAT is the important thing with this blog.  People either love it or hate it, but talk about it.

So… Let’s bring that to the topic of “Certified Scrum Training – Debunking the Bullshit.”

This should be fun, huh?  I figure if you are still with me than you are wondering why this is  important.

I am a Certified Scrum Trainer and that is a trademarked name from the Scrum Alliance, the body that certifies people who have taken my class as Certified ScrumMasters.

It does not certify competency.  It cannot.  OK… Like it or leave it, that’s an established fact (that people will debate!).

It does certify people who have taken the workshop have paid their money, the Certified Scrum Trainer has paid the Scrum Alliance a $50.00 fee so that they can take the assessment and become members (all Certified Scrum Trainers must do that).  And you can do a lot more with the Scrum Alliance — and should.  Here is some good background information from the Scrum Alliance FAQ that tells you how to move forward with them after you are a Certified ScrumMaster.

There are still a limited number of Certified Scrum Trainers in the world.  The market is showing that there is still a pretty strong demand for this type of Certification.  Why is there a demand?  People want it (possibly not the people taking the workshop — could  be their bosses or organizations are forcing them to attend or organizations want to send one person expecting that the newly Certified ScrumMaster can train the rest of the organization).  All of those statements are up for debate, and will always be debated.

Fine.

Move on with the debate.

So if it is so controversial, why do I do it?

I LOVE teaching this workshop.  I have fun.  I learn.  Every time.  Every place.

Here is a current description of what it is like to take the workshop with me… www.michaelvizdos.com/experiential-csm.

It has evolved (and will continue after each workshop, as no one is ever the same).

People who have taken the Certified ScrumMaster Training Workshop with me are usually satisfied.  I know I cannot solve problems for all of the attendees — that is not the purpose.

The purpose of the Certified ScrumMaster Training Workshop that people attend with me today (and remember it continues to evolve) is to learn about Scrum in an experiential way.  They should be able to answer questions about Scrum on their own by the end of the two days — using the framework and experiences from attending.

People who attend my Certified ScrumMaster Training Workshop receive a lot of value — because it is an environment where people can learn (from me and mostly the other attendees).  My training is different than any other Certified Scrum Trainer.  It should be (other organizations disagree and that is OK).

I also tell every attendee that this will not make them experts at being a ScrumMaster, Product Owner, or Team Member.

In fact, I now understand  that each individual will walk out at the end of the two days latching onto only one or two things that we discussed AND that fits into their current world paradigm (it used to bug me, now it does not).

Wow.

Two days… and only one or two key things (that was said and they heard what they wanted to hear).

Is this cutting through the bullshit of debates and bla bla bla out there about Scrum Certification?

I am sure there is SO much more that can (and will be) said on this topic.  Like I said up front, this is a provocative and controversial topic.

And the purpose of this blog over the years has evolved into learning about how to have tough conversations about Software Development.

Yes… Scrum can be used outside of Software Development (another topic for later again!!) but here’s the thing…

Talk about this stuff all you want.

Get out there and practice it.

Thank you!

Looking forward to hearing comments, suggestions, and ideas on here, in FaceBook, GooglePlus, or however else you want.

Talk.

But do.

Go….

With Scrum, and Scrum Teams, similar things can also be said.

Take for instance this blog posting about Scrum and Social Networking.

Over three years ago, the social networking thing was just catching on.

Five years ago, twitter did not exist (or about a dozen people were using it).  Facebook is now a huge.  LinkedIn has gone public.  Plaxo.. well… um… I am not even sure this is running anymore (for me at least).

This is one of the first postings from me you have seen in a while on ImplementingScrum.com.

Why?

Well… as technology has changed so have my habits of communicating information (and maybe yours?).

My habits today include posting things on my personal FaceBook Page; however, like a lot of you who mix business and personal stuff… things got out of control (again… perhaps this has happened to you?).  I recently created a new FaceBook Page for me as “VizdosEnterprises”  – this clean-up has helped me keep my friends as friends and now people who are really connected to me as a company well, as a professional.  You can follow my future world travels there.  It’s how we communicate today, so please feel free to “like” it!

I am on twitter a lot as mvizdos and tweeting lots of random information.  Eventually I may separate out that to business stuff too.  But I also know that twitter is for small stuff that is at the moment.  And it comes from “me” still (smile).  On that note… I’ll remind you of the power of Twitter and relationships some time in the future.

LinkedIn is powerful — I am still not utilizing it enough.

Which brings us back to this blog.  It has been around for almost five years and has gone through many iterations and changes.

The fact remains that people love the cartoons (or hate them… and that’s OK with me too).

They are making a difference.

So.

I will continue to examine some of the older comic strips on this site and re-write some new ideas on the topics.  Maybe even create some new ones (smile).  I’d also invite you to let me know if you want to write a guest posting.

You are a member of a worldwide group of people who really care about making a difference.

Let’s continue doing that.

So… you’ll see me in social media and you’ll start seeing more postings here with the comic strips.

Because that what this site is about.

Comic strips about Scrum and starting difficult conversations.  Like this one… may not seem difficult to you (or important), but I thought it would be good to get stuff into the open with you.

Let’s see where we go from here.

Until then, enjoy this comic strip.

And.

Think about how all these changes can be applied in your Scrum world today?

Welcome back to yet another week at www.implementingscrum.com.  I appreciate all the comments from the last posting and comic strip, and it feels good for me to get back into posting the comics and new thoughts.

It seems like you enjoy them too (thank you).

If you ARE in this situation, start the difficult conversations today about how to fix it… and SHARE this posting within your organization.

If you are NOT in this situation, well… count yourself lucky and SHARE this posting with your friends who might be in the following situation!

Is your organization struggling to come up with an “Enterprise Plan” for rolling out Agile [and Scrum in particular]?

I am working with clients today that have a similar problem.  I have worked with many many many large [and small] enterprises over the years and have seen many patterns that work.  I have also been personally involved with ideas that have failed (and yeah, some were even my ideas).

Here is the number one reason I have seen that “Enterprise Rollouts” of Agile and Scrum FAIL:

They try to implement it too fast and furious.

Does this sound familiar?

Here is some great advice (and I know most people will ignore it AND possibly even disagree with me) for successfully rolling out Agile and Scrum projects:

Start with ONE project.

That’s it.  Sound too easy?  Hmm… Remember that the easiest and obvious answer may be that way for a reason!

“But Mike,” people say to me.

“WE are different.”

“WE need to get our entire portfolio up and running using Agile and Scrum across the worldwide distributed enterprise so that we can get metrics and tools in place to increase our time to market, lower costs, and make everyone feel like it is a party coming to work every day.”

OK… so the “party” part in that last statement was made up by me (smile).  Just making sure you are with me.

The idea that, “We are different” and “we need to do bla bla bla bla” ALL RIGHT NOW will kill your Agile and Scrum implementation.

Don’t believe me?

OK… try it and get back to me.  Or… continue down this thread with me….

If you are jumping on the Agile Bandwagon and using Scrum to transform your entire enterprise because “everyone else is now doing it” (yeah… Agile and Scrum have hit mainstream!) here is another word of advice.

STOP.

Right now.

Please.

Remember it took your organization years (and maybe decades) to paint yourself into the corner you are in today.  Your organization has probably spent years coming up with incredibly complicated frameworks, processes, or  methodologies to get things done.  People have been promoted and rewarded for building empires and silos of expertise.

You also know that if you keep doing this, you are screwed.

Because your competitors are now all “Agile” and a lot are using this thing called “Scrum.”

There is still a major failure rate out there using Scrum (and the other Agile techniques).

Why is this?

Organizations — made up of really smart people (usually) — are making one of the greatest and most common mistakes in history… trying to inject too much change at one time.

Remember what happens when you try to do this (on a regular basis even)?

The organization will always always always go back to the way it was.

Dysfunctional.

Comfortable, but Dysfunctional.

AND… just as screwed as before you wanted to start this Enterprise Rollout of Agile and Scrum.

So.

Listen.

PLEASE.

If you are just getting started (or have already been down the path to where now “Scrum” or “Agile” is a bad and forbidden word in your organization) with a Scrum and Agile change management process….

Start with ONE Scrum project.

Get Executive Sponsorship as high up into the organization as possible (they need to take the fire cover for you and will be burning political favors).

Worry about scaling it later.

Otherwise, you’ll be just as comfortably dysfunctional and screwed at the end of the day.

Don’t believe me?

That’s OK.

Your competitors do.

Let me know your thoughts.

I am listening!

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

And yeah, it’s been a long hiatus from my contributions to this site (by the way… for those of you who do not know… my name is Michael Vizdos and I am solely responsible for all content on this blog… it is not a huge corporate entity or machine — it is a way for the two of us to communicate).

So much has changed since starting this site in 2006.  Life — both personal and professional — has changed in many ways for me.

What about you?

In trying to figure out how to get things restarted here, I thought this would be an appropriate comic strip (originally posted as http://www.implementingscrum.com/2008/04/21/up-the-creek-without-a-paddle/ years ago).

See… in all the traveling and working (on personal and professional stuff over the past few years)… I have learned that the stuff I write about and post on this site IS important and DOES have an impact.

And.

I stopped paddling.  Stopped posting.  And kept watching — in amazement and awe — how this site kept growing and growing without me doing anything.

Yikes.  I need to step up and start contributing once again.

Much of the “work work” I do today involves training (still — but not as much as the past!) the Certified ScrumMaster Workshop.  It is an aweome experience — described as *life changing* by many attendees and has evolved dramatically.

The major shift of this training workshop is because I am seeing that most people in the industry today seem “OK” with Scrum being almost ho-hum-bla-bla-bla (well… maybe except for Jeff Sutherland, who continues to kick my ass to up my game [and probably does not know he has this impact on me]).

Scrum involves a lot of work.

This is where I am spending most of my time with work today — facilitating teams that are having a hard time with keeping the paddle moving against this never-ending tide of change resistance.

Fun stuff for me.

It is failing all over the place now… and there are a lot of blog entries dedicated to writing and discussing this.

Me… I want to focus on the positive.

And the tough stuff.

Professionally I am now at a point where I can — and DO — select my clients (as much as they select me for whatever reasons [which I am extremely grateful for!].

And.

I am really now only selecting to work with people who WANT to be successful with using Scrum — and the other agile techniques that are also required for a successful organizational change to occur.

It takes time.

It does not happen overnight.

I am proof of that (smile).

So… Here I go again.

I’ve looked at myself and have seen and recognized that I “stopped paddling” and well… it had a lot of consequences (both good and bad).

My choice now with this site is to start paddling again and keep pushing things forward.

It starts with you and me.  Just two people.  We are all that matters to get things going together.

Are you ready to start again with me?

I’ll ask for feedback continually… much like a great ScrumMaster needs to do.

Time to get back in the boat.

Here we go!

When you think of estimating and planning techniques in Scrum, what method do you think of first?

Wait.

“There is an official way Scrum says you *must* do estimating and planning,” you may be thinking.

You’d be incorrect.

And.

Thats OK.

See, there is nothing in Scrum that says you have to use any certain technique for estimating and planning.

My recommendation though:

DO SOMETHING.

People will continue arguing about the different techniques for-e-v-e-rrrrrrrrrrrrrrrrrrrrrrrrrrrr.

So what.

If you have something that works today, use it.

If you do not have a clue about how to do estimation and planning, or think:

“Hey we are using Scrum and we do not need to tell the customer when we are going to finish….”

Um… try telling your customer that.  Let me know how that goes, because I can pretty much guarantee that answer will not invoke any confidence in your delivery as a team.

Remember, your customer does not care about story points or gummy bears or peanuts or t-shirt sizes or dart boards or ouiga boards or whatever.

Ask the customer what they really care about.

THE answer to that question may rock your universe.

So.

What kind of estimation and planning techniques are you using today?

What works?

What fails?

Please feel free to discuss these and other answers about this topic in the comments of this thread.

Phew.

See.

I did something today for YOU.

Instead of estimating and planning on when this next cartoon strip would get to you… I just did it.

THAT is why people are reading this (you are my customer as someone who reads this blog, and I thank you for that!).

Original Posting: March 4, 2008

As many of you know, next week is a HUGE conference in Orlando, Florida.   The comic strip above was created a few years ago when I was speaking at a different conference, but I wanted to re-post it for both the people who ARE and ARE NOT going to the conference.

The original posting addressed seven things I try to do to get the most value out of any conference setting.  I encourage you to review those tips — or see them for the first time — here.

So… first… for those of you NOT going… I will be posting a lot of real time information of my happenings there via twitter (this is really micro-level blogging these days!) and on FaceBook for larger thoughts than just 140 characters.  For those of you who know about hash tags and groups on Twitter and FaceBook… look into  those.

Why is this important if you are NOT going?

You’ll get some great tidbits of information from me and a bunch of other people who will be on the ground there.  Meeting.  Face-to-Face.  Hearing about stuff both inside and outside the Scrum World.  Because this really is important to what we do on a daily basis.

And.

Last week I announced to my e-mail followers that I have listened and will not post much more than new (or re-purposed — like this one) comic strips about Implementing Scrum on this blog.  For those of you interested in following my fun travel exploits (well, I think they are fun… but yeah… outside the scope of this!) and other stuff that I’ll blog about outside of Scrum — head over to www.michaelvizdos.com and subscribe via email (you’ll see how to do it there!).   I will be adding an RSS Feed there soon, but it is not up yet.

For those of you who WILL be going — or know people who will be going — please review the seven tips here.   Help pass on the word about these tips!

If you have more tips or suggestions — please add them to the comments section of this entry.

I am making the personal investment to head down to the conference to meet people — both new and those who I have not seen in a while.

I am not speaking at this conference.

For me, it is ALL about the networking.  Meeting PEOPLE.  Real People.  Outside of the side of the screen you are reading now!

This is also one of the first postings in a long time on this site, and I know the important thing about this site is the comic strips and how they can help people start tough conversations.

Some of the toughest conversations always need to take place face-to-face.

It does not matter if you are heading to the conference or not… the important thing to reflect on with this comic strip is to make sure you get out into the world once in a while — especially in this industry.

A lot of changes are happening on a constant basis.

The updated focus of this blog going forward is to start reminding myself and you that it is VERY important to have tough conversations.

Get out there and start.

Maybe it is just with the person sitting next to you….

Or… Maybe we can meet face to face — contact me if you are interested!

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.

[Note: January 11,2012 -- An updated blog posting about this comic strip is located at: http://www.implementingscrum.com/2012/01/11/scrum-planning-its-important-and-misunderstood-you-have-to-plan/]
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.

[After you read this you may want to check out an updated posting to this cartoon at: http://www.implementingscrum.com/2012/01/04/scrummasters-feel-like-giving-up-sometimes/]

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!