Implementing Scrum

Request for Feedback. Please.

mvizdos@gmail.com — 2007-08-09T16:55:13-04:00

Request for Feedback. Please.

I have been receiving a lot of requests from people asking if they can print tee-shirts or mugs (or whatever) for use either internally at their company or for sale. At this time, it is strictly prohibited to use the cartoons or characters for anything that is of commercial interest (read: makes you money off our brand!).

We have a LOT of comic strips (I think we are are approaching 50!) and of course our characters. At this point, all the artwork on the site is "optimized" for the web viewing (meaning if you try to print them they are not "book" quality). This will take time to do.

So.

Instead of me rushing to convert all the artwork and creating a lot of products and an online store (bla bla bla)... I figured I'd ask YOU and see if there is any interest in merchandise for you and your teams. Am thinking T-Shirts, Mugs, and whatever cool stuff you can think of doing.

That's where YOU come in.

Please let me know if there is any interest in merchandise from the site.

It is not a commitment to order, but rather actually me talking to my customers before trying to deliver something. Wow. How Agile :).

If you can, please take a few moments and send me your thoughts.

I'd really appreciate the feedback!

And also don't forget to tell your teams and friends about the site (thank you).

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!


Originally Published:
August 9, 2007

[Update] Making Babies. Fast.

mvizdos@gmail.com — 2007-08-08T15:36:43-04:00

[Update] Making Babies. Fast.

His September column "Agile on a Fixed Budget" is now posted here.

------

From Scott Ambler:

The article was originally motivated by the "How do I do Agile on a fixed price/estimate project" questions that I invariably get when working with clients or internal development teams. So I decided to take it one step further and address the question "How do I do Agile when one or more of the cost, schedule, or scope is fixed up front?"

The column first summarizes strategies for what you would do when each of these factors is allowed to vary so that you understand what trade-offs you're making.

Then it describes what I consider to be your best approach remaining to you for each combination of constraining the three factors.

The main point of the article is that although it isn't ideal to have one or more of these factors constrained, you can still take an Agile approach even when such constraints exist.

------

Hope it is helpful for you!

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!


Originally Published:
August 8, 2007

Scrum = Scrum.

mvizdos@gmail.com — 2007-08-06T15:40:40-04:00

Scrum = Scrum.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
August 6, 2007

[ANN] Two NEW Translations Available!

mvizdos@gmail.com — 2007-08-01T13:55:30-04:00

The two new translations include Hebrew and Spanish; they can be viewed here.

The English version of the blog entry can be found here.

The others (in alphabetical order) include:

Dutch
English
French
German
Italian
Polish
Portuguese (Brazil)
Russian.

Thanks to all who have contributed the translations.

Interested in helping me translate the cartoons in other languages? Please contact me!

Feedback. Is Anyone Listening?

mvizdos@gmail.com — 2007-07-30T15:49:11-04:00

Feedback. Is Anyone Listening?


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

Breathe
Stay calm and listen
Ask for clarity
Don’t interrupt, but if you aren’t getting what you need (data) then ask for it
Use what you can
Remember it’s information not praise or blame
Know when enough is enough
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!


Originally Published:
July 30, 2007

ScrumMaster = Snake Oil Salesman?

mvizdos@gmail.com — 2007-07-23T15:34:38-04:00

ScrumMaster = Snake Oil Salesman?


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
July 23, 2007

The "Evil" Doctor and Captain.

mvizdos@gmail.com — 2007-07-17T14:17:39-04:00

The "Evil" Doctor and Captain.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
July 16, 2007

Don't Force It.

mvizdos@gmail.com — 2007-07-09T14:29:12-04:00

Don't Force It.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
July 9, 2007

[ANN] Plagerism or Flattery? [repost]

mvizdos@gmail.com — 2007-07-06T11:47:43-04:00

[ANN] Plagerism or Flattery?

mvizdos@gmail.com — 2007-07-05T08:37:21-04:00

You have LESS oxygen at high altitudes.

mvizdos@gmail.com — 2007-07-02T16:54:52-04:00

You have LESS oxygen at high altitudes.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
July 2, 2007

ScrumMaster Begins. And thinks about BatMan.

mvizdos@gmail.com — 2007-06-25T00:01:42+02:00

ScrumMaster Begins. And thinks about BatMan.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
June 25, 2007

Kyiv - Day 3 and 4 - First Kyiv CSM Workshop "Done"!

mvizdos@gmail.com — 2007-06-23T20:58:57+02:00

Kyiv - Day 3 and 4 - First Kyiv CSM Workshop "Done"!


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
June 23, 2007

Kyiv - Day 2

mvizdos@gmail.com — 2007-06-21T00:14:05+03:00

Kyiv - Day Two.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
June 21, 2007

Kyiv - Day 1

mvizdos@gmail.com — 2007-06-20T09:36:13+03:00

Kyiv - Day One.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
June 20, 2007

Ya Got to Know When to Fold 'Em.

mvizdos@gmail.com — 2007-06-11T21:25:16-04:00

Ya Got to Know When to Fold 'Em.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
June 11, 2007

Who's your Product Owner?

mvizdos@gmail.com — 2007-06-04T16:08:30-04:00

Who's your Product Owner?


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
June 4, 2007

[ANN] Update on the ImplementingScrum.com Forum

mvizdos@gmail.com — 2007-05-30T23:29:40-04:00

Hi all,

Wow. I see a lot of new -- and returning -- readers have been checking out the site at www.implementingscrum.com.

I'd like to say a sincere "thank you" to each of you who both read the site and pass it on to your friends and colleagues.

One of the areas of the site that has been growing (slowly) is the Forum area. As a test, I wanted to let that part of the site grow organically without any input from me. I have found that is a bad decision on my part, and I apologize for that. In the future, I will be reviewing any postings as they are ummmm... posted (smile) and will offer my input.

As a member of the community, if you have something to say... PLEASE feel free to add to the discussions. I have found that these forums work best when the entire community participates!

If you are interested, please check out www.implementingscrum.com/forum

Have a great day and thanks again!

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!

Race to the Finish Line.

mvizdos@gmail.com — 2007-05-29T12:40:30-04:00

Race to the Finish Line.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
May 28, 2007

[ANN] Kiev and Budapest

mvizdos@gmail.com — 2007-05-23T14:37:02-04:00

Scrum = Communication.

mvizdos@gmail.com — 2007-05-22T22:47:51-04:00

Scrum = Communication.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
May 21, 2007

RIP Scrum.

mvizdos@gmail.com — 2007-05-14T21:46:35-04:00

RIP Scrum.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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!


Originally Published:
May 14, 2007

What's for Dinner?

mvizdos@gmail.com — 2007-05-07T20:30:56-04:00

What's for Dinner?


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

This week I am flying solo -- without Tony (the artist for www.implementingscrum.com). While this was a planned event, it actually started stressing me out a bit to know that I am on my own this week. So, instead of me drawing stick figures, I asked my son (he just turned seven years old) Dominic to work on the comic strip for me. He did a great job and I thank him for it! As a heads up... The first panel has kyrptonite and the last frame is the pig and chicken fighting (my fault that the scan looks a bit on the lighter side!).

And, it stresses the importance of an agile practice (not talked about directly in Scrum) called "pairing."

This blog entry could take a dozen different tangents on this topic; however, I promise to try to stay on point about what I am trying to get across. Yes, O people who know Scrum... Scrum does not talk about "engineering practices" (this is by design).

So why am I even breaking out of the "World of Scrum" to talk about pairing? Because, my friend, Scrum must play in a big bad world of Software Development and well, people need to realize this.

So... what is pairing and why is it important?

I am going to tell you my definition from experience.

My idea of pairing is NOT having two people sit together for 8 (or more) hours a day at a computer banging away at code code code and not focusing on anything else. Nor does my definition of this include sitting by the computer together (as a pair... getting this??) for 3 hours a day joking around, surfing the Net, or playing online games. As cool as that may be to get paid for (and yes, some gamers who use Scrum in their development shop may have this opportunity and not even realize it!), neither of these two things describe pairing for me.

Here is an example we can use that is "outside" the Software Development world.

This site is developed using Scrum as a framework.

Do we do it perfectly? Nope.

Do we continue to strive to improve? Sure.

Now... please stick with me through this. There is a point. I promise.

Right now, remember... the site is developed and maintained by only two people (Myself and Tony). And, this is the process we go through to get you the comic strip and blog on a weekly basis:

Usually by Thursday evening, I get a rough idea about what I want to write about the following week (to be published on Monday evenings). I email the idea over to Tony. On Friday, Tony and I answer any clarifying questions about what we will try to get across... and by Saturday mornings Tony has a rough idea of the text and format of the panels in the comic to me. That's usually the last we talk about anything until Monday afternoon when -- pop -- in comes the latest comic strip for the weekly blog. I'll go back to my original outline for the idea (that I emailed him the previous week) and then -- after the kids go to bed on Monday nights -- I refine (as much as possible) the bog entry for the week.

Publish. Rinse. And Repeat.

I usually am totally shocked at the results. In a good way. And, most of the times, the comic strips that go along with this bog entry write-up take things to an extreme (with a lot of references to pop-culture and humor in ways I could never think about).

Over the time of working on this site together, Tony and I have come to a balance and understanding that he provides the [awesome] comics and I will provide the text and writings behind them.

This is an example of pairing.

Is it the classic example? Nope.

Does it cost me more than doing it alone? No.

Is the product better?

