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

I am amazed at how people keep trying the "change" Scrum.

What do I mean by this?

Well.  It seems like there are people out there trying to add new "types" of Scrum.  

And it seems like this topic rears it ugly head (meaning it "shows up") pretty regularly in different discussions and on different boards.

You will see "Scrum Type A, B, and C" as some examples of this "evolution."

What do the different Scrum Types looks like?

Scrum Type A

This seems to be the classic, by the book way Scrum is taught.  An iteration (or Sprint) starts and stops at regular intervals.

Scrum Type B

This is where Sprints start "overlapping."  Ug.

Scrum Type C

This is where there are basically continuous - and overlapping -- Sprints.   Jeff Sutherland (one of the creators of Scrum, not normally mentioned) - Explains "Type C" here.
 
Ummm.

And the scary thing is, there are probably many more "types" of Scrum out there.

At the end of the day though, really, Scrum boils back down to doing the basics.

Ken Schwaber has addressed this publicly (and privately at meetings I have attended with other Certified Scrum Trainers). 

Here is one of his comments (from a yahoo group posting):

"There is only one Scrum... There are many ways to fill in its blanks to optimize productivity and ROI, but those vary with each situation. I may implement Scrum differently if there is hardware and software involved, if there are various levels of engagement throughout the enterprise, if the engineers are more or less competent – but it is all Scrum."

So what is the big fuss?

I really do not know.

Seriously.

It is all the same stuff.

And.

I personally think the marketing around Scrum - one of the many available agile techniques for software development - is tough enough to try to explain, teach, and implement to both people inside and outside of the software development industry.

Does it really matter about the different "types?"

No.

Really.

If this religious dogma of "typing" Scrum continues (and I am urging, along with others, to stop this nonsense) I guess I should claim "Type V" now.

Scrum - Type V 

(for Vizdos, pretty creative, huh?).

This would be where all teams actually use Scrum (as Scrum should be used!) and really get it.  And then all the Scrum Teams out there actively print out all our cartoons from ImplementingScrum.com (all are available here!) and use them as teaching and learning aids.  And each and every person implementing "Type V" Scrum would send out all their own favorite cartoons from the site to people they know (wow, you can do that from each page by using that "tell a friend" link!) and link back to them from their own sites (both internally and externally for the world to share).

But wait.

Sorry.

And (use AND not BUT).

Um.

This differs from the way you are using Scrum today in what way?

Thought so.

Scrum = Scrum at the end of the day.

Gotta run....

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

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

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

One of the tools a ScrumMaster needs in their toolbox is the ability to both give and receive feedback.

Is this you?

And.

Be able to teach others to be able to do the same.

This is one of the ways a team can become "high performing" and really start to surprise everyone -- including the team itself.

This is hard stuff. It looks easy on paper... but as with many things when you try to do this in real life, things can get tough.

Here is a format I use during my Certified ScrumMaster Workshops:

How to GIVE feedback

Start with an opening

Stan, can I talk to you for a minute…

Provide data NOT opinion

...in the meeting this morning when you said...

Talk about the impact on YOU, avoid speaking for others

…it made me feel uncomfortable and distracted me…

Make a request for change.

Please bla bla bla.




That's it. Pretty easy, huh?




Come up with some hypothetical examples and run through them. Need some? Let me know.



Hmm. Sometimes this is not easy to do. Can you see why this is the case?


And that is normal.


And.

It is OK.

Really.





So what about receiving feedback?

How to RECEIVE feedback

1. Breathe
2. Stay calm and listen
3. Ask for clarity
4. Don’t interrupt, but if you aren’t getting what you need (data) then ask for it
5. Use what you can
6. Remember it’s information not praise or blame
7. Know when enough is enough
8. If you are being overwhelmed ask for some time to digest it.

Gotta run....

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

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

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

Eeek. This may hurt a bit.

Sometimes you gotta face things head on. As regular readers know by now, I do not shy away from tough stuff.

In recent history in the blogging world -- and elsewhere -- I have been seeing a lot of claims that Scrum (and the courses etc.) are hype and people are victims of snake oil sales people.

For those that do not know what a snake oil sales person is, this person sells something for a "cure" that they know does not do anything in reality.

Yikes.

Am I selling snake oil?

Shoot. I *use* it and know it works.

For me.

Gulp.

And, I teach people the skills to become a ScrumMaster in their own organizations (both formally in a class and by mentoring different clients). I say "teach" in a term that also reminds me that I usually "learn" with each new and unique experiences.

And, it works for them.

Sometimes.

It is hard?

No. Maybe.

Yes.

And (smile).

When you put people into the mix (you know -- human beings -- not "resources") anything can happen. And it does.

Scrum is not a Silver Bullet.

The Certified ScrumMaster Workshop does not make you "certifiable" to be a ScrumMaster, even with the crazy name. And. I do not hide that fact anywhere. I have yet to have any person in one of my workshops who was forced to be there; each and every person did their research and wanted to learn more about this Scrum stuff.

Scrum is not rocket science.

And.

Many organizations cannot handle what Scrum exposes. And it dies or fades away (see this link for part one of a three part series) or an organization continues to face the challenges Scrum exposes.

Snake oil?

I make no claims that this stuff is easy.

And (geesh... I really want to say "but" here LOL).

It works.

For me.

And at the end of the day, if I try something and it actually works, who cares what other people think. This is not third grade.

If you have read about Scrum (or worse yet -- have never even read anything about it) and never tried it, shut up and quit whining about it. Really. Go away. Please. Do something productive with your time.

Ouch. There. I said it. And stand behind it.

If you have read about Scrum and actually tried it, and found it does not (or did not) work for you, STOP. Really.

