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

What are the three roles?

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

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

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

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

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

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

Thank you!

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

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

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

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

Fair? (smile)

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

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

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

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

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

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

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

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

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

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

Inspect and Adapt.

Let’s see where we go.

As usual!

Thank you.

- mike vizdos

www.implementingscrum.com
www.michaelvizdos.com

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

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

Today, he is back at work.

And.

He did not die.

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

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

So what does this have to do with Scrum?

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

Not a lot of people like doing that.

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

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

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

It is a choice.

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

Wow.

Incredible things happen.

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

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

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

Saying “No.”

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

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

We all learn and move on.

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

Why am I telling you all of this?

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

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

Do you need help saying, “No” sometimes?

Where can you go for that help?

And remember… a dead ScrumMaster is a useless one.

DO NOT commit career suicide.

But remember… you DO have a choice.

Always.

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

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

Well, we have done it again. The boys (Dominic – almost 8 and Kenton almost 5) spent this evening adding some audio comments to an older strip that was created last year.

If you’d like to see the original posting, please go to http://www.implementingscrum.com/blog/2007/09/04/scary-team-retrospectives-part-one/.

Remember, this is from the point of view of my children, who are awesome at talking about what daddy does in English that everyone understands.

To see the video, look below:

As usual, comments and emails are welcome.

Thank you.

- mike (and Dominic and Kenton) Vizdos
www.michaelvizdos.com
www.implementingscrum.com

More to the point — useless meetings.

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

Ug.

Breath.

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

I know the feeling.

This familiar to you?

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

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

1) Schedule only when necessary.

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

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

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

2) Reduce the frequency.

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

Hmmm.

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

3) Create an agenda.

This one is easy.

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

Keep it simple.

4) Recap.

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

5) Do the minutes.

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

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

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

Some people call that “meeting.”

Time to get over it and start working together.

Getting some ideas of how to help get this working in your organization?
Gotta run!.Please send comments, questions, criticisms, ideas, or whatever here.

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

This week Tony and I complete the last of a three part series on Retrospectives. Part one is here and part two is there (smile).

This week we are covering a topic near and dear to a lot of people in the Scrum Community.

Retrospectives. Part Deux.

Last week I covered the “old way” team have done them.
This week.

How some teams do it today.
So called, “By the Book.”

Ooops.

But Mike, “It LOOKS so easy!”

Three Questions:

1) What went right?
2) What went wrong?
3) What can we improve the next iteration?

If a team begins to mature and grow, this type of format will become mind-numbing and create no real value to the team.

Think about it.

And. I mean this in the nicest way.

A lot of team members are technical.

And a lot of them can be introverted.

This means they may not like answering the same darn question after every Sprint.

Ug.

Even extroverts will get bored by this.

Really.

And then things start going South.

Your teams become less effective.

And.

Team members that are in this situation may recognize there is a problem.

In real life, they may not say anything. Usually — and this is unfortunate — they do not say anything.
Productivity suffers.

People start questioning what they are doing.

And the ScrumMaster may not have a clue.

Yikes.

What next?

The next part of this series will discuss what you as a ScrumMaster can do. And even as a team member on a Scrum Team.
If you are on a team today and see this is a problem, please get the word out that NEXT WEEK I will reveal some great solutions that may help you and your team become more effective.

Or at least take a shot at it.

Stick with it!

This week we are covering a topic near and dear to a lot of people in the Scrum Community.

Retrospectives.

[Edited April 5, 2008] I added a youtube video of this cartoon with my two sons — Dominc and Kenton. Check them out here:

I have been wanting to write about this topic since day one of this site; however, it kept sliding down my product backlog.

Why?

Mostly out of respect for this topic and the people in the Scrum Community who add to this valuable technique. Namely Esther Derby, Diana Larsen, and Norm Kerth.

This is going to be at least a two part series — maybe three.

Today’s posting looks back at the “old” way a traditional post-mortem was completed.

Think back. Or look at how you may possible be doing them today.

At the end of a project, management may have declared a project “successful.” This can take many formats, including actually delivering working software; however, many times in my own past I have attended these for one reason and one reason only — to complete a “check mark” on some project manager tick sheet. For compliance reasons.

We quickly talk about “lessons learned.” And of course they get filed away into the project notebook (or whatever you use for compliance and auditing).

NEVER to be looked at again.

Gulp.

And.

The team knows the project was a complete disaster.

Management is flying high because a date was “met”.

In the background, they are slapping high-fives with their peers because their project burned through two marriages and one person left the company because they were totally pissed off.

I have seen this happen.

And.

It makes me sad.

In the meeting, everyone gets around to sing happy camper songs and congratulatory awards are handed out.

“Congratulations. Katie worked 100 hour work weeks until the end and pulled in through for the team. And Joe, well, without him, the project would not have been where it is today.”

And them some $25.00 gift cards are handed out.

“Good job,” says the manager.

And.

The team is totally demoralized.

They know the product they delivered was not up to their own personal standards.

They know the product shipped with many bugs (but, because compliance says a product cannot ship with “severity one” bugs, mysteriously the night before all those pesky things were “downgraded” to a two or three — “Wahoo,” say the managers, “We shipped without any high severity bugs!”

Gulp.

So.

It may not be that bad where you work.

Unfortunately, I have seen this — sometimes many times.

And then people leave that project team to start a new project all over again. And guess what? They do the same thing again.

People become numb to the process.

People stop learning.

And.

It happens with both traditional waterfall teams and Scrum teams.

Today.

Is it happening with your team?

In the next part of this series, I am going to give you some solid techniques for dealing with this part of the process.

And not just “deal” with it.

But.

Make is a positive experience for everyone.

And.

Help improve your team and its interactions.

Sound like a dream?

At least it will not be a scary one.

There are things out there to help you.

Really!