Does it work? You tell me (please!!!!).

Another interested fact on the idea of pairing.

Most people think you need to collocate in the same room and computer in order to do this. I will let you in on another secret, and think about this for teams that are not collocated today -- Tony and I live in different states (not of confusion, but locations) and we have yet to meet face-to-face. If I passed him on the street, I would not even be able to say "hi" to him.

We will meet someday, I am sure. However, as with many Software Development projects these days, Scrum teams are using offshore resources on a more regular basis (I will not go into this topic on this entry, really!). The point here is that, in reality, we are all going to have to work with people we may never meet face-to-face. And it somehow needs to work.

Does this increase the chances of failure?

Absolutely.

Another factoid.... I had the idea for this site in early 2006. It took me almost eight months of speaking to my personal network of contacts -- and then to networks of people and their networks -- to "find" what both an artist and I considered a good fit.

Could I have launched the site earlier than September 11, 2006?

Sure.

Would it have had the same tone and impact it is having today?

No.

However, once we figured out that we could get started... we did.

And, weekly -- come hell or high water -- we deliver on a consistent basis. Sometimes the results vary widely.

As for Software Development projects using Scrum, realize that you are dealing with people -- human beings (not Resources!) and you cannot do everything by yourself. And, with all the constraints that are out there for not getting things done or delivered.... remember that Scrum talks about the "Art of the Possible" and try to keep that in mind as you get mired down in your day-to-day work.

I hope the current blog entry was helpful to you. Share it with others, as I see happening quite a bit now (and thank you for that!). And hopefully you enjoyed this week's guest artist!

Gotta run...

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

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


Originally Published:
May 7, 2007

This Scrum Team Costs WHAT?

mvizdos@gmail.com — 2007-04-30T17:10:33-04:00

This Scrum Team Costs WHAT?


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

A few weeks ago I presented a CSM Workshop with Mark Pushinsky (another great Certified Scrum Trainer!). One of the things we continually get asked about during the two-day session is regarding budgeting. We will be adding a module on this in the future; however, after talking about it quite a bit, it comes down to trying to keep things extremely simple.

And, it works.

So, here is a quick lesson on budgeting on a Scrum Project.

And no, you do not need any super computers or fancy software models.

Got an abacus?

Good enough!

Remember if you will the idea of the iron triangle. If you are not familiar with this concept, please visit the link and come back. I will wait for you!

Welcome back (smile).

In Scrum, your timeline is fixed (either called a Sprint or Iteration). For the purposes of this example let's state the Sprint length is the classic 4 weeks.

In Scrum, you have pretty fixed resources (some people call them people, and not resources [I agree!]). For the purposes of this example let's say you have 10 people on the team. And, again, for the sake of easier math (on me right now!), let's say the bill rate is 100.00 per hour per team member.

So here comes the budgeting!

Take your team members ($1,000.00 per hour (wow!)) and multiply it by 8 hours ($8,000.00 per day ) * 20 billable days = $160,000.00 per Sprint.

If your project involves a lot of infrastructure or software licenses or bla bla bla... count that in now.

However.... there... you have the burn rate for the team. About forty grand a week.

And. This is pretty accurate.

Within 3-5% on a personal basis. At the END of real projects.

Keep it that simple.

Really.

And then.

DO NOT fall for the trap of starting to associate the burn rate with story points.

"Why not Mike," you may be asking yourself?

Well... think about the classic "result" that managers (Chickens) try to associate in their minds....

"Let's see. Doing the math, we can get 3.47 points per person per Sprint. Let's ADD people to get that number up to 4 points per Sprint and I will look like the hero!"

Warning lights and loud sounds should go off in your head if you start hearing this silly reasoning.

Why?

Because, as we ALL know (Pigs)....

Adding people to projects (especially ones that are "in trouble" never helps -- especially in the short term. In fact, this is usually a major drain on the current team and the velocity starts trending downward.

Yikes.

Unfortunately, I have seen this false reasoning applied time and time again. Even after coaching managers (Chickens) who really do know better.

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!


Originally Published:
April 30, 2007

The Cast of ImplementingScrum. Infamous Yet?

mvizdos@gmail.com — 2007-04-23T16:45:41-04:00

The Cast of ImplementingScrum. Infamous Yet?


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

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

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

Otherwise, please enjoy and drive responsibly....

Scrum Master

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

Chicken

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

Pig

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

Product Owner

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

Ken

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

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!


Originally Published:
April 23, 2007

Drink. Out of a Fire Hose.

mvizdos@gmail.com — 2007-04-16T20:17:32-04:00

Drink. Out of a Fire Hose.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

In the past, I have written about the Product Owner and the role that person needs to play. And, I have been on record for saying this is one of the toughest roles for anyone to play on a Scrum Team.

Today, I discuss ways in which the Product Owner interacts outside the team -- with what I call, "The Noise."

First, please remember that each Scrum Team should have ONE Product Owner.

ONE.

Not two.

Not three.

Not a committee.

ONE.

Comprende?

This is a super important concept to understand and make sure you are actually following on your Scrum Team. It is a major point of failure when implementing Scrum if your team is being run by a committee of Product Owners. If you are in this situation, I think you know this in your heart; and, you probably feel the pain on a daily basis.

For the reminder of this discussion, lets assume that you have one Product Owner.

Ahhh. Nice (smile).

This Product Owner is actively involved on a daily basis with the team. In fact, as a team member, you feel like the Product Owner IS a part of team. This person attends the daily stand-up meetings, is actively involved in your Scrum Team Room (collocated of course), and has the answers and is empowered by his or her peers and bosses to make the call on direction. If there are any questions, this person knows how to navigate "the system" outside of the room, and is able to get the Scrum Team a definitive "yes" or "no" (or answer) in a timely fashion.

Sounds easy, right?

Here is what could be happening outside the room. And this is where the Product Owner really needs to shine for the team.

On the "outside" world (away from your Scrum Team), the Product Owner is actively defending people from coming into your Scrum Team Room and asking for new things to be added. You know... those pesky Vice Presidents who have "friends" on the team that can do "favors" for them. An effective Product Owner -- in conjunction with the Scrum Master -- works to ensure this actually stops happening.

This is part of shielding the team from "The Noise" on the outside world.

In addition to being a shield for that, the Product Owner has the distinct opportunity to help all the outside stakeholders shape and form the Product Backlog (remember... there is a difference between a Product Backlog and Sprint Backlog ). At the end of every day (or minute, depending on how your organization looks and reacts), ultimately it is the Product Owner who is the single wringable neck (a term, by the way, which I hate to see used gulp). This person has the responsibility of making sure the priorities are negotiated and are correctly identifying the highest risks to the organization today.

This can be tough.

The Product Owner must negotiate with his or her peers and up the chain of command in an organization (even if it is an organization where there is only one more person with an opinion above the Product Owner).

And remember, like you (o Scrum Team Member), this person cannot just make stuff up in a vacuum. If that happens, I can pretty much guarantee career suicide for that person. I have, unfortunately, seen that happen.

So.

If you are on a Scrum Team today and things look rosy and things are going smooth, be thankful.

If your Product Owner makes it look easy to the team, you are lucky.

Hmmm...

If you are not in the happy happy situation as described above, maybe it is time to chat with your Scrum Master, Product Owner, and Team (maybe a Retrospective Topic???) about what can be done. Call in someone from the outside if needed (shameless plug for me if you take it that way!).

If you are in the happy happy situation as described above, then give your Product Owner a hug (or at least a sincere "Thank You" if it is inappropriate) right this moment. Allow that person to continue shielding you from "The Noise."

And, continue making your team even higher performing than it started today.

Good luck!

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!


Originally Published:
April 16, 2007

[Podcast] Welcome to Oz.

mvizdos@gmail.com — 2007-04-11T21:47:59-04:00

This is The Podcast -- the first one on www.implementingscrum.com -- based on the blog entry and comic from this past Monday.

Welcome to Oz.

mvizdos@gmail.com — 2007-04-09T20:48:43-04:00

Welcome to Oz.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

Welcome back to another week at www.implementingscrum.com. The blog entry this week has been brewing for a while, and I'd like to thank John S [you know who you are] for the idea of linking this topic to Oz.

The topic of the week is Compliance.

And no, I am not going to tell Scrum Teams to "just ignore it, and it will go away."

But I am going to challenge the system. At least a little bit (smile).

Before delving into this further.

Think about the importance of customers.

Really think about this.

Not "IT" versus "Business" or whatever you call it internally... but REAL customers who PAY your company REAL money.

In the beginning, as either an entrepreneur, recent university graduate, or single person.... you were accountable to basically you. And oh, the IRS (or whoever collects taxes). And maybe a puppy. When you delivered services you were paid.

Then...

You started growing. Your company added people. You were responsible for payroll -- making sure your employees received a regular paycheck; and it had to clear. Or you got married (or had a civil union if it is legal where you live). Your puppy starting growing up.

Then, one day, you decided to take the company public. Or have kids. Your puppy turned into an adult dog.

All of the sudden, you look for your customer -- remember, the people that actually PAY you for services rendered -- and see that now you have a lot of oversight.

From "stake holders." Be it the IRS, your board of directors, your shareholders, your clients, you internal teams, bla bla bla.

Where the hell did your customers go in all of this. Remember.... little Joe (or Jane) customer who actually pays the bills for all this new overhead? Hmmm... people lost sight.

Empires started to grow.

People -- not resources (smile John) -- that are paid (ultimately by a customer who uses your services and could give a rats ass about what happens behind the scenes) start building empires. And this is not just with public companies (sad, but true, and I have been there).

One of the many empires that emerge is something called "Compliance."

There job is to create and publish policies, procedures, standards, guidelines.... bla bla bla. Your customers (who pay you) do not care.

Ah.

But another empire -- the auditors -- who compliance can then "blame" start making sure you are following ALL of the darn things that they (compliance) created.

This, my dear reader, is the agile police.

And, breath here....

It is a cost of doing business.

That being said, remember that you can be 100% compliant. And have no customers. Then what?

But... until that message gets across within your organization, here are a few tips:

1) Become compliant.