And finally....

If you have read about Scrum and actually tried it, and find it works for you and the team, learn more. Improve. Really.

Have a great week.

Gotta run....

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

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

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

The term "Agile" means different things to different people. It should not.

But.

It does.

And, as I hope you are learning from reading this blog, this is OK and you should accept the fact.

Going religious-zealot on anyone will not help.

Trust me on this one (smile).

So. Am I going to cross a chasm today by saying something that people may disagree with? Maybe.

But.

It is reality.

Now. Remember, Scrum is an agile technique that focuses on the team and its delivery of working software at regular increments. It does not deal with what I will call "engineering practices."

So?

Well, there is an Agile practice that works well WITH Scrum, and it is called extreme programming -- or "XP" for short. The topics that are focused on while using XP are those that engineering teams normally wind up requesting at some point when working on an agile project.

And this is OK.

Read up on XP. It is a good tool to know and understand and to have in your agile toolbox.

And here is something else you may want to use with your teams when it -- and you will know when it is time.

A lot of times I go into teams that really do think they understand solid engineering practices.

And, sad to say, most of the times, they suck. OK. Maybe that is a bit harsh. How about, they are kidding themselves to think they could not use improvement.

Want a cool exercise to run with your team? It is something I have used successfully in the past, and you are free to modify and use it at will (although I can claim this is something I came up with in the past, it is derivative work off other exercises that may seem similar).

Get a few big sheets butcher paper and have lots of different little sticky notes.

Draw a line across the paper.

On the left side write, "Hacking."

On the right side write, "Solid Engineering Practices."

Now, have the team talk about what makes up solid engineering practices versus hacking away at code.

This can be a great facilitated discussion oh ScrumMaster.

Now, have the team members individually write what they think are hacking versus solid engineering practices.

One per yellow sticky.

And post it along the continuum drawn on the wall with the butcher paper.

What do you see?

It may amaze you.

Now.

Have the team identify three or four things they can start working on *today* to start improving their engineering practices.

Yes.

Scrum does not talk about engineering practices.

But guess what?

Your Scrum Team needs to develop working software.

And solid engineering practices are needed.

In the real world.

Let's chat more if you have questions on the technique or let me know how it goes with your team. I can write more about this if you are interested.

It is pretty enlightening each time I work with a team on this exercise.

What they do with it is up to the team.

Remember that!

Gotta run....

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

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

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

This week we conclude our first "series" of cartoons. If this is your first visit, please check out episode #1 and episode #2 before continuing... it may add a bit of context behind what I am about to tell you next.

Sit down.

And listen. This is important.

Really (smile).

If you are on a Scrum Team, either as the ScrumMaster, Product Owner, or Team Member and are looking around your team room today asking yourself, "Why the heck are we using Scrum on this project," you are not alone.

It turns out that the majority of projects that start using Scrum actually fail.

Wow.

This supports my statement that Scrum is not a "Silver Bullet" for software development.

If your team is not working out.... I would not recommend doing what our intrepid ScrumMaster above is saying to the team, because the response will probably be much the same.

Gulp.

So what the heck do you do?

Try using Scrum.

If things are not going well, make sure you are following "the basics" of Scrum. It is not Rocket Science.

Take a look around this site and do some research on the Internet -- there is a lot out there to help you.

However.

And this is a big one.

If it is not working, STOP calling it Scrum and move on.

If not, you can pretty much guarantee yourself and the team of dying a slow, iterative, and incremental death march.

Do you understand the implications of the above statement?

Really?

Gotta run....

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

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

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

When we last left our intrepid ScrumMaster, he was finishing a journey to the top of a large mountaintop. Only he realized it was just another beginning once he reached his final destination. What a strange dichotomy.

Knowing he had only one question to ask of the one who knows all, he started to feel a bit of pressure.

One question.

Only.

One.

Phew.

The pressure was on.

What question would he ask?

Amazing at how sometimes life truly imitate art (or, in our case, being a ScrumMaster). One week ago this evening I was climbing to the top of a mountain retreat. Instead of heading there to learn something, I was going to teach a two day Certified ScrumMaster Workshop. By the end of the week, it was I who had learned the most (although I am sure the students of this class walked away with some cool new insights about Scrum and how it applies in the real world!).

So.

Back to the question. It actually is one I have been pondering for a few weeks.

"What if a team REJECTS Scrum?"

I have had a lot of experience with organizations (who are made up of many teams -- using Scrum and not) implementing Scrum.

And.

I have had to get used to the idea -- based on experience -- that not all organizations, or teams, actually DO successfully implement Scrum.

Scrum is not that "Silver Bullet" I kept saying to people that is was not.

And it is not.

Even to "me" as a ScrumMaster.

So Ken Schwaber and I had a conversation (it was brief.... via email... not me actually having to climb to the top of a mountain to speak with him (smile)).

Am I the only ScrumMaster experiencing this trend?

Could it just be *me*, I wondered?

Am I really worthy of coaching other ScrumMaster's and their teams who are implementing Scrum today -- and in the future?

And I found out something amazing.

Only about one out of four teams are successful implementing Scrum.

25%.

"Wow," I thought.

This fact -- even if it is based just on experience from others in the industry -- hit me like a ton of bricks (this means it made a big impression on me, oh readers not from the USA).

Personally I am seeing better than this twenty-five percent success rate with Scrum. Some organizations (remember, who are made up of teams) are much higher than this (that is, they really are successful using this framework!).

And then I realized.

It probably has *nothing* to do with me or my skills as a ScrumMaster.

Stop and think about this.

I did.

And it made me feel very humbled.

Silence.

