This is a hard story to tell.

You may want to grab some Kleenex.

OK.

It is not that bad.

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

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

Names and places have been changed to protect the innocent.

But.

It is a story that must be told.

Since.

Well.

It involves me.

As the ScrumMaster.

And.

I wound up becoming a “Dead” ScrumMaster today.

How did that happen?

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

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

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

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

Boy.

I guess I did. In retrospect.

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

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

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

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

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

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

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

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

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

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

It was something the team could focus on.

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

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

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

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

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

We went home.

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

Kept it at 15 minutes.

People were off and doing real work.

It was cool to see. I stood back.

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

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

We started talking about the “Cone of Uncertainty.”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Get to “Done.”

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

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

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

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

Partly because I “sat in the corner” watching.

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

Partly because I did not code.

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

I am sure there are a lot of reasons.

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

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

Funny thing happened though.

I hear the team delivered working software.

And.

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

Is it perfect?

No.

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

I think so.

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

And.

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

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

It has happened to me before.

And.

Will again.

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

Is it any wonder that most teams fail using Scrum?

Yet.

I try.

As do others.

Yet.

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

And.

I am OK with that.

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

Read this lesson.

Read this real world situation.

And.

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

Talk about it with your stakeholders.

Talk about it with your Scrum Team.

Talk about it with your Product Owner.

Talk.

Have the conversations.

BEFORE things implode on you.

Because remember.

A Dead ScrumMaster is a useless ScrumMaster.

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

I apologize if it was a long one this week.

Lots for me to learn.

Still.

I may post more on this during the week.

And if you want to hire me (smile)….

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

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

Vegas. Hangover. Enlightenment.

---

---

Welcome back to a new week at www.implementingscrum.com. I hope all is going well with you.

Some of you may be familiar with the term, “What happens in Vegas stays in Vegas….”

Well, tonight I am introducing a new guest writer to the blog, a guy I have worked with for almost the past three years on some major enterprise rollouts of Scrum and co-train with him on a pretty regular basis. His name is Mark Pushinsky and this “enlightenment” came to him a few years ago and we have been waiting on how to actually introduce this to the Scrum Community.

So… without further ado… here is his write-up on the topic (and thanks to Tony as usual for the cartoon!).

I may add something to it later this week (smile).

=================

I was on my way back from Vegas sitting on a plane, with a massive hangover…….and this thought occurred to me.

I know they say that, �What happens in Vegas stays in Vegas� but this occurred to me on the plane ride home and I am pretty sure we cleared Nevada airspace before it did so I feel compelled to share it.

Do you know about the �Cone of Uncertainty�? It is a phenomena that people in software use to describe the fact that when you start a project you have no idea when you�ll finish.

The longer the project goes and the closer you get to finishing the better/more accurate your estimate. Basically you are pretty sure your going to finish it the day before its done.

We have been trying to make it go away in software for many years. Fancy new estimation techniques, months and months of analysis, and brute force have not materially changed the fact that software projects are unpredictable!

Period!

Managers having been trying for decades to make it disappear/pretend it doesn�t exist/figure out how to make it turn from a cone into a cylinder.

Yet time and time again the uncertainty in projects remains.

The epiphany that occurred to me is that Agile or Scrum flips it around. This means that if you ask me what I can deliver in the next 2-4 weeks I am pretty accurate, if you ask me what I am going to deliver 3 months from now I have some uncertainty, but I can give you a reasonable guess, and if you ask me what I can deliver 6 months from now I have no idea…….

When we teach Estimation and Planning in class, we make a point of saying that Agile does not make the �Cone� disappear.

Nothing will!

We use light weight, proven techniques to make our best guess at long term plans.

We don�t pretend to know the end…….in fact we are pretty sure it will change……and we commit to be back in 2-4 weeks to tell you how its changed.

Then we focus on short term commitments, doing the right things, executing well, and delivering real business value.

I have found that after a couple of iterations of working that way we get customers focused more on prioritization, the next release, and getting impediments removed.

They begin to worry less about when the whole thing will be done.

I think the best way to end a project is to stop working on it before all of �The Requirements� have been implemented.

The 80/20 rule, right?

=================

So there goes.

Mark is an awesome person, trainer, and mentor by the way…. While our opinions do not match 100% I love the opportunity to provide an outlet for different opinions and thoughts (even if we are competitors and collaborators in the marketplace).

Let me know if you are interested in contributing in the future!

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

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

Originally Published:
February 18, 2008

Posted in Cartoons,Guest Blogger,Pigs,Product Owner,ScrumMaster,Teams,Transparency — by mvizdos on 02/19/08 (3) comments

Chickens and Pigs. YouTube.com Debut.

Hi all.

Well, I finally had the idea to try and see if posting any information or videos on YouTube.com would help us spread the word more about Scrum.

So, tonight I had my almost-eight-year-old son (Dominic) and I record a very low-tech version of the cartoon using some audio files and the “original” Chicken an Pig cartoon. Right now, it is mainly a test.

My son and I are willing to post a version of the cartoons with commentary by myself and him on an ongoing basis.

Is this worth our time? My son loves doing this and I think this can add some very new perspectives on Scrum and all we do.

Thoughts?

I’d love to hear your feedback. Please spread the word.

Here is the link to the video:

Thank you!

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

Posted in Chickens,Pigs,Video — by mvizdos on 02/16/08 (6) comments

« Newer Articles — Older Articles »