2) Stay compliant.

3) Work with compliance.

4) THEN... start questioning compliance.

I know. I know.

Compliance is important.

Very important.

Is it worth going out of business to be "compliant"?

I will leave you with this.

For now.

Gotta run...

Oh.... want to hear the Podcast of this entry? Click The Podcast.

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!


Originally Published:
April 9, 2007

[ANN / Question] For Regular Visitors...

mvizdos@gmail.com — 2007-04-07T13:55:45-04:00

Hi all,

As we move into April (wow, the year is flying by), I'd like to ask for your feedback on the site/blog and find out -- from you -- what I can do to make it a better experience going forward.

Some specific questions I am wondering about include:

- Is anyone interested in posting some advertising on the site? If you know of anyone who is (or if you are in the position to do this), please contact me we can work something out together I am sure. One of the reasons I am asking is because it looks like I will need to get a dedicated server (and increased bandwidth) for the site in the near future, and asking the community for ideas to fund this was my first thought. We are getting a ton of traffic and it is almost doubling on a monthly basis (thank you!). The site is currently hosted on a shared server and I am blowing over the current allotment of bandwidth already.

- One of the areas I have not touched yet is with podcasting. I know this is a hot topic and wanted to know if anyone would *really* be interested in either hearing a weekly broadcast about the comic/blog and/or if anyone out there would be interested in doing a "seven minute conversation about Scrum" (OK... crappy title and we can work on it); this would basically be me interviewing people in the trenches on a weekly basis to find out what problems, issues, or impediments they are having while implementing Scrum. I know that people reading (and maybe listening) can learn a lot about this from others, and I am more than willing to start this if you are interested. We can keep it as confidential as you'd like!

- Translations. As you may have noticed, the comic strips are starting to get translated into local languages. If you are interested in assisting with this, please let me know and I will work with you to make this happen. The only compensation is "credit" to your name but it is always fun seeing them in lights (isn't it?).

- Ideas for cartoons. Always welcome. And again, I will credit you however you'd like. Love to hear about real-life things that happen other than on teams that I work with!

OK.

That's all for now.

I do appreciate your continued support both reading and helping me spread the word about this blog to people around the world. It is truly awesome to see it makes a positive impact (most of the time). It's been a fun six month start so far, and hang on for more fun as we continue the journey together. Stick with me!

Thank you,

- mike

Work Naked.

mvizdos@gmail.com — 2007-04-02T16:13:09-04:00

Work Naked.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

Welcome back to another week at www.implementingscrum.com. We introduced a translation page early last week and the response has been great to date! So far we have seven translated versions of "The Chicken and Pig" with lots more in the pipeline.... and remember, it is not limited to just the first comic or blog entry -- if you have an interest, please feel free to help us add to the site!

I want to thank Tami Clark (on an agile team at salesforce.com) for pushing me to get the comic out this week. It has been on my mind for a while, and well, here we go!

The topic for this week is regarding dysfunctional scrum (or stand-up) meetings.

Here is the way they "should" work:

The team stands up and faces one another. Sometimes this is a circle, sometimes it is a square. It does not matter... people should stand up.

Chickens cannot talk during this fifteen minute meeting. Yes. This should not last more than fifteen minutes.

Each person on the Scrum Team takes their turn answering the three questions, which can include:

1) What have I completed since the last meeting?
2) What will I complete before the next meeting?
3) What is in my way (impediments)?

Yes, the nuances of how the questions are asked can be a little different, but sticking to answering the three questions is key. The Scrum Police will not come after you if you do not ask the questions specifically as they have been listed above (for example, "completed" can be replaced with "done" or whatever).

The key thing that this daily meeting is set up to do is so that each team member can communicate with the rest of the team on what they are doing and what they need help with.

Here is where I have seen these meetings go bad....

- The meeting lasts for an hour. And nobody seems to care.
- People talk about things that are not related to the three questions.
- Team members try to solve problems.
- Chickens speak.
- People sit.
- Cell phones on. Laptops open. People "checked out."
- People show up late, or do not even bother to show up.
- Status reporting to the Scrum Master.

I will address each of these topics in a little more detail.

Is it an exhaustive list?

No.

Is it in any specific order?

No.

However, if you see some of these topics popping up when you are working day-to-day, maybe it's time to figure out -- as a team -- what can be done to fix things.

- The meeting lasts for an hour. And nobody seems to care.

Apathy sucks. If your team is having diareah of the mouth and the stand-up is lasting more than fifteen minutes, the Scrum Master needs to keep the team focused on answering the three questions.

And move on.

- People talk about things that are not related to the three questions.

This topic feeds into the problem of the daily meeting going more than fifteen minutes. Yes, it is great that you are spending time outside the room on other things (even "life"); however, the purpose of this meeting is to answer the three questions and get coordinated.

You will have time during the remainder of the day (hey... you are collocated... correct?) to talk about that other stuff.

- Team members try to solve problems.

Ug. This is something I see from both new and experienced teams. If there is a problem (and, there usually are) that the team needs to solve, put it up on a board or list someplace visible in the team room and make sure people work on it and solve it during the workday.

- Chickens speak.

Enough said? If Chickens want to speak, they can speak AFTER the daily meeting.

- People sit.

Stand up. OK, unless you physically cannot do that.

It will help keep the meetings short.

And, it helps team members avoid the next topic....

- Cell phones on. Laptops open. People "checked out."

Oye. Ug. Ouch. Scrum Master -- help the team come up with norms that help the teams get over this. It is a good topic for a retrospective (to be written about soon, I promise!).

- People show up late, or do not even bother to show up.

OK. Scrum "says" people should pay a penalty if they are a member of the team and they do not show up for a daily meeting. There are a ton of excuses, and people can get creative (like for instance... I have an "emergency" (wink) is used as a "valid" excuse to miss them).

Missing a daily meeting has an impact on the team.

Your team.

One that you are a part of!

Some of the penalities I have seen over the years include paying a dollar (or a LOT more), eating a pickle (one of those big disgusting ones out of a large jar -- at 9:00 in the morning blech), wearing a hat, receiving a Scrum Witch, or... or.... or....

Penalties can get creative (as I have learned).

But.

Show up. Avoid the silly penalties and excuses and be there for your team.

- Status reporting to the Scrum Master

This is a classic pattern I see for teams converting from old waterfall approaches (with a command and control Project Manager) to agile approaches of doing work.

There is no role of "Project Manager" in Scrum.

For a reason.

The Scrum Master is not a Project Manager in the classical sense.

So Scrum Team members... PLEASE do not give daily status reports to the Scrum Master.

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!


Originally Published:
April 2, 2007

Four more translations available!

mvizdos@gmail.com — 2007-04-01T11:05:39-04:00

Wow!

The cartoon of "The Classic Story of the Pig and Chicken" is now translated into Italian, Polish, Portuguese (Brazil), and Russian (just over the past few days).

That brings the total number of translations up to seven for this one cartoon.

Check them out here.

If you are interested in helping with any other translations (they do not just need to be the Pig and Chicken cartoon), please contact me!

Thank you,

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

French Version of The Classic Story of the Pig and Chicken

mvizdos@gmail.com — 2007-03-27T20:24:06-04:00

Wahoo!

The cartoon of "The Classic Story of the Pig and Chicken" is now translated into French. Check it out here.

If you are interested in helping with any other translations, please contact me!

Thank you,

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

Get a Life.

mvizdos@gmail.com — 2007-03-26T19:37:22-04:00

Get a Life.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

So, I planned this awesome blog entry for this week.

It will have to wait.

My three year old wanted me to read a story to him.

Now my six year old wants to read to me.

Priorities.

Lesson learned?

More tomorrow.

Unless of course my kid wants to read to me. OK? We have one chance in this life.

Live it.

Fully.

I will write more tomorrow.

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!


Originally Published:
March 26, 2007

[ANN] SD West: Follow-Up

mvizdos@gmail.com — 2007-03-22T23:34:20-04:00

Hi all,

Wanted to let you know what happened out in California on Thursday while I was at SD West (www.sdexpo.com).

I met with a few people and groups and we will have some exciting news in the near future about the site in general.

One of the immediate things I can talk about is the fact that this site will be syndicated on CM CrossRoads and The Agile Journal and you should see some press around that in the next week (see... being a subscriber via e-mail or RSS pays off for some of this great "inside information" (smile)).

I also facilitated a discussion with about 40 people in a round-table format during the conference. I think it was one of the best groups I have worked with to date, and if the guy that took pictures of the large post-it notes (that were created during the talk) sends them to me, I will post the information and make another announcement as to where you can talk yet another glimpse at some great information about Scrum in the Real World. I have submitted a proposal to present it again at SD East in Boston later this year -- but with a twist. I will let you know if it gets accepted and what it can mean for you!

