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!
July 30, 2007
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!
July 23, 2007
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!
July 16, 2007
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!
July 9, 2007
Older Articles »
