Much has been written and talked about regarding the Iron Triangle in the software development community. For those of you unfamiliar with the concept, there are three “constraints” to any software development project — Scope, Schedule, and Resources. Oh, and consider Quality as a non-move able object (which can be discussed in some other context later).

Resources include money and budgetary stuff. While I usually say that people are NOT resources, in the end this is where people “fit” in this example.

Schedule is the time you have to deliver on a project.

Scope includes the features and functionality of the deliverables you will be providing to the end user.

Scott Ambler has written about how this triangle is really “broken” today, and you can read more about it here. There is some good information there and much can be learned from it.

Today I will focus on what is considered the only movable line within Scrum, and that is Scope. Why?

From a Resource perspective, each Sprint normally has a fixed amount of people and equipment. You can easily predict the burn rate for a Sprint.

From a Time perspective, each Sprint is normally a fixed length of time (anywhere from a week to a month, depending on the team norms).

So, that leaves Scope as the one item open for discussion during a Sprint. Let me explain further…

The Product Backlog contains all of the features and functions that the Product Owner has identified (with the team) as the highest priority items to deliver for the overall project. Following each Sprint Review and Retrospective, the team gets together during the Sprint Planning Meeting to discuss the latest Product Backlog and decides what items should be pulled into the next Sprint.

Once the team — along with the Product Owner — decides what to pull into a Sprint Backlog, the Product Backlog then becomes part of the background noise in a project. Once a Sprint gets started, the team focuses on the Sprint Backlog while the Product Owner — and other outside stake holders (Chickens) — can play with the Product Backlog to their hearts content. Outside the team room. Responsibly (remember that… do not do things blindly or irresponsibly!).

So, the team gets started with their Sprint and is chugging along.

The Scope is fixed. The Resources are fixed. The Time is fixed — and ticking away. All is well until about mid-way into the Sprint when….

“Uh-Oh Mike… I see from the Burn Down Chart that we are not gonna make it!”

What should the team do?

Panic?

Uh. No.