I hope you have a great weekend. I am about to hop on a plane for the red-eye back to the east coast. Fun stuff!

Thanks for reading, commenting, and continuing to read this blog and passing it on to your colleagues.

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

German Version of The Classic Story of the Pig and Chicken

mvizdos@gmail.com — 2007-03-22T00:22:04-04:00

Wahoo!

The cartoon of "The Classic Story of the Pig and Chicken" is now translated into German. Check it out here.

If you are interested in helping with any other translations, please contact me!

Thank you,

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

[ANN] SD West: Thursday, California

mvizdos@gmail.com — 2007-03-20T18:51:40-04:00

Hi all,

I will be facilitating a round-table discussion at SD West (www.sdexpo.com) on Thursday afternoon. It is entitled: "Scrum: A Five Letter Word Geeks to Need Learn."

If you (or people from your organization) are headed to the conference, I encourage you to attend. The past few times I have organized the talk in this format there has been awesome participation and great information sharing!

Here is the link with the information:

https://www.cmpevents.com/SDw7/a.asp?option=G&V=3&id=257617

If you cannot attend the workshop, try to stop by and say "hi"!

Thank you,

- mike vizdos
www.implementingscrum.com
www.michaelvizdos.com
619-709-1716 (cell)

How to get out of a Speeding Ticket.

mvizdos@gmail.com — 2007-03-19T19:39:46-04:00

How to get out of a Speeding Ticket.

 
    							                		 				                       				                    					     

*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

As a Scrum Master, you may have the opportunity to work with multiple teams as time goes on.

This can be a fun and exciting time because sometimes you may work with a team long enough that coaching the same team may get boring – especially if the team is just moving along and being productive (smile).

One of the things I like to chat about with an existing ScrumMaster is the concept of being able to move from "zero to sixty" within and among Scrum Teams.

What does this mean?

Scrum is a change.

Some may consider it an organizational change (a topic for the future!).

As a ScrumMaster, you are an agent of change.

When you are working on a Scrum Team, the team goes through the normal team "stuff" that teams go through to become a cohesive unit. Things and people mesh. Inside jokes prevail. Little things become normal, and sometimes people can start finishing another team members sentences or thoughts.

Then….

The team finishes a project and those people may go on to start new teams (or join existing teams). Some team members go back to traditional waterfall projects while others may have the opportunity to go to a new Scrum Team.

This story really apples to any role, be it a ScrumMaster, Product Owner, or Team Member. I do want to point out here that as a ScrumMaster, it is your responsibility to know and understand what is happening.

So.

When you go to a new team, remember this: It is a new team.

And, when you start a new team, I remind folks that they need to "start over."

As a ScrumMaster (possibly working on one or more teams, or even a serial Scrum Master (hmmm)), you need to realize that each team you work with are in different places of their lifecycle as a team.

You need to recognize "where" the team you are working with "is" on the team formation cycle, and be able to walk into the current situation to help them along.

Team A is not Team B is not Team C.

ScrumMaster must work with all different Scrum Teams -- A,B, and C.

ScrumMaster must mold and treat each team differently.

Including when you play the role of ScrumMaster and how you perform that role on each of the various teams.

And be able to go from "0 to 60" on a daily basis if needed.

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!


Originally Published:
March 19, 2007

Whiskey Tango Foxtrot? Over.

mvizdos@gmail.com — 2007-03-12T20:58:56-04:00

Whiskey Tango Foxtrot? Over.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

Wow.

Last week I must have hit a nerve with some of my readers. I received a ton of email responses (both positive and negative) and thank everyone for their comments. Keep them coming as I try to respond to everyone who takes the time to send their comments, thoughts, and suggestions.

Last week a common theme began occurring in conversations all around me. So I thought I'd better listen and actually write about it more.

Questions I ran into (or should I say, ran into me) last week included the following:

"Can a team max out their velocity using Scrum?"

"Is there such thing as a "ceiling" to the amount of work that can be done in a Sprint?"

"What is the terminal velocity of a Scrum Team?"

