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

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

Is this you?

And.

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

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

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

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

How to GIVE feedback

Start with an opening

Stan, can I talk to you for a minute…

Provide data NOT opinion

…in the meeting this morning when you said…

Talk about the impact on YOU, avoid speaking for others

…it made me feel uncomfortable and distracted me…

Make a request for change.

Please bla bla bla.

That’s it. Pretty easy, huh?

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

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

And that is normal.

And.

It is OK.

Really.

So what about receiving feedback?

How to RECEIVE feedback

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

Gotta run….

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

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

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

Eeek. This may hurt a bit.

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

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

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

Yikes.

Am I selling snake oil?

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

For me.

Gulp.

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

And, it works for them.

Sometimes.

It is hard?

No. Maybe.

Yes.

And (smile).

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

Scrum is not a Silver Bullet.

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

Scrum is not rocket science.

And.

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

Snake oil?

I make no claims that this stuff is easy.

And (geesh… I really want to say “but” here LOL).

It works.

For me.

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

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

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

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

And finally….

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

Have a great week.

Gotta run….

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

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

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

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

But.

It does.

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

Going religious-zealot on anyone will not help.

Trust me on this one (smile).

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

But.

It is reality.

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

So?

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

And this is OK.

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

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

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

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

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

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

Draw a line across the paper.

On the left side write, “Hacking.”

On the right side write, “Solid Engineering Practices.”

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

This can be a great facilitated discussion oh ScrumMaster.

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

One per yellow sticky.

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

What do you see?

It may amaze you.

Now.

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

Yes.

Scrum does not talk about engineering practices.

But guess what?

Your Scrum Team needs to develop working software.

And solid engineering practices are needed.

In the real world.

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

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

What they do with it is up to the team.

Remember that!

Gotta run….

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

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

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

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

Sit down.

And listen. This is important.

Really (smile).

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

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

Wow.

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

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

Gulp.

So what the heck do you do?

Try using Scrum.

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

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

However.

And this is a big one.

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

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

Do you understand the implications of the above statement?

Really?

Gotta run….

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

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

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

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

One question.

Only.

One.

Phew.

The pressure was on.

What question would he ask?

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

So.

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

“What if a team REJECTS Scrum?”

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

And.

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

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

And it is not.

Even to “me” as a ScrumMaster.

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

Am I the only ScrumMaster experiencing this trend?

Could it just be *me*, I wondered?

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

And I found out something amazing.

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

25%.

“Wow,” I thought.

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

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

And then I realized.

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

Stop and think about this.

I did.

And it made me feel very humbled.

Silence.

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

Really.

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

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

Think about that statement.

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

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

And then, what it means to your organization.

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

OK… so “Scrum” will not “fail.”

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

So.

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

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

The truth hurts.

Brutally.

Yikes.

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

And move on?

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

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

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

Think about it.

Seriously.

Because.

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

More next week.

Gotta run….

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

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