So now I am faced with the fact that, "OK. The majority of teams fail using Scrum."

Really.

And the other 75% will start to go back to their, "Old Habits."

Which means most will go back and "die" what is being called an, ".... iterative and incremental death march."

Think about that statement.

And what it means to you, as a ScrumMaster (or a member of a Scrum Team).

And what it means to your Scrum Team as a whole.

And then, what it means to your organization.

Sometimes, no matter what *you* personally do -- no matter how hard you try -- Scrum will fail.

OK... so "Scrum" will not "fail."

The team, or organization, will not be able to handle what Scrum exposes on a daily basis. And this is a hard thing to swallow (err.... let me think.... how about "hard to understand and accept").

So.

As a ScrumMaster.... you need to deal with the fact -- and accept this as a fact -- that no matter what you do, and no matter how well you do it.... things will most likely blow up within an organization and they will not continue using Scrum.

They will go back to the old habits I have been writing about and talking about for years. Because sometimes it is just easier than facing the truth and working to improve yourself as a team or organization.

The truth hurts.

Brutally.

Yikes.

Is this something as a ScrumMaster you are able to accept?

And move on?

Something to think about for next week's final installment of this series.

What *do* you do if your team is not succeeding with Scrum?

Or, what if your Scrum Team is succeeding and your organization is rejecting it?

Think about it.

Seriously.

Because.

The majority of time, Scrum does not work in an organization.

More next week.

Gotta run....

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

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

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

So I do not know if you know that I realized that we did not have a comic strip posted last week. This was by design. And, it can happen in real life!

Sometimes the ScrumMaster stops working with the team. To go learn some new things. While I was "gone" -- i did send information as I learned it. Both the good and bad.

So, while, in reality I have spent last week in Kyiv and this week I will be in Hungary.... I want to take this week to introduce the first of a three part series.

This is something that has been eating at me (bugging the heck out of me) (keeping me up at night) (worrying about) (etc.)........

Unbeknownst to the Scrum Team in this cartoon, our ScrumMaster has quietly faded from the team room in order to go get some help.

Along the way, the people he went to get more help kept telling him to go to other places.

Eventually, our intrepid ScrumMaster wound up at a very unusual place -- both physically and in his own personal and professional life.

Knowing he had only one question to ask of the one who knows all, he started to feel a bit of pressure.

One question.

Only.

One.

Phew.

The pressure is on.

What question will he ask?

Got it.

And we will address it next week!

Gotta run....

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

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

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

As I sit down this evening to write this, I am now sitting in a hotel room overlooking the Danube in Budapest, Hungary, at close to 10:00 at night and daylight is almost over (almost time to call home!). I left Kyiv this morning and have had a chance to look back and think about the almost four days I spent there, and what it means now (well, at least to me).

First, the CSM Workshop was attended by about 20 people from Kyiv and other places in the world. Most of the attendees worked for what I would consider "offshore" firms (you know, those great people that do work on an outsourced basis from the USA, Denmark, and other places?). It also included some direct customers of the offshore firms, which, when put together, created some awesome discussions and some new insights into the reality of working with Scrum.

The course normally runs for two full days, and this was no exception. When we got started, I took some pictures of the classroom setting. It was set-up lecture style and tables were spread really wide and used up most of the room (it was a good size for the attendees!). By the end of the two days, we took up about 1/2 the space and were sitting in "pods" -- and people were mostly sitting with and working with people they were not sitting with the day before. I say this (it may seem obvious to some) because in fact this is a lot of what Scrum teams go through -- or should -- on a regular basis. I may have encouraged it a bit by making some suggestions, but did not force anyone to do this (hmmm... sound familiar as what we must do as a ScrumMaster?).