These questions [and answers that were discussed] interested me. They occurred in small one-person hallway conversations, online via email, and a topic at an Open Space {LINK} APLN-Richmond Meeting (facilitated by Joe Little (and his wiki) last Wednesday evening.

First, I had to go to our friends at wikipedia to remind myself of the definition of terminal velocity (kept thinking back to high school and 9.8 meters/second/second):

"The terminal velocity of an object falling towards the earth, in non-vacuum is the speed at which the weight of an object and the air resistance, or drag, balance, thus giving it a final,or end, velocity also known as Terminal Velocity."

For someone sky-diving with (or I guess, without) an un-opened parachute, it is about 120 miles per hour (195 km/hour). Fast. So this is the interesting thing... there IS a limit to how fast one can fall.

How does this relate to the topic of a velocity for a Scrum Team?

I have been challenged in the past to defend my idea that a Scrum Team truly does have an upper limit, or ceiling, that they can work within. I usually take the side of, "If a team is highly functional and coherent, there really is no limit of the velocity they can reach by working together."

I found out that sometimes, as the saying goes, "Them's fighten words."

In Scrum, the velocity of a team can be viewed on the burndown chart. Usually, this can be tracked by figuring out what User Stories are complete.

So what if a Scrum Team "finally" gets to a plateau (or ceiling) in its velocity? Or, the question should be, "When they plateau?"

Let's say the team started using Scrum three months ago. After a few rough beginning Sprints, their velocity was computed to be 28 points per sprint. And, they have held steady since then.

They are producing and humming along as a real team. They have a regular "heartbeat" of the Scrum lifecycle.

Now... The Chickens step in and start demanding more.

Two ways I have seen (and was reminded last week at the APLN meeting) a team respond included:

- The team allowed the Chickens to add new team members or allow them to be pushed into working longer hours. We all know this is not sustainable and can lead to team burnout.

Always.

- The team started to figure out on their own how they could become better. Hmmm... they thought... what about amping up our engineering practices (such as pair programming)? Other ideas come out of the team and they keep getting better!

Does this mean the team must make a jump from working 40 hours a week to 80 hours a week?

No.

No.

No.

It means they -- as a team -- figure out for themselves what works for THEM. And this is where the power of Scrum can be seen (heck, don't even worry about Scrum at this point, you are in the realm of working with a truly high-performing team!).

Circle back to the original question.

Is there a limit to what a team can do to increase their velocity?

I submit the answer is still a solid "No."

If you are hesitating about taking that stance, I challenge you to go back to your team (not as a Chicken!) and figure out what you can do to make things better.

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!


Originally Published:
March 12, 2007

Translation. Get Ready for a Vulcan Mild Meld!

mvizdos@gmail.com — 2007-03-07T01:45:21-05:00

Translation. Get Ready for a Vulcan Mild Meld!

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

Wow. Yesterdays entry sparked some mega-interest. If you have not had a chance to look at it -- or pass it on to your friends -- you can look at it here!

We have our first offer for translating this site from friends in the Ukraine!

If you are interested in helping with this specific translation effort, Max Pendyschtschuk and Roman Muntyanu are coordinating the effort.

You can send your info directly to GotischeRose@yahoo.de with subject "ImplementingScrum into the Ukrainian".

If you are interested in translating any portion of the site into another language, please contact me and we can get the process started (I see a lot of traffic with the following languages: French, German, Spanish, Portuguese, Dutch, Italian, Swedish, Russian, Norwegian, and Chinese.)

in addition to this great news, I will also let the readers of this blog (you!) know that I am planning on offering two Certified Scrum Master Workshops in Ukraine, Kiev (Kyiv), this June. The first will be 14-15 June and the second will be held 21-22 June. In between the two workshops I will hold there, we are also working on getting me up to Moscow to teach a workshop there.

More details (pricing, location) will follow and also keep an eye on the following pages (for translated information about the workshop and logistical information):

http://www.krivitsky.com/2007/02/scrum-trainings-and-other-events-in.html
http://www.agileukraine.org/

Thanks for the interest and let's see where the site continues to evolve....

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!


Originally Published:
March 6, 2007

Crack Cocaine. First Scrum is FREE!

mvizdos@gmail.com — 2007-03-05T21:18:24-05:00

Crack Cocaine. First Scrum is FREE!


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

The topic for this week is regarding the use of software tools on a Scrum team.

I am going to write about some of the commercial and open source tools that are available today. In addition, I will continue my public stance that these tools should not be used by a Scrum team -- and give you evidence from real-world experiences about what I continue to take this hard-line stance.

Feel free to ignore me (as usual!). This is just my opinion. Like the rest of this site (smile).

[Full Disclosure ON]

I am not affiliated with any of the tool vendors mentioned in this blog entry. I have used some of the tools at various client sites and have worked with demos from some of the companies. I am not receiving any financial gain (or loss) from the companies mentioned. I know the main people at each of the companies and have spoken with them in the past about tool usage for agile and Scrum teams. They are nice people (smile).

[Full Disclosure OFF]

The "Software" Scrum tools out there include Version One (versionone.com), Rally Software (http://rallysoftwaredevelopment.com), Scrumworks Pro(http:/danube.com/scrumworks/pro) as commercial products.

There are more. And there are write-ups about the different tools (for example, "Fear and Loathing (http://weblogs.asp.net/bsimser/archive/2006/10/21/Scrum-Tools-Roundup.aspx or Dave Froslie - Microsoft Development on the Prairie http://blogs.msdn.com/dave_froslie/archive/2005/12/15/504251.aspx)

Open Source tools include XPlanner (http://xplanner.org/) and others that pop up on a regular basis (for instance, I heard about a new tool just last week called Project Dune (http://sourceforge.net/forum/forum.php?forum_id=671252).

There is always Microsoft Excel for the die-hard MS fans.

Microsoft Project is one tool I would not even consider using on a Scrum Team.

So, those are the "Software" tools that are available today.

Are there more?

Sure.

Will there be more in the future?

Of course. Geeks like to create tools. And marketing folks like to sell seats (licenses) for them.

"So Mike," you may be asking me at this point, "Clearly the market has shown a need for these software tools, and people are buying them (or at least trying their demos!). You must be smoking something if you think software tools provide zero value to Scrum teams."

First, I am not smoking anything. Or snorting. Or injecting. Or swallowing. Gulp.

The software tool mainly provides value to the software vendor. Remember, their goal is to sell "seats" or "follow-on" consulting services. Heh... remembering also that this statement comes from a consultant (who does not sell software tools).

And, wow, I work with teams that actually use these software tools; some clients even go as far as growing their own internal versions (so they can print cards nicely or bla bla bla).

Congratulations.

And what value does that bring to your team?

Think about this.

And then...

Here are some conversations I start hearing when software tools start getting involved / used on Scrum teams:

"Please make sure you update tool X so that we can report our burndown to [someone who is not even in the room]."

"Holy Shit. Our tool is down. What do we DO now?" [mad scramble ensues]

"I love this tool. It keeps me from having to be in the room all the time....."

"I love this tool. I do not have to talk to anyone about what I am working on anymore. I can just enter my tasks and user stories in and just worry about the stuff I am working on."

"Look at these cool graphs."

"Wow. Our estimated time for a task was off my 37.5%, how do we 'fix' that delta so we don't get dinged for giving bad estimates."

"Oh, we do not have a bundown because our software tool admin is out of the country for a few weeks. And we do not show task cards or user stories anymore."

And... I could continue for hours (really... and this makes me sad... barfy sad sigh).

I discourage the use of tools at any point in the project, but teams almost always want to use them :). Geeks.

Are you seeing where this can have a reallllllllllly negative impact on the team and how the team works together?

The scary thing is, when teams get started using tools, it can be perceived as crack cocaine.

The first one is "free" (demo).

Then... The tool starts taking grip on the team. And starts growing to other teams within the organization.

Hmmm... now internal compliance people (at an enterprise level, these people say what applications "can" and "cannot" run on your machine) get wind of it.

Bad things start to happen.

So an internal software tool starts getting developed. This takes resources -- or usually one poor schmoe who winds up doing it off the side-of-desk -- away from the main goal of the team.

The compliance people may get involved again because hey, you are running some internal tool that is not supported by the enterprise and gulp, you are running it using a non-standard database (i.e. Microsoft Access etc.).

And then, and this is the really scary part, Chickens get this great idea that they can start comparing team velocities and setting up a control center or dashboard of some type to magically report what is happening in their kingdom. [Bad idea -- here is why.

Throughout all of this, the comments I made above -- REAL comments I have heard from teams using software tools -- take place and start eroding the real purpose of why a team started using Scrum in the first place.

"So Mike," you may be thinking. "What are the alternatives?"

My advice.

Keep it simple.

Really.

The alternatives include index cards, some markers, large post-it notes, and whiteboards.

I know, whiteboards can sometimes be harder to get than ordering new software for the team. Do not use that as an excuse to start using software tools.

And yes, whiteboards can get erased. It's OK. Life goes on. And, since your team is actually using a whiteboard on a daily basis to discuss stuff, it may not be all that bad to refactor the board once in a while anyway (smile).

Remember the goal of setting up your team implementing Scrum?

Did you have one?

Was it to actually develop working software?

Think about it.

Delivering working software does not include "software tools" to get your there.

All the "stuff" I wrote about above regarding the use of "software tools" takes the team away from the primary goal.

I have actually seen teams burn more than 50% or their available velocity in trying to maintain a software tool.

Yikes.

50%???

Or more???

For WHAT????

Huh? Where the heck is the Product Owner in all of this?

Hopefully not the one saying, "I love this tool because I do not have to be in the room to answer questions anymore." Unfortunately, I have heard this during a Sprint Review in the past.

Uggggggggggggggggg.

Just because you have a hammer does not mean it is the right tool for everyone. Or every team. Sometimes you can use a small screwdriver to finesse something together instead of whipping out THE big hammer and causing more collateral damage than good.

As software professionals, we should all carry a toolbox of things we can use. Sometimes, a "software tool" makes sense (hammer) while others it makes sense to use manual techniques.

And not lose site of your Sprint Goal.

Really.

Gotta run...

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

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


Originally Published:
March 5, 2007

Like it? Digg it!

mvizdos@gmail.com — 2007-02-27T22:52:54-05:00

Like it? Digg it!

Welcome back to www.implementingscrum.com.

I added a button to help you -- my reader -- have the ability to help spread the word even more about the site. It looks like this:

Let me know if you have any questions about what to do with it, or how it can help grow this site even more!

Gotta run...

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

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


Originally Published:
February 27, 2007

Evolution. Or a Revolution?

mvizdos@gmail.com — 2007-02-26T16:15:17-05:00

Evolution. Or a Revolution?


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

Today I am going to cover a lot of ground at a pretty high level.

I have written about some of these concepts in the past, and this blog entry takes it up a notch (so hang in there with me!).

So in Scrum there are only three defined roles....

Scrum Master
Product Owner
Team Member.

That is all. Really.

And this is your team.

This is the team to deliver the completed work item.

Now, there are people out there who discuss (argue?) about which of the roles above is part of the team.

My answer:

All of the roles are members of the team.

It is critical that the roles are defined on a team, understood by the team (and its stakeholders // Chickens), and enforced by the team (not by the stakeholders // Chickens).

Pigs versus Chickens. See this blog entry for more information about this concept.

I'd say all three of the defined roles are Pigs. You cannot be a Pigkin.

Does this mean Pigs and Chickens do not talk?

No. Of course they talk.

However, it is their interactions between the Pigs and Chickens that may differ among the three roles.

The Scrum Master must interact with the Chickens to help remove impediments. When the team asks for it. The Scrum Master is also the facilitator of the process for the team. This person is an active member of the team.

The Product Owner must intereact with the Chickens to make sure questions are answered and addressed (from the team members asking). Remember... the Product Owner "owns" the Product Backlog and is responsible for prioritizing it for the team in order to perform effective Sprint Planning (and execution of the Sprint).

Does that mean the Product Owner is ruler supreme?

No. Of course not.

The Product Owner needs to be available to team members for answering questions and helping lend a hand to the team members when time is available.

Wow. Ummm. This is a debatable area.

However.

I have found that when a Product Owner actually has the time / bandwidth to act as a productive member of the team, both the other team members and the Product Owner learn a ton from the other. So, in addition to blocking and tackling the "noise" for the team from outside stakeholders (which sometimes takes almost 100% of their time), the Product Owner is also negotiating with the other stakeholders about the items on the Product Backlog and the said prioritization with that list.

More information about the Product Owner role can be found here [LINK].

This leads us to the last role, a "team member."

It is fun (and rewarding for all) to see the evolution of a team from specialists (I am a tester, I am an architect, etc.) to "I am a member of X team" (see generalizing specialists).

And, I'd say the Scrum Master and Product Owner are an active part of the team.

This happens to a naturally evolving and growing team.

Really.

All teams. Who want it to happen.

Bruce Tuckman has written extensively on the stages a team goes through during its development.

They include:

Forming.
Storming.
Norming.
Performing.

And, as Mark Pushinsky (one of the trainers I co-teach with) has added...

Mourning. (Although it looks like Dr. Tuckman may be calling this adjourning... see we may not be all that creative lol).

The reason for this addition is when a team is "done" doing its work, the team members do need time to decompress and figure out how to "start over" with a new team as they leave the current team.

This process happens with all teams.

And.

You cannot skip any of the stages.

If you try, go back to ground zero and start again at Forming.

Also.

If your team changes at any point during its life (people come and go), guess what?

You need to start over at ground zero all over again.

Is all the above correct? I think there will be debates (ahh... better word than arguments) from people about this minuta for years to come.

Gotta run...

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

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


Originally Published:
February 26, 2007

Abnormal Scrum. Call the Terminator.

mvizdos@gmail.com — 2007-02-19T19:47:12-05:00

Abnormal Scrum. Call the Terminator.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

This week I want to discuss something that does not happen very frequently; however, as a Scrum Master -- or member of a Scrum Team -- you need to be aware of its existence and the power you have to use it.

This is something I teach on a regular basis (in fact, just last week in San Diego, California!)...

There is something called a Scrum Abnormal Termination. Here are the "rules":

- Sprints can be canceled before the allotted thirty days are over;
- Team can cancel Sprint if they feel they are unable to meet the Sprint goal;
- Management can cancel Sprint if external circumstances negate the value of the Sprint goal; and
- If a Sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.

One of the things we teach during the workshop is the concept of a "wailing circle", where the team lays (lies?) down in a circle with their feet together and cries out in a loud voice. The purpose of this is to make it look ridiculous. It does. Sigh.

Actually, I have personally stopped bringing people up to the room and presenting this as an exercise. One of the main reasons for doing this is the reaction it had during the workshop. Think crickets at night. Then stopping in dead silence.

Ohhhhhhhhhh K. So.

I inspect and adapt. I have learned (smile).

So is this really something that happens in the real world?

Yes.

Do I tell the teams they need to do the wailing circle?

Nope.

How often does a Sprint Termination happen?

Rarely.

Really.

It should be used to make a point. Let's review the options presented above:

-- Sprints can be canceled before the allotted thirty days are over;

We all live in the real world. Because a Sprint starts out to be thirty days (or whatever the length is for your Sprint -- as long as it is consistent!) does not mean things do not change in that time period. I have used this once in this case because there was a major reorganization at a client site during the middle of a Sprint. Half the team got whacked. I figured it was a good thing to take a breather and start a new Sprint when things settled down. Was it according to any book? No. Did it make sense? Sure. And the team found its was again. Eventually.

-- Team can cancel Sprint if they feel they are unable to meet the Sprint goal;

If you start a Sprint with the a technical choice (for example -- batch versus real time solutions) and the team figures out a solution to one choice over the other in the middle of a Sprint... would it make sense to stop things and re-plan using this new information? As a team, they can decide that. As a Scrum Master, you need to be able to facilitate this.

-- Management can cancel Sprint if external circumstances negate the value of the Sprint goal;

OK. This one is not an excuse for the Chickens to run the asylum. Really. However, let's pretend the team is working for an organization in a highly federally-regulated environment. And, let's pretend that Congress makes a change that has an immediate external impact on the direction of the team. Now... stop pretending because, guess what, as a team you cannot just break laws at your leisure. Or well... it is not highly recommended. Remind the chickens that this part of the rule is not to allow for canceling a Sprint at their own peril. Think about it. And help guide the Chickens when trying to make a call like this.

-- If a Sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.

What do you do at the end of every Sprint? Besides the Sprint Review, there is a Sprint Retrospective. Have one. Then, when the time comes (it may be immediate, it may not), embark on Sprint Planning, Rinse, and Repeat as directed.

And to think, I could have brought Arnold Schwarzenegger into the comic strip this week. I went for the artsy-fartsy example. That being said...

"I'll be back...."

Sigh. Sorry. Needed to say that (smile).

Gotta run...

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

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


Originally Published:
February 19, 2007

Scrum. Do Not Plan. Really.

mvizdos@gmail.com — 2007-02-12T21:09:30-05:00

Scrum. Do Not Plan. Really.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

One of the things I hear often -- usually with teams who are using only partial Scrum practices -- is the quote, "This is Agile. We do not plan."

Ug. Nothing can be farther from the truth on this one.

Scrum is not a license to be a hacker.

Scrum is not a license to pick and choose selective parts of the practice for you to implement.

And.

Scrum is not a silver bullet.

That being said, why am I so adamant about wanting to strangle people when they say, "This is Agile. We do not plan."

I am glad you asked (smile).

From Mike Cohn, we know that in Scrum there are three levels of planning. The first is Release Planning. The second is Iteration (or Sprint) Planning. The third is Daily Planning.

I will examine each planning cycle from what I understand by doing it on a daily basis. For other information about this (more details, etc.) see Mike Cohn's book(s). Remember the following views are what I have learned through practice....

--- Release Planning

This is accomplished through the use of the Product Backlog.

One of the common themes a Product Backlog helps answer is, "When we you be done?"

Remember in Waterfall Projects a Project Manager is handed a date (usually out of thin air) and then, come hell or high water, a project is decalred "successful" on that date. Sometimes to the dismay of the team who knows things were cut (think quality). I know this is just one example of what can happen, but it does. All too often (and before Agile I was guilty on both sides of doing this).

With projects using Scrum, the Date and Budget are fixed. Scope is move able. See this posting. How is this different than a Waterfall Project? For me, it means that the team has an active discussion with the Product Owner about what is happening in reality. Sometimes is sucks. But. These discussions need to happen. Welcome to one of the joys of being a Scrum Master!

How do you do Release Planning with the Product Backlog? After the first Iteration / Sprint or two, the team has a good idea of the velocity. If you are using Story Points, you take the total number of Story Points, divide it by your velocity, and it will tell you how long the Release will take.

That's it. It is that simple.

The discussions that take place can be tough. Life can be that way.

--- Sprint (Iteration) Planning

This is done by taking the highest priority stories off of the Product Backlog. And the team having a discussion with the Product Owner about what the team can during the Sprint. Estimate out the stories (sometimes using ideal days / hours). And again, have a conversation with the Product Owner about what you can do as a team.

Pretty reasonable. Again.... tough to do.

And stick to it. Keep the Product Owner on task for making sure NOTHING else (other tasks) get into the current Sprint. This is a hard thing. Again, it gets easier with time!

--- Daily Planning

Say it with me... "Daily Stand-up Meeting" (or "Daily Scrum"). And... what are the three questions?

1) What have you done since the last stand-up?

2) What will you complete before the next stand-up?

3) What is in your way?

That's it. People can "talk" to the task cards, or they can talk "to" a user story. It depends on what the team likes doing. Let the team decide. Let the team waffle on this for a while, and allow it to change over time. The important thing is that people are talking. Communicating. And keeping it to fifteen minutes.

Read that last sentence... in case you forgot... Keep it to fifteen minutes!

So, with all this planning happening, can you really say that Scrum has no planning?

If you still do think that... maybe take a look at how your team is implementing Scrum.

Gotta run...

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

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


Originally Published:
February 12, 2007

More Fun Than Watching Paint Dry. Or Grass Grow.

mvizdos@gmail.com — 2007-02-05T18:42:49-05:00

More Fun Than Watching Paint Dry. Or Grass Grow.


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

Welcome back to a new week at www.implementingscrum.com. Wow. A month has already passed in 2007. Yikes... where does the time go? I do hope you have enjoyed the journey of learning more about Scrum with me so far... hang with me and we will continue to learn -- together.

One of the questions I get as a Scrum Master is "What do you do?" (And this is not just from my family and friends.)

Sometimes it gets asked as "What do you DOooooooooooooooOOOooooo?" This blog entry will not explain "what" a Scrum Master does, but more about HOW *I* as a Scrum Master help get it started.

My style when going into an organization is to watch and listen.

Really.

I have learned that silence can teach me -- and others learning with me -- more than I can sometimes even teach my talking or yapping away.

And it looks like I am just "sitting there".

This is a usual pattern of mine since I work with a lot of teams making the transition from waterfall project management to the Scrum framework. And it requires a big shift in change and patterns from the team making the transition to Agile and Scrum.

It -- "the shift" -- does not happen overnight. Trying to go commando-uuber-religion-Scrum-like is a turnoff to any team. Trust me (licking my wounds).

So... pigs (who are busting their asses sometimes working 24*7 and trying to really see that a work-life balance may work for them) and chickens (who may be paying for me to sit and watch them) ask this question a lot.

Even if it is not to me directly. Actually, people sometimes ask me directly, "Mike, do you even know what you are doing?" Um. Yes. I do. Am I always successful with this technique? Nope. I am human. I make mistakes and move on. And learn from them.

When do I engage?

I usually wind up engaging pretty quickly. But it is the "how" I engage that sets me apart as a Scrum Master versus a traditional Waterfall Project Manager.

[tangent on]

I have the greatest respect for Waterfall Project Managers. I used to be one. Felt powerful. And "in charge." I also used to be a work-a-holic and had no work-life balance to speak of. I then made the "impossible" choice to look at -- and implement -- more agile techniques. It was a personal choice and it is not for everyone.

[tangent off]

How is a Traditional Waterfall Project Manager different than a Scrum Master?

Well, one way that became very clear to me recently is that Project Managers manage to Budget and Time along the Iron Triangle. With Scrum, those two lines are "fixed" -- and Scope is the negotiable factor. It leads to a lot of interesting conversations if you are open to receiving feedback from some Project Managers about how Scrum is non-managable. I literally saw some Project Managers' head almost blow up when talking to the them about this situation. Wow.

As a Scrum Master, instead of saying things like, "Instead of doing such and such...." I will talk about ways I engage at a subtle level and allow the team to make a choice.

I think most regular readers will of this blog know that Silence works. For those of you who may be reading my blog for the first time, or have not seen me write about it... think about this. Over my phone (on my monitor) I wrote a sticky-note that reads, "Shut Up. And Listen."

Huh?

Most people I speak with like the act of talking and being heard. Hey, I like it too (you are reading this blog with no real opportunity to speak with me about it other than via email or picking up the phone to speak with me). But I have found that when I am done "talking" -- I stop.

And listen.

This can be hard. Many people do not like to hear the sound of silence, and usually someone will jump in to fill the void. I work hard to make sure that person jumping in is not me.

Try it.

See what you can learn.

"But Mike, people PAY you to give advice."

That may be the case for a lot of my clients before I work with them. Before beginning any engagement, I do try to set expectations -- and this "silence" thing is one that is tough to swallow.

Why do I insist on it? Other than past learnings (ouch)....

I want to help the team -- from day one -- start to start thinking and acting on their own. Once I jump in to "answer" a question -- or anyone does for that matter -- it can lead to a dependence on some one person always having the answer. As a Waterfall Project Manager, I thought one of my jobs was to always "have the answer." Where did that get me? Sigh. That is fodder for another blog entry (smile).

Your job as a Scrum Master is tough sometimes. This is one area of advice I wish someone had shared with me when I started on this journey.

Is this tact something that all Scrum Masters should start using?

Nope.

Find out what works for you. And the team.

Gotta run...

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

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

Now... I will shut up. And listen.....


Originally Published:
February 5, 2007

Do Task Updates Matter?

mvizdos@gmail.com — 2007-01-29T20:40:06-05:00

Do Task Updates Matter?


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

Hi all,

Welcome back to a new week at www.implementingscrum.com. The blog and comic strip today came from a user-submitted idea – one that I thought was great and I could expand on more this week for the rest of the readers out there. Thanks to the CCM team (one of my client teams) for submitting the following (edited to protect some of the innocent (smile)):

-------------------------------------------

Top Ten Reasons to Update Your Task Cards

- The team would know every day where they stand with current sprint.
- Senior leadership could walk in any time and determine if the team is being successful for current sprint.
- It shows your individual progress to the team.
- You will feel confident and good about achieving or doing something as it's documented.
- The rest of the team will feel the pressure to do the same.
- It empowers team to be competitive and successful.
- Mike Vizdos can make a cartoon out of task updating.
- The chickens would know the pigs are getting their work done.
- If David D. or John S. came back in the room, they would know we continue to use Agile processes
- It makes Marty and Venkat VERY happy!

Where Does Task Updating Show Up

- Daily Burn Down Chart.
- Factors into Product Burn Down Chart.
- Weekly Status Report.
- Weekly Updates to the PMO.

Who Sees Task Updating

- Anyone who walks into the room.
- Chickens.
- Senior Leaders like Ken A, Kathy K, & Patricia.
- Pigs.

-------------------------------------------

So, do I agree with everything written in the list above? No, not really. However, I am thrilled to see people taking the time to help shape the community with submitting new ideas, so I did not edit the list(s) in any way.

In the spirit of "Yes... And...." (this is different than the people who say, "Yes.... But....)... I'd like to add a few more thoughts of my own...

On writing task cards and user stories, check out www.mountaingoatsoftware.com where Mike Cohn has written some incredible books and has some great information about how to use these artifacts more effectively.

One thing that is also good for keeping the tasks updated in a visible location is to make sure it gives context to the also present (we hope) burndown chart. If people see the burndown chart without information to back it, assumptions may possibly be made that are incorrect or invalid altogether.

OK... I'd like to hear more feedback from you if you are interested in providing it...

Gotta run...

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

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


Originally Published:
January 29, 2007

[ANN] 3.5 Seats Remaining in Richmond!

mvizdos@gmail.com — 2007-01-25T18:41:32-05:00

[ANN] 3.5 Seats Remaining in Richmond!

Hi all,

Just wanted to let you know that I have exactly 3.5 prime seats left for my Certified Scrum Master Workshop in Richmond, Virginia on Monday and Tuesday next week (January 29-30). Fun will be had by all!

If you are interested please visit www.michaelvizdos.com/scrum for more information or go directly to www.michaelvizdos.com/enroll to sign up today!

If you cannot join me next week, I will be in Pittsburgh, PA and San Diego, CA soon.

And finally... If you are interested in a private session with your group -- contact me directly.

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

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


Originally Published:
January 25, 2007

Is a Waterfall Silent?

mvizdos@gmail.com — 2007-01-22T22:13:45-05:00

Is a Waterfall Silent?


*** Interested in becoming a Certified Scrum Master?  Come to my next workshop! ***

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

This week, I am writing about something that shocked me the first time I saw it happen... then I became numb from seeing it so much.

Now, I hope this article shocks me -- and others -- out of something that should never happen in on an Agile Team.

One of my colleagues once walked into a room with a new team. When he told me about it, he said something along the lines of, "It was so quiet you could hear the waterfall."

Think about that last statement for a moment. I'll stick around.

Welcome back. Good thought break? Hope so.

When *I* hear this statement, I realize a team is probably not working to its full potential. There can be many reasons for this.

The first reason, and obvious most of the time, is that a lot of people in our industry are introverts. For instance, I am an introvert. I have to actually *work* at talking to people and it does take a lot out of me when doing a workshop or meeting with a group of people. To recharge, I need quiet time alone. Other people I know are completely opposite... they are totally jazzed after doing a workshop or are completely comfortable when at a party working a room. They'd go crazy in silence.

So, how does this relate to an Agile Team Room?

Besides realizing the differences between introverts and extroverts, I also have realized that teams converting from waterfall methodologies (big up-front-designs) to working in a room with other people may need help making the transition.

When I see this as a serious problem -- and I do -- in new teams I work with, I work hard to actually settle in work with individuals to make little changes on a daily basis.

One person at a time.

This includes things like when scheduling a meeting within the room with the same team members... I work with people on the team to break out of the habit of scheduling something in Outlook (or other calendar systems) when it only impacts the members on the team. See... they are in the same room on a daily basis. If they are not.... influencing the breaking of this habit yields some great results.

So what do I do? After a standup in the morning, I try to facilitate team members to talk about when to "schedule" time to dive into details (usually discussed during the standup) using a white board or flip chart as their "new schedule". This starts getting people talking. And working together.

Making it visible to all involved parties. You never know what can happen when people start talking in the room -- and what others can actually contribute.

Usually after a few weeks people start realizing that they can actually do this on their own, throughout the day. Without "scheduling" meetings for internal meetings of the team members that are in the room together all day.

Sounds simple. But.

That is one of the hard habits to break on a team that is culturally adept at meetings to have meetings to have meetings (and so on).

The same ideas apply to the usage of Instant Messenger programs. I have sat and watched people in a room -- a totally silent room -- typing away "talking" to one another as they are sitting right with each other.

This is insane. But a regular occurrence.

As I see this happening, again I work with individuals in actually putting the two people together to talk. Using language skills instead of typing. Typing sucks as a way to communicate with each other... because I have read (and know this from experience) that 90% of all human interaction is by non-verbal cues. And, email or Instant Messenger cannot convey that.

Heck... This blog is one-way communication, with me trying to make assumptions that the reader (you!) understands what I am writing and how I really mean it. That is tough, especially since most of us have never met in person (nor we will ever).

So... if you see this happening on your team today -- or in the future -- work with individuals (one on one) to make small changes on a daily basis.

Doing this will result in a happier and more productive team. I promise.

Gotta run...

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

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


Originally Published:
January 22, 2007

Requesting Your Help. Please.

mvizdos@gmail.com — 2007-01-17T21:35:52-05:00

Hi all.

Thanks again for reading the blog and providing some awesome comments... please keep them coming!

I do not know if you have noticed, but at the bottom of every page published is a series of flags. I'd like to hear from you to see if they would be more valuable moving towards the top of the page.... but first, I need some people who actually READ those languages to check them out for me. So... If you can read one of the 13 languages this site is automagically translated into, please check out some of the links from the cartoon pages and let me know if they are even close to accurate -- or a waste of time to upkeep on my end. I use an auto-translator service, but I want to know if it is worth continuing!

Please check it out and let me know.

Thank you!

- mike vizdos
mjv@michaelvizdos.com

Cartoon -- January 15, 2007

Making Babies. Fast.

mvizdos@gmail.com — 2007-01-15T14:42:28-05:00

OK. So, maybe I messed up the punch line.

That is pretty normal for me. Sigh.

Cartoon -- January 15, 2007

Sick? Stay Home!

mvizdos@gmail.com — 2007-01-08T19:50:12-05:00

Sometimes, I point out the painfully obvious.

OK. Most of the time. Enjoy!

Cartoon -- January 8, 2007

CSM Training. Reality. Check.

mvizdos@gmail.com — 2007-01-03T11:10:23-05:00

Oh My Gosh.... He did not do that :).

This week we take a look at the journey that begins with a course. A CSM Course.

Cartoon -- January 2, 2007

Happy New Year!

mvizdos@gmail.com — 2007-01-02T18:51:55-05:00

Here is a quick highlight from the past few weeks...

Just before Christmas (in case you forgot), we examined collocation for an Agile Team. And looked at why people sometimes call it "A Jail" instead.

Cartoon -- December 18, 2006

The week of Christmas we took a look at the use of Burn Down charts -- or the lack thereof.

Cartoon -- December 26, 2006

Take a look. Enjoy, and provide feedback as usual. See you back here soon. The next comic will be a doozie!

Burn Baby Burn.

mvizdos@gmail.com — 2006-12-26T21:21:22-05:00

Wow. It amazes me how burn-down charts are abused. Help your teams stop this. Please.

Cartoon -- December 26, 2006

[ANN] Are you ready to Ruuuuuuumble in Richmond? January 29-30, 2007 CSM Workshop!

mvizdos@gmail.com — 2006-12-21T22:36:13-05:00

Mark Pushinsky and I (Michael Vizdos) will be hosting a Public Scrum Certification Workshop on January 29-30, 2007. If you are interested, please visit www.michaelvizdos.com/scrum for more information about the workshop.If you already know you'd like to go, visit www.michaelvizdos.com/enroll to sign-up now!

Go Directly to Jail. Do NOT Pass GO.

mvizdos@gmail.com — 2006-12-19T11:49:38-05:00

As a wise man once told me, "Excuses are like [insert body part reference here]. Everyone has one and they all stink." How does this relate to jail? Make your own connections and then continue to read more about it from me....

Cartoon -- December 18, 2006

Full Transparency [ON]

mvizdos@gmail.com — 2006-12-13T21:21:38-05:00

The following items will be covered in the Certified ScrumMaster training (effective November 2006 per Ken Schwaber):

1. Scrum is a framework for iterative, incremental development using cross-functional, self-managing teams. It is built on industry best practices, lean thinking, and empirical process control.

2. Scrum is optimized for high yield product management and product development. Scrum is particularly appropriate for high risk, complex, large projects and can be used when other parts of the endeavor are hardware or even waterfall development.

3. If waterfall suits current needs, continue using it.

4. An enterprise can use Scrum as a tool to become the best product development and management organization in its market. Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into such an organization.

5. Whenever an enterprise modifies or only partially implements Scrum, it is hiding or obscuring one or more dysfunctionalities that restrict its competence in product development and management.

6. The iterative, incremental nature of Scrum puts stress on the product development organization to improve its engineering skills and on the product management organization to optimize the return on investment of every release and project. The phrase, “That can’t be done here” really means that it will be very difficult to do so. The gap between current practices and target practices is a measure of incompetence and competitive risk.

7. The use of Scrum to become an optimized product development and management organization is a change process that must be led from the top and requires change by everyone within the enterprise. Change is extremely difficult and fraught with conflict, and may take many years of sustained effort. Turnover of staff and management can be expected.

8. The most serious impediments to using Scrum are habits of waterfall, predictive thinking over the last twenty to thirty years; these have spawned command and control management, belief that demanding something will make it happen, and the willingness of development to cut quality to meet dates. These are inbred habits that we aren’t even aware of anymore.

9. The focus of using Scrum is the change from old habits to new ways of doing business. Scrum is not implemented or rolled-out as a process; it is used to foment change.

10. Scrum is not a methodology that needs enhancing. That is how we got in trouble in the first place, thinking that the problem was not having a perfect methodology. Effort centers on the changes in the enterprise that is needed.

11. Iterative, incremental development is much harder than waterfall development; everything that was hard in waterfall engineering practices now has to be done every iteration, and this is incredibly hard. It is not impossible, but has to be worked toward over time.

12. Managing a release or project to deliver only the highest value functionality and not deliver the rest optimizes value is the job of product management and customers.

13. Self-managing teams are extremely productive. When they work closely with the customer to derive the best solution to a need, they and the customer are even more productive.

14. A team consists of people under pressure to do their best. Conflict is natural and the team needs to know how to deal with the conflict and have resources to draw on when needed.

15. The role of an enterprises management changes from telling people what to do to leading and helping everyone do their best to achieve goals. People aren’t resources and managers aren’t bosses.

Oops. I Suck. And Somebody is Mad.

mvizdos@gmail.com — 2006-12-12T20:33:11-05:00

The following cartoon was put up last month and Ken Schwaber liked it.

Cartoon -- November 6, 2006

Today, I have found out that I am banned from a yahoo group that I frequented -- for basically pointing out that there were some dysfunctional things happening on the list.

I have started a new thread to discuss the job of a Scrum Master as a Facilitator. Please join me in this discussion and others.

Forum Entry -- December 12, 2006

BBQ Sauce. Sweet or Hot?

mvizdos@gmail.com — 2006-12-11T19:19:59-05:00

Personally, I like it spicy. But then again, I am not usually a Pig....

Cartoon -- December 11, 2006

Lipstick Remover...

mvizdos@gmail.com — 2006-12-04T22:46:54-05:00

This is not the place to find out about those sick jokes. Phew.

Cartoon -- December 4, 2006

Is This Community Transparent?

mvizdos@gmail.com — 2006-11-30T20:10:15-05:00

For those of you unfamiliar with the practice of Transparency in Scrum, take a look here for a refresher. I'll wait.

After some serious soul searching this week, I came to the conclusion (right or wrong) that since one of the major Scrum yahoo lists actually "banned" someone for participating in a heated thread that I would open up my own forum on this site. It can be found at www.implementingscrum.com/forum and I, as the moderator, will allow just about anything to be said as long as people have fun, do not attack one another, and remain professional. I will not kick anyone off who has a dissenting opinion.... if anything, I think that adds to the value of the forum.

Please feel free to join us at the new forum and let's see if some real transparency can be opened up in our small community.

Gotta run,

- mike
www.michaelvizdos.com/scrum
www.implementingscrum.com

Please send comments, questions, criticisms, ideas, or whatever here. You can also enter The Forum to discuss this cartoon and other Scrum topics. Thank you!

---------------------------------------
---------------------------------------

Chickens and Pigs. Get Over It. Please.

mvizdos@gmail.com — 2006-11-29T23:11:34-05:00

Hi all,

Since starting the site back in September, I have received a lot of email from readers regarding the cartoon about the Chicken and Pig. If you are not familiar with the story, please go read it here.

Please note: This is not a story I started. It has been around for a long time (even since before Scrum -- applied in different circumstances).

I had one very long email thread (that I may one day publish here) that discusses how I am degrading people by referring to them as Chickens and Pigs.

Three words:

Get over it.

In addition to being a great way to have people recognize the role they play on a Scrum team, the analogy has allowed Tony and I to create this cartoon and website.

Cool stuff.

Maybe it is even something you'd like to pass around to your geek friends and neighbors.

And laugh. We all need that once in a while.

I hope you agree.

I still do intend to continue publishing on this site using Chickens, Pigs, and other "cast members" (including the Scrum Master, Product Owner, and "Ken"). Who knows what else will appear in the future!

If any real Chickens and Pigs are offended, please tell them I apologize. No Animals, Scrum Masters, or Product Owners are being hurt in the production of this cartoon series (smile).

Have a great day!

- mike

Done. Really?

mvizdos@gmail.com — 2006-11-27T06:29:57-05:00

Really. This week I examine how a team determines "done" and who makes the ultimate decision.

Cartoon -- November 27, 2006

[ANN] Opening of a New Forum

mvizdos@gmail.com — 2006-11-22T05:57:03-05:00

I am opening a new forum today in response to many reader requests. Please take a look around, register, and let me know what you think.

The Forum

The Food Factor. Another Metric.

mvizdos@gmail.com — 2006-11-20T21:18:29-05:00

Food.... Glorious Food.

Cartoon -- November 20, 2006

[ANN] Open Space. I will be there!

mvizdos@gmail.com — 2006-11-14T17:39:49-05:00

I will be arriving on Thursday afternoon (Nov. 16) in MN (will make it to the closing of the two days and then am attending the Trainers Gathering on Friday).

If anyone if interested in setting up a meeting with me (or buying me a beer or three!), please contact me.

For those of you who'd like an overview of what is happening on Wednesday and Thursday, read more here.

Open Space. It's Nothing Ordinary.

mvizdos@gmail.com — 2006-11-13T06:25:14-05:00

This week a bunch of people who enjoy Scrum will be meeting. How did they justify this trip to their boss?

Cartoon -- November 13, 2006

[ANN] New Feature - Help Spread the Word

mvizdos@gmail.com — 2006-11-09T07:20:03-05:00

Please feel free to use the widget below on your website, blog, or email it to a friend.

Get this widget!

You Suck. And Somebody is Sad.

mvizdos@gmail.com — 2006-11-06T06:30:56-05:00

One reason to fly first class is to meet interesting -- maybe even "glowing" -- personalities; today Chicken meets a colorful one at best!

Cartoon -- November 6, 2006

Shock Treatment for your Product Owner

mvizdos@gmail.com — 2006-10-30T06:38:29-05:00

The new character we introduce this week is the Product Owner. Not really a Pig, not really a Chicken. And definitely not a PigKin!

Cartoon -- October 30, 2006

Getting off the Island

mvizdos@gmail.com — 2006-10-23T03:35:37-04:00

Today it is all about the Island we call a Scrum Team. Good times...

Cartoon -- October 23, 2006

Transparency and Jessica Alba - A Scrum Connection?

mvizdos@gmail.com — 2006-10-16T02:27:17-04:00

Found out Tony (the creative illustrator here) has a thing for Jessica Alba.

Cartoon -- October 16, 2006

Summary of Cartoons

mvizdos@gmail.com — 2006-10-10T06:00:54-04:00

Want one place to see all the comic strips? Here is the place. You can continue to get updates via this blog entry, but rest assured you can see all the illustrations in one place now. Enjoy!

Cartoons

"The Fly" - This time, it's a Pig and Chicken...

mvizdos@gmail.com — 2006-10-09T06:40:29-04:00

I gotta hand it to Tony (the artist for this site), he really does "get" me. Scary. Anyway, see his rendition of a Pigkin and the start of my write-up for the week. It continues later...

Cartoon -- October 9, 2006

Scrum - Get out the Vaseline?

mvizdos@gmail.com — 2006-10-02T06:11:38-04:00

OK, so the title is a bit strange. But so is Scrum.

Cartoon -- October 2, 2006

RSS Feed Updates

mvizdos@gmail.com — 2006-09-25T18:16:12-04:00

... I am sorry if you have received bad links for the past two weeks.

In an agile fashion (smile?) I put up the initial links to the cartoons with bad headings. I am pretty sure it is all figured out. Please accept my apologies.

Here are the official links for the first two cartoons in the series:

Cartoon -- September 11, 2006
Cartoon -- September 25, 2006

Scrum - The Silver Bullet [NOT]

mvizdos@gmail.com — 2006-09-25T06:50:35-04:00

This introduction to the Scrum Master Role takes a light-hearted look at a common misperception as Scrum being a "Silver Bullet."

Cartoon -- September 25, 2006

The Classic Story of the Pig and Chicken

mvizdos@gmail.com — 2006-09-11T18:29:07-04:00

This is the classic story of a Chicken and Pig. These are the central characters for this cartoon series.

Cartoon -- September 11, 2006