This is actually something that is normal (and, by the way, CAN happen in reverse (as in… “Mike, we have some bandwidth…”).

And either way… this is actually a healthy thing if you work it the right way.

The WRONG way is for Chickens to come parachuting in (because that is what they love doing) and offering to “help” by adding what….

RESOURCES or trying to EXTEND the Sprint TIME.

Remember… on Resources… nobody can make a baby in a month by adding eight more women. Really. And time… well… that is fixed; as much as we want more hours in the day.We will end the Sprint when we will end the Sprint. And be done.

So… that leaves the Scope. Here is what should occur….

The team should sit down and have a facilitated discussion with the Product Owner about what is happening (this should not be a surprise for an active Product Owner) and why the Scope needs to be adjusted.
If the Product Owner is truly empowered by the outside stakeholders to make a decision, the Product Owner can then take user stories and tasks OUT OF SCOPE for the Sprint and add it back to the Product Backlog to be re-prioritized for a future Sprint.

Is this hard?

Sometimes.

OK. Most of the time.

Is this reality?

Yes. And that is why Scrum is set up to deliver working software at regular time intervals using fixed Resources and Time throughout a Sprint.

Should you follow this advice blindly?

No.

Be responsible. Think. 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!

This week we take a serious look at how being part of an Agile team can sometimes be a bad thing.

In the normal course of working for a living, people get sick.  And usually, they come in and tough it out (this may be an Americanism… sorry… it means even if you feel like a wet sock twirled around a razor blade sliding into a pile of cigarette ashes, you come to work anyway [hope that makes things clear!]).

The Chicken above could easily be a Pig too.  One of the reasons we selected a Chicken was to make another point — besides being sick as a Pig (or sick as a Dog), this Chicken starts to think that said Chicken can do things better than all the Pigs combined.  I — unfortunately — have seen this happen.

So, if you are a Pig on an Agile team, I will not say stay home.  Sorry.  This is not a free pass.

What I will advise is that, as cold and flu season starts to rear its ugly head soon, the team have a discussion (maybe during a Retrospective — you are having those, right?) about your Team Norms and how the team wants to deal with it.  Talk about it, and agree on it, BEFORE it actually occurs.

It will.

Every team is different. Remember this.

This “sick thing” is something that teams forget, or worse yet, do not even bring up.  Is it important?

Think about it this way.

You are in a room together with 7-9 people (or 15-25 for those “large” teams out there HEAVY SIGH) for most of the day five days a week.  People come in contact with other people outside of work.  Kids bring home sicknesses to parents and pass them off to parents.  Parents, some Pigs on your team, bring the sickness into the room with you.  I am not picking on parents (I am one!), but know this is an easy thing for people to see.

Now… remember that old [waterfall] thought of… “What if our key person gets hit by a pie truck?”

Pie truck for this example = “Sick”.

This happened to me back during the OJ Trials.  Well, I was not hit by a pie truck, but had pneumonia that was bad enough for the doc to tell me to stay home for two weeks or go to the hospital.  I toughed it out until it was bad enough to actually go to the doctor (it probably would not have been so bad if I actually did something about it earlier).  But I was on a waterfall team that got screwed because I was out for just over two weeks.  And — worse than the drugs I had to take, or that fact that the OJ Trial was the only freaking thing on TV 24*7 — I got total pressure about it from all sides at work.  Remember… I was a “key person” on the team and this royally screwed up the Gantt Charts.   Sigh.  This was also during a project when one of the guys working with us (may he rest in peace) left work with his feet first on a gurney one day.  Imagine the effect on the Gantt chart then?!!?

Apply it to an Agile Team member…. “What if our key Pig gets hit by a pie truck?”

Here is one of the key differentiators to tell if you are on a truly Agile Team.  Do you recognize the benefits of becoming Generalizing Specialists and have you worked to do this within your Agile team?

I know.  I know.

“But Mike… [insert any excuse here]…”

Bla bla bla.

Yes.  People are important.  This is one reason (among many) that people on the team should become generalizing specialists. Again… something to talk about in your next Retrospective.

Really.

I know.  It is hard.  Suck it up and do it (smile).  Not become sick.  Become more Agile.  Learn about what other people on your team “do” for a living.  It may even make you more marketable.

Otherwise…

Play out this scenario…

You come to the Agile Team room (even if the room has the Clorox Wipes) sick one day.  In about seven to ten days, half your team gets it.  In another seven to ten days, the rest of the team gets it.  At the end of two week, if everyone kept coming in sick to the room, you’d have nobody left.   Velocity for the Sprint is shot.

Is this an extreme example?

Of course.

I am tryinnnnnnng to make a point.

Get it?

So, what do you think the Chicken in the cartoon above is thinking about where this will go?

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!

We had a late start to the site in 2006 (actually, our first cartoon was published on September 11th) and have seen consistent weekly growth since the initial kickoff.  Tony and I appreciate your interest, questions, and feedback we regularly receive from this very active community.  It there is anything else we can do to make your time in our little world more enjoyable, please let us know!

This week I examine — at a pretty high level — what it actually means to “be” a CSM (Certified Scrum Master).  And then what you can do once you have that initial certification in your hands.  This is my view of what you can do, as backed up by information that is available publicly today.  Any errors are my fault and should not be construed as “the way” to do this, as results will vary and I am not liable for any future results (translation: follow at your own risk!).

To become a CSM, you need to do one thing.

Pay your fee (either via your company or by yourself), attend a two day CSM Course, and successfully complete the two days.  There are about fifty-two people “certified” to train you throughout the world (yes, I am one of them, and I will talk more about how to become one later in this article.

Wow.  You are thinking.  “Mike, are you kidding me?  All it takes to become a CSM is to attend a two day course?”

The easy answer is yes.  And, there are about 9,649 people internationally who have the certification today.  You can read more about how *I* present my course — or workshop — here.  All CSTs (Certified Scrum Trainers) work off the same principles for their courses or workshops; details of the latest information can be found here.

So.  Does being a CSM actually qualify you to lead and coach and start facilitating a new team?

My classic consultant answer: It depends.

The CSM “stamp” tells the world that you have been through a training class from a Certified Scrum Trainer.  You are now a member of the Scrum Alliance (woot!).  This shows the world you understand the basic principles and practices, and each course / workshop is designed to make sure we each consistently give you about fifteen bullet points.

So why does it depend?

Each person is an individual.  You are not resources (smile).  People are different. Some people actually “get it” from day one of being stamped a CSM.  Others — many others in fact — do not.

What do I mean, “Get it?”

Scrum is more than just a list of rules you must follow.  In fact, people who “get it” realize that Scrum is not a cookbook.  Only a small percentage “get it” from day one.  Heck, I am a CST and some days I question if I really “get it” — as I learn something new every day.

And this is what the CSM stamp gives you — a heads up that your journey is just beginning.  And hopefully you walk out of that two day course / workshop with your eyes open.

Will everyone go back to their “real jobs” and implement the stuff they learn?

No.

And, right or wrong, this is something we all need to understand.  And move on.  This Scrum Stuff is not for everyone.  Really. Recognize and accept that. We are not pushing a cultish religion (OK, I can say that I am not doing that).

So, what is available “after” becoming a CSM.

Approximately one year after becoming a CSM, you can apply to become a CSM Practitioner.  This means paying yet another fee to the Scrum Alliance (as of the beginning of 2007, it is a non-profit organization…. something I will write about in the future as the community learns more about the transfer of assets from the “For Profit” to a “Non Profit” Entity in the USA) and filling out a form to show your proficiency in Scrum.  Today, there are 109 of those people internationally.

That is just over 1% of the total CSM Community.

Do all the people who are CSM-Practitioners “get it?”

Nope.

However, as you can see just by the pure numbers, that small percentage of the overall trained CSMs actually take the time and make the effort to become publicly recognized as a CSM Practitioner.

What is “next?”

The next step is to be a Pracititioner for a set period (a year?) and then apply to become a Certified Scrum Trainer.  Prior to November of 2006, this meant co-teaching with Ken Schwaber (one of the founders of Scrum) and him giving you the stamp as a trainer (in addition to paying an additional license fee).  Then, each time we teach a course, we pay a license fee for the course information to the Scrum Alliance.

Post November, 2006, the process to become a Certified Scrum Trainer has been updated.  In November, five new Certified Scrum Trainers went through the “new” process to become certified to train.  This “new process” involves a lot of work from both the person wishing to become certified and the committee / panel of Certified Scrum Trainers who now make up a team of people to certify new trainers.  One thing to note — all Certified Scrum Trainers are also Certified Scrum Pracititoners; we actually need to practice what we preach (smile).

And there are 52 of us worldwide. For those keeping the statistics, that means less than a half of one percent of the overall Scrum Community is at that level today.

Overall, this “new process” seems to be a great thing.  Again, this is “new” to the Scrum Community, and something that has been put in place based on a lot of feedback by the overall membership of the Scrum Alliance.  More information can be found there. A lot of the outputs from things like Open Space Gatherings and Trainer Gatherings are meant to help guide the overall Scrum effort moving forward.

So, this submission has reviewed the current path of becoming a CSM, a CSM Practitioner, and a Certified Scrum Trainer.  Did I get it 100% “right” — probably not.  For the most up-to-date information see the Scrum Alliance site.  Get involved.  As you can see, there is plenty of room for talented people to continuing shaping our future.

What I have tried to give you is some information about what you can do as a CSM, using the most current information I have available to me today.

Will it change?

It will change.

Will it adapt?

It will adapt.

One of the main principles of any agile practice — including Scrum — is to inspect and adapt (frequently).  As a community, we are doing that.

It is hard.  Like any change management within an organization (especially one that is approaching 10,000 today!).

Finally… if you are looking for a CSM, CSM Practitioner, or Certified Scrum Trainer to work with in your current environment… what do you do?

First, read this article over again.  Understand what you are “getting” when you work with someone with a specific certification.

Next, ask questions of whoever you will work with about specific problems you are encountering today… and see how they have handled similar problems in the past.  Talk to people.  And listen.  Watch out for people who have all the answers.  Big red warning lights should be going off if someone claims they have the “Silver Bullet” that will fix all of your “problems.”

Finally, ask around.  Call me.  I can be reached anytime at (619) 709-1716; I will call you back if I cannot answer your call at that moment.  Call other CSMs.  Call other CSM Practitioners. Call other Scrum Trainers.  The key thing is to talk to people.  And listen.

Seeing a theme here?

There are a lot of CSMs out in the wild today.  There will be a lot more tomorrow, and the next day, and so on….

Hopefully now you have an understanding — in everyday terminology — what the CSM process looks like today.

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!