Day one went much as it normally does. I cover a lot of the "basics" of Scum, and the point of this is to make sure people understand -- as a team or group -- what the common vocabulary should be according to "the books." In addition to this, I also inject my patented comments about reality-based Scrum.... "The book says this.... and you see bla bla bla a lot in reality." I cover this more on the second day. One of the great exercises we do is called the "59 minute Scrum" -- which is a simulation of a very non-technical based version of actually implementing Scrum. In other workshops, I usually allow participants to select which one to work on (there are three that I use, including things similar to "A Martian Tour of Earth", "Doggy DayCare", and "A Spam Brand Theme Park."

While I presented this in English, I allowed each group or table to use each discussion time (for the simulations and break-out discussions) to be completed in whatever language they decided (there was a mix of Russian, Ukrainian, English, and more represented). This was helpful for each table but put me at a slight disadvantage (although I could tell when they were getting off-topic somehow [lol]). We debriefed all exercises in English.

And I had to remind myself to speak slowly. Sometimes I know I did not. Ug. I am passionate about this topic, and I can get to speaking quickly. I apologize (and apologizED during the workshop).

I decided to just assign the "Spam Brand" theme park to all the tables to make the discussions similar; also, when I asked about "Doggy DayCare" I got blank stares and heard crickets (for those that do not know this, in the US when people go on vacation/holiday they drop off their dogs at a place where other dogs get pampered better (usually) than they do at home OR people drop off their dogs to play at these places during the day while they are at work). For the "Martian Tour of Earth" -- I joked that we may as well have called it "Mike Vizdos visiting Kyiv" (at least they laughed at that instead of the crickets and blank stares).

So we did Spam Brand Theme Parks (you know, like creating a Disney World like place based on that [insert whatever this really is made of] stuff called Spam (not e-mail spam -- ug.... let's see if email filters catch this one lol). It was great and there were some great discussions about this.

Lunch was great (some people did not like it). Liver. Yummy. If there is one thing I can say, i do still like to try the local food (burp... had a cup of Hungarian Goulosh tonight!).

We had a successful first day and I (like other evenings) went out with some of the local firms to discuss what "the real world" looked like for Scrum in their eyes (and of course eat some more great food (had rabbit lasagna).

Day 2 of the class went awesome and people asked engaging questions -- especially when I take some time to shut up and pull people from the audience to become a "panel" (and a different voice) to ask questions from other people in the workshop who are currently implementing Scrum. Good stuff. All was going well until my last exercise of the day when I discuss how to deal with "middle management" (Chickens).

Looks of stares and the cricket sounding ensued.

Huh? I thought. And asked, "Are you serious?" Maybe it was my translation of the concept, I thought? Damn... every other trap I set during the class (to help learn!) worked. What the heck?? Why?

I asked, "You know... the guys Dilbert makes fun of?"

Ruh-oh. Same thing. Some people laughed.

Er. Um.

This topic usually takes a good hour and I need to cut people OFF.

Wow.

I am learning something. Live and on the fly.

Just like what I have been teaching!

Their general response was, "Mike, we are outsourcing companies. We do work. Nobody wastes time at [insert management bla bla practices here]."

Wow.

Then when pressed about Dilbert, i asked if they read Dilbert and just said to themselves, "Those silly [nice word] Americans." The response was generally "Yes."

OK.

New tact. No wind (I think that is the term lol).

I asked if they wanted me to review the practices that THEIR clients (since remember, we have flipped the perspective here from the view of someone who is "taking" work currently) go through at some of the large clients I work with. And I told them if it did not add value, I would immediately stop it. One hour later, the module was complete and I hope we all learned some new things from different perspectives.

We finished off the day with each of them (congratulations!) becoming a Certified Scrum Master.

And we talked about the implications of what that actually could mean as the go back to their companies and start working with teams that may be implementing Scrum at their client sites (those who use off shoring).

This will be a topic of future discussion. I promise. I am learning a lot. And not from books, but by "being" here and talking to people face-to-face. Practicing what I talk about and teach.

We of course finished the day at a pub. More beer.

Then i left and had dinner with a host -- Chicken Kiev.

Had to do it. When in Rome and all that.....

But.

NO vodka. I learned my lesson in a past life about trying to do that. Experience helped me there lol.

I do want to also take the opportunity to thank a few people who made the trip there a lot easier for me -- including Alexey Krivitsky (organized the workshop for us), Tim Yevgrashyn (excellent host) and Marina (for managing the logistics of the apartment and transfers for me). Thank you tons. I look forward to coming back one day in the not too distant future.

I will leave the story of leaving the airport at Kyiv to another posting -- or a beer sometime if you want to buy (smile). It's a bit of a different process. And again, I learned more!

Wow. Fireworks are going off now. They must know I am here and are putting on a big party for me in my honor (I am totally KIDDING).

OK, I am going to go and try to call my family at home. Play some battleship online with my kid and see how life is going....

Gotta run....

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

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

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

... except of course I woke up at midnight east coast time, or 7AM local time here.

Not bitching or complaining... just putting things into perspective for my friends and readers who do not do a lot of traveling.

One quick word on my posting from yesterday's events.... it was no way intended to offend anyone.

I am completely thankful and humbled for the hospitality and professionalism all of the people that I have met with have shown me. I appreciate it and love this part of the world!

Also though, please remember that I write this blog entry in a way (or style) that suits me. I am writing it like I am trying to tell you a story person-to-person. Like sitting in a pub (smile).

THIS [blog] is not formal writing. I understand that. This blog is not set up for that purpose.... The purpose is for me to have a little fun (and poke some fun at myself).

Yes, I know I have readers of this blog from other countries (all around the world actually!).

Yes, I know my writing style sometimes is not easily translated and is sometimes loaded with Americanisms.

But I am trying to have fun with this, maybe put a smile on your face once in a while, and help people learn about Scrum the way I see it being implemented in the real world.

I am who I am. Love it or hate it. At least accept it please!

Enough said? Please I hope so!

So.

On to Kyiv Day #2.

This morning was MUCH colder than yesterday. And cloudy. I awoke early and read/responded to emails and then went for a walk (after locking my three doors behind me) without my camera; my accu-window forecast said it was going to rain. Unfortunately, I was correct.

I got wet.

O well.

I did not melt.

Here is another good lesson for people to remember when traveling to Kyiv.

"Yes, of course we have drivers licenses," stated a friend here when I asked him about it.

"Why?" He asked.

As he was asking the question horns were blowing and cars were going in the wrong direction on a one-way street.

Come to find out that the political people here (big black ford expeditions or mercedes 500/600 class or the really nice audis) all well, do not care about following the rules of the road.

Even better, it seems they set the example for the rest of the yahoos in their driving style. The cost of a ticket if they get stopped? Something like $2.00. Seriously. And if it goes to court, well, the court does not go after $2.00. Sounds like a business opportunity for someone in Kyiv if you guys are listening (laughing).

Why did I ask the question in the first place?

O yeah.

Because pedestrians do not have the right of way. I learned this an important way today.

I am not talking about the right of way in like in New York City (where people drive nuts).

But.

In New York City, the cars stay on the road and the people stay on the sidewalk. A nice symbiotic relationship exists and people do not kill each other.

People = Sidewalk.

Cars = Road.

Right?

Seems like someone has forgotten this here. But I guess for $2.00 you can pretend to drive like you are in the video game, "Grand Theft Auto."

What am i talking about?

They drive on the SIDEWALKS here. And park too. Actually, they will park anywhere. The last two facts did not surprise me or bug me too much (the cars were not MOVING at me)... the first one -- actually not knowing about it -- almost killed me. Well at least I would have been plowed down by some really nice black mercedes 600 series car :). And the guy driving it would have been fined two bucks. Nice.

So file that away for your next trip to Kyiv.

Back in the apartment in the morning after my walk, I did a bit more prep work for the CSM class -- the first one ever to be held in Kyiv (or the entire Ukraine!) and was getting ready to go meet a client to work with their team while I was in town.

I had just opened the door from the shower (in my pink apartment with my bear rug and slippers next to the door) and the front door (the one inside the one from the outside) started to open.

"AH" i said.

"AH" she said (except in Ukrainian). But it actually sounded like "AH" to me, no matter how you actually write it (smile).

Immediately thoughts (from yesterday) went through my head that, holy shit, I was in somebody else's apartment. I picked the wrong door or something.

And I was not fully clothed.

Eeek.

Turns out, through my thorough understanding of the Ukrainian language, that she was dropping off some things for the fridge, or "mini-bar." Cool, I thought, while getting dressed.

Now, my language skills in Ukrainian are non-existant. So I used pointing gestures and said english words really loud (darn... they did it to me yesterday lol) about the satellite TV not working? Much hilarity ensued while I tried to explain it was not working.

I guess I got the point across.

Let me say a sincere "Thank you" to the people who read the blog yesterday and got it fixed by the time I got back to the pink apartment tonight. It scared the crap out of me because some Ukrainian lady was blaring on the TV (but as I was walking in, I did not understand it was the TV and... well... you get it by now). Wahoo... the power of the internet. Thanks again guys. Now I can watch the propaganda machine from the USA (CNN and others) along with being able to see how the rest of the world sees Americans.

One word on that.

I am sorry to the rest of the world for thinking we are all like what you see on TV.

Amazing what happens when you meet face-to-face (hmmm... is there a Scrum lesson here or anywhere in the rest of this posting Mike?)....

Now for the Scrum part (finally!).

Today I met with an outsourcing company (not to be named) and spent the afternoon working with them on talking about Scrum basics and working though a lot of questions they had for me. In addition to that, we did some exercises on Product Backlog Estimation and Planning (using Mike Cohn's stuff for material).

It is extremely interesting to be working with teams that Americans (and other places) are outsourcing their work to.

Wow.

I think as I learn more about it over the next few weeks I will need to publish my thoughts publicly on this topic. Keep looking for it.

We wound up the day eating at a typical Ukrainian eating establishment. It was great food (and no, I could not convince myself that fried bull testicles would be a good idea to eat) -- so we shared some different types of meat and some excellent potato pancakes (of sorts) from Georgia (not the Georgia in the USA)! We had some exquisite cranberry juice and, fortunately for me (as I am teaching tomorrow) no beer was put into my system tonight.

As I sit and write this with a Ukrainian channel going in the background (hey, I hear it is a great way to learn it), I notice an, "as seen on TV" infomercial // commercial about a breast enhancer.

It's OK, this comment will be safe for work.

Wow. I thought, they MAKE those? Not only that, but, from the computerized pictures (no live hot Ukrainian models on this one) you can PROGRAM how um, enhanced, you want them! And guess where the switch (knob) is?

I am not joking.

Damn. It's time to call it a night and go to sleep.

Just remember if you are reading this in America tomorrow morning and drinking your cup of coffee from Starbucks at 8:30, the first day of the Certified Scrum Training class will be in full swing and getting ready to wind down for the day. If you are reading this entry during my CSM class and I have not asked you to close your laptop yet, please do so and participate fully for the remainder of the class (thank you!).

Have an awesome day and I hope you enjoyed reading this entry. And thanks again to all my local hosts who are extremely helpful, generous, and kind to me.

Gotta run....

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

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

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

I left Richmond at about 9:30 AM on Monday morning and arrived in Kyiv at about 10:00AM Tuesday morning (short layover in New York). Upon arrival, I pretty much breezed through immigrations and customs, not really able to read the cyrillic language anyway. One of the people from the local agile users group picked me up out front, and we went to their office to pick up keys to the apartment I am renting while I am here. I also stopped by one of the money exchange places and traded about $200.00 in US Dollars for about a 1000.00 in local monopoly money (sorry, it is called Hryvnias, pronounced with a "G"). Anyway, I am feeling rich with my new bills.

We went to the apartment and I huffed it up stairs (no elevator) in a building that well, has been around for a while. It is historic :).

After trying to get into the apartment, I found out the service that coordinated the apartment gave me the wrong apartment number. So, I met my neighbor.

Too bad it was not some hot Ukrainian woman in a towel, but at least it was an understanding big burly dude who just looked at me in amazement as I was trying to break into his apartment (he was in fact inside his own apartment and had a big bat with him). Oye. So he said (ok, yelled) something (intelligible to him, but ummm, somehow the f-bomb got dropped a few times I am pretty sure). The door slammed.

Hrumph. The piece of paper SAID 24. So I looked around and saw that there were three more apartments in this section. I moved to the one next door.

Still catching my breath from the haul up the stairs, I moved onto the apartment next door and tried one of the 25 keys on the holder. One worked. And, the bolted door lead to another door. So, finding yet another key, I opened the next door. At least there were only two doors (not like those Russian Dolls you can get that just keep getting smaller and smaller). And locked both behind me. Nice yellow slippers on the floor, but not mine. I hoped I had the right apartment.

The apartment is a beautiful pink. Lovely. Not really my choice of colors, but after meeting my neighbor and locking the doors behind me, I was happy to see I had a safe place to stay. "Shoot", I thought, "The keys worked." It has all the amenities of home, including satellite TV (which, I guess the bill was not paid because it just says something like "no service" (or wait... actually it says... o shoot... cannot type the words.... let's leave it at "no service." So I turned on the regular TV and listened to Ukrainian soap operas in the background. Looked around and saw that it had an empty fridge so it must be a rental (smile).

Time to leave for lunch already.... bags not even unpacked. Leaving my bags and sailing down the stairs, I looked back at the apartment and noticed a bright blue balcony over the entryway (this is a bit of foreshadowing!). Met my host downstairs.

Hope you are enjoying this, living vicariously through me -- and really -- the Scrum learning is coming too. I promise.

Kyiv is a great walking city I am learning. And the people are so friendly. Well, except if you are trying to break into their apartment.

I walked with my host to a metro station area for some local lunch (local, duh, I am here... but I told him we could skip McDonalds and TGIFridays!). We went to some local pub and I had coke and some chicken thing with a pickle. Yum. O... and the coke tastes like coke -- real sugar I think (not the crap we get in the US with corn syrup). It does make a difference. But heck, it was still a coke that made me smile (I have a million of those lines). Oh, and you want to say "Coke-a-Cola" not coke. I guess there could be mistakes by the looks I was getting from people around me when I placed the order.

After lunch, we hopped into a cab to be zoomed across the city to an old soviet building that was used (I think "was" and not "is" anymore) to design aircraft for the Soviet military. They looked strikingly like the airplanes I see in other places in the world. After handing over my passport and going through a strip search by a hot Ukrainian woman in a towel -- wait.... that did not happen.... I handed over my passport for examination to some lady that looked like she has been there since before the building was there and was allowed to pass through the turnstile into the lobby. There were two elevators. Here we go -- and it is like a pushbutton type I have never seen before.

I turned on my phone (forgot I had it!) and it looks like it had service from the nice phone company in Kyiv.

Now... before you think I am some untraveled ethnocentric Americano... please remember I have done a bit of traveling in my past. And more than my sister, who thinks "Epcot" at Disney in Orlando is all you need to do to see the world. I love traveling. And I love learning things like I am learning now. I do hope you are enjoying this entry heh....

It was a hot day yesterday. About 33-34 degrees (close too 100, eh?). The room where I would start my first talk in the Ukraine -- hosted by the awesome members of the local Agile Users Group -- had no air conditioner. This was not a problem until AFTER I was done with my roundtable discussion.

Anyway, about 50 people were in attendance and I started with my usual warnings about, "Tell me if I am talking too fast or if I say some stupid Americanism that needs translation." Then I jumped into my discussion.

Every time I lead this discussion, I get VERY nervous about audience participation. I should stop worrying.

I start this type of discussion on a white board drawing the skeleton of Scrum. I point out the steps, the artifacts, and the roles associated with Scrum. All of this is "by the book" kind of information. Then it gets interesting. When I first arrived, I asked people (on a scale from 1-5) about their experience with Scrum.... most in this audience were 1-2 with a few 5's. I, by the way, do not consider myself a 5 on that scale.

I then start a product backlog -- on the wall with a big piece of sticky white paper -- for audience members to let me know what they want to talk about. Mostly it is about, "Scrum in the Real World" (wow... the title of my presentation!).

I usually have about 90 minutes to pull this off.

90 minutes flies by.

Great questions were asked, and I was finished. I will address some of them in upcoming writings.

Coffee break (I had water).

Then the group had two more presentations. One was from a company looking at the local Ukrainian market who wants to setup shop there and told some war stories of how a project got completed by using Scrum. Or sort of. Stuff like "death march" was used in there, so it must have been some variance of Scrum. Yeah. Good stuff.

Now, remember... I said it was a little hot.

And, after being up all night (since Monday morning eastern time at 4:30 AM), I had to stand up else I would have passed out and that would have looked bad for me. Coffee would have been a good idea in retrospect.

Another break (no coffee this time) and we went on to listen to another speaker who had much to say about off shore agile. I learned a lot from their perspective and will be writing more about this in the near future. He was the only "non-Enlish" speaker who apologized for his English language skills (about a zillion times) and said his Russian was much better. I thought I'd be funny from the back and say, "Thank you, and remember your English is wayyyyy better than my Russian!"

Expecting crickets sounding in the background, at least the crowd laughed (probably being polite, but much appreciated).

We wound up the meeting at about 7:00 PM local time (it is +7 hours from ET).

I was ready to go to sleep.

But then my ears perked.

"Pub" and "Beer" passed though my Ukrainian babble-fish like finely-tuned ears. Could it be?

All 50 of us descended upon a local pub for furthering our discussions on all things Scrum. Or not.

OK, we did not talk about Scrum (too much). But drink we did. Or they did. I stopped at one beer. I am thinking more will come as my stay progresses.

My host then asked if I wanted to go to dinner and we went to a local place for some Borsch, Beer, and Beef. Nothing like the three B's for dinner :).

After some great conversation and excellent food, I flagged down a taxi (at least I though so, some mercedes stopped anyway) and my host negotiated my rate back to the apartment and gave the driver an address (at least I thought he did, he was speaking Ukrainian with his head popped in through the window of the car". I hopped in hoping it was not the last I saw of humanity. OK... not really.

But.

The "cab driver" spoke no english and had no idea where the heck he was going. After much "bla bla bla" from him and me thinking (very loudly and using the f-bomb in my mind) I cannot believe this, I got out a map and showed him where my apartment was.

Um.

It was useless to him because it was in English.

Ug.

What should have been a five minute cab ride wound up taking about 40 minutes through the back streets of Kyiv.

Nice tour. Fast and furious. Worse than when my father used to get lost and not admit it. OK... I do the same thing back home.

Remember earlier how I remembered looking back at the blue balcony? Well, after much of the cab driver "talking" to (ok, yelling at) me in Ukrainian and me just staring at him with a look of astonishment like, "does he think I am freaking deaf or TRYING to ignore him???" we whizzed by the blue balcony. "STOP" I yelled.

Looking around, well, um, nothing looked familiar except for the damn blue balcony.

So I paid the guy for my 5 minute taxi ride (the negotiated rate only!) and, tires spinning, I was left standing in a puff of white smoke (ahhh... the smell of spinning tires) in the beginnings of darkness on some street in Kiev surrounded by barking dogs.

Gulp.

Ug. The front door to the apartment complex was locked. And it had a numbered keypad (not electronic, push button -- like the elevator) on it.

Looking through the apartment information that was handed to me (it was in my pocket, phew), I found a three numbered code and... it did not work. Not really surprised. But hey.... maybe this was the wrong building I gulped.

I tried it again. And. It it did not work.

Remembering an episode of Scooby Doo (I watch the movies with my kids!), I looked harshly at the numbers on the keypad. Three were worn down. I kinda pushed all three at once and viola, whoosh, the door inched open.

No lights inside. And a haul up the stairs to the apartment. And outside of my block of apartments, there was yet another locked door. No lights either (not to self -- bring my little flashlight when I leave).

One more guess (OK, 20) from my block of keys let me in (and I locked it behind me) and then two more doors in, and ahhhh.... home in my pink apartment I was.

And then I found a cable modem on the floor. Right next to a bear rug. Seriously. I think it is dead but it is staring at me right now. At least he is quiet.

And... well.... as you can see... I got it working.

I bought some Skype money and called the cell to let my wife know I arrived and things were well. Nothing much had happened with me today (smile).

And then went to sleep.

Got up Wednesday morning about 7:00 local time and wrote this entry after reading some email.

At this point I will head out and walk around until about 1:00 -- where I will be picked up for my next adventure -- some consulting at a local company implementing scrum here.

More later. I hope :).

Still looking around wondering if I am in someone else's apartment. O well.... for now I am OK.

Gotta run....

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

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

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

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

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

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

Two words you should become familiar with:

Planning Poker.

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

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

Now.

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

Why?

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

Back?

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

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

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

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

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

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

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

Read them. More. Really. I can wait.

Now....

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

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

Really.

Next.

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

Next.

Finish it in one sitting. Trust me.

Next.

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

Next.

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

Next.

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

Guess what.

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

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

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

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

Most likely.

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

Is it easy to do?

Who said it should be easy?

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

Move on.

And develop working software.

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

Gotta run....

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

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

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

OK.

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

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

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

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

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

Is it totally Scrum?

Nope.

Can I still talk about it?

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

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

Start your Product Backlog.

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

Remember.

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

Anyone.

Now. Also remember....

There is one Product Owner.

Only one.

Really.

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

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

Reality sucks some times, eh?

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

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

You can assign story points and hours.

You can track your progress via a burn down chart.

You can then have your Sprint Review.

And a Retrospective.

It can be fun.

And.... stuff actually can get done.

Like at work when Scrum is working "right".

So.

This is great. Right?

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

But.

Think about the world outside of IT.

Your business.

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

What can you start doing differently using Scrum today?

Heh.

Gotta run....

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

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

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

I have a fun time working with clients around the world.

Really. Please remember this as you read this entry!

With some clients and projects, I get called in a little after Scrum has been adopted. Sometimes the team has gone through one or two iterations and Scrum does not seem to be working.

Or so it seems. To the Chickens. And the team usually is getting frustrated at all the change surrounding them.

Here is one of the symptoms to the problem.

In heavy waterfall environments (corporate cultures), a lot of the time people are still working in silo styles (mini-waterfalls) and then some have tried to form multiple Scrum teams when one does not even work to its potential.

The reasoning behind the formation of multiple Scrum Teams is because some work "requires specialists" that only a few people -- or just one person -- on the team can fill. And they are perceived as slowing things down (or opposite -- this Scrum stuff getting in the way of moving forward).

Teams -- or should I say management -- looks to the type of people who do this as "heroes" that can always pull a project out of trouble.

OK... I may piss some people off here; however, a lot of the "heroes" I have met (and tried to work with) are not worth what you are paying them. They may be hiding behind a process or claim to be the only person who knows a critical piece of code. Ug. Usually that code is crap. But I digress... sorry.

People implementing Scrum this way do not get it.

In these situations, sometimes the teams start competing with each other and the blame games start. Competition for resources starts to occur. All of the sudden, Scrum starts looking like the old waterfall environment of
the past.

All within only a few iterations gone bad.

How can you avoid this?

Look around and see what is happening with your team.

Is there a "hero" on your team?

Are you that person (smile)?

Are you doing the "basics" of Scrum?

Really?

Make sure.

And.

Get it right with ONE team before breaking out to new teams.

If the Chickens want to interfere... tell them to back off.

Or have your ScrumMaster do that.

That is one of the roles that the ScrumMaster must play.... helping to shield the team.

Gotta run...

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

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

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

Scrum and communication techniques. Brings me back to the days when my neighbor Ed and I used to string two tin cans together with a piece of tightly strung string (over a house between us!) in order for us to "talk" together at night. Eventually we upgraded to some crappy handheld radios for transmissions (which we assembled from parts from Radio Shack) and got in "trouble" at night for staying up late using our toys.

Today my friend Ed and I still talk to each other; albeit most of the time via email and occasionally over the phone. We rarely see each other face-to-face, as our lives have diverged into different areas of specialties and different areas of the world. I think the cool thing though is that if either of us called upon one or the other for help, we would "be there" for each other in an instant.

So what does this trip down memory lane actually bring to this blog entry?

Think about some of the most highly effective teams you have worked with.

Now think about the world today. I bet there are some still very high effective teams working together today (using Scrum of course!).

And to me this is great to see.

Here is where I see a failing -- or a significant challenge today. In addition to me seeing it and living it on almost a daily basis, I realize it is being written about ad-nauseam in some forums and other areas of the net (including books I am sure!).

The topic is collocation -- or the lack thereof -- of teams today.

It is a fact that many many many Scrum teams are struggling with this topic today. And, while I hope people are coming up with creative answers, I'd like to make some recommendations that I have seen work -- in the real world -- today. Along with some miserable failures.

This may seem obvious, but I always always always always recommend any Scrum team collocate together during a Sprint.

This cannot always happen.

However.... strive for the ideal.

Really.

If this truly cannot happen, strive to make the part of the team which is not collocated with the main team feel a very close connection as to what is happening with the entire team today.

Huh?

Think about it. Yes, even people in large enterprises with "risk officers" who may shred my advice.

Open a communication line between the two rooms. Have more than two rooms? The same advice applies.

Realy.

It is that damn simple.

It may not be cheap, but it is simple.

Male it as simple and effective as possible.

This does not mean throwing a 56K ISDN line into a PolyComm Speaker Phone over to India to talk. Um. This is almost as bad as the string between the two tin cans. Don't believe me? Try it. And come up with a better solution.

Team.

Do this.

And do not accept mediocrity.

Sure, the bean counters and other Chickens may say that getting the entire team together for even a Sprint Review, Retrospective, and Planning session may be too costly.

Hmmmm.

Look at what the team is burning each Sprint.

What percentage of the team burn will REALLY increase if you got people together once a Sprint.

And... on the flip side.... what would the team GAIN in productivity (as measured by the velocity) for the overall project?

Gotta run...

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

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

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


Today I am writing about something I consider a real problem within our industry today. I will keep this entry specifically to Scrum; however, please note this can apply to any of the agile techniques out there today (for example, XP, TDD, Agile Modeling, Crystal, DSDM, and others).

As regular readers of this blog can hopefully tell by now, I am not a religious zealot about Scrum and do not subscribe to the thought of a Scrum Police Force. I regularly push the edge on some topics (I am finding this gets your attention!) but do not think Scrum is a Silver Bullet nor should it be applied to every Software Development Project on the Planet.

Really.

However.

And I think you know this was coming (smile).

If you are going to use Scrum as one of the many available Agile Software Development frameworks on your project, please please please please please please please understand what you are getting yourself into.

When I teach Scrum (as a Certified Scrum Trainer), I teach things “by the book” and then talk about the differences I see sometimes in reality (you know, the real world you and I both live and work in!). At conferences around the world, I receive great feedback from a session I present named, “Scrum in the Real World.”

I know what “the book” says and what Scrum talks about as “best practices.”

So…. Why should I care (you may be asking yourself)?

The idea of, “Death by a thousand copies” is not something new to Scrum. It was taught to me by a gentleman named Michael Spayd (a great Organizational Change person!) and I do not know its true origin(s).

What does this mean?

Let’s say you are on a team which uses Scrum today. It really works for you and your current team. The team is so successful that the project is finally shut down (you have delivered enough value to the business -- congratulations!).

You move to a brand new team.

Starting from scratch. Some people on the new team have been watching your “old team” and may be resentful at its progress. Now… someone is telling them, “You should use this Scrum thing because it worked so great for such-and-such a project.” You are excited coming off a great team that was high performing.

You are the only person with any experience using Scrum on the new team. And, you are telling everyone on the team how great it is and how, “On the old team, we did it this way….”

“This way.”

Hmmm… maybe the old “this way” included the team skipping doing a Burn Down Chart to track velocity. Maybe your stand-ups used to take 30-45 minutes.

And… you “push” these “old” ideas of Scrum onto the new team.

But wait. The “new team” has just finished getting some initial training on Scrum and wow… they say… we really do need a Burn Down Chart and the meetings should really take 15 minutes.

You entice them to do things the “old way” you did things (no matter what the reason) with your old team. You reason, “It worked for us, it can work for them.”

Zoom ahead three projects if you will for a moment.

People from the current “new” team have seeded about nine other teams at this point. Scrum training is a thing of the past since your organization now “knows what it is doing” and has this Scrum thing down pat.

Things start going wrong.

Way wrong.

People start looking at Scrum and calling it useless.

You are no longer delivering working software at the end of each iteration. Your iterations are now eight to ten weeks long. Retrospectives? What are they? The stand-ups have devolved into three meetings per day to get “input” from senior management on your team. Managers are parachuting in on a daily basis with “solutions” for the team. They start throwing bodies at the project, because, don’t you know, adding people and resources to a late project helps.

Not.

Stop.

Look around.

Is this happening today?

So what does this have to do with, “Death by a thousand copies?”

Hmmm.

I get called in (pretty regularly these days, yikes) by managers and teams who may have been using Scrum in their organization for a while.

I start asking the basics about Scrum.

“Sure Mike, of course we are using Scrum here. We are the experts on it,” they say to me.

So.

I look around.

Whatever framework they are using today -- as a result of people cutting corners and skipping basic principles and practices of Scrum -- looks nothing like Scrum anymore.

But.

People are running around saying, “Scrum is killing our organization.”

Are you in this situation today?

Are you headed that way?

Gotta run...

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

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