Interested in becoming a Certified ScrumMaster? Come to my next workshop!
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!
You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!
September 4, 2007
April 6, 2008
4 Comments! to “Scary Team Retrospectives. Part One.”
Leave a Reply
Comment moderation in full effect!
All comments at Implementing Scrum are moderated to help cut back on spam.
This only happens once (more if you are using multiple computers). Once you are in the system, everything is good to go after that.
September 5th, 2007 at 12:49 pm
One of the things that we have found helpful with our retrospectives is to not only reflect on the individual team retrospectives (which each team does separately), but also pulling all of the project managers together for a larger retrospective across all of the products. Some times we are able to find common areas that can be worked out/through that are affecting many teams. Other times, it is to give advice on how to overcome obstacles that are hindering a team. In this manner, we seek to build from the bottom up and top down the individual, team, and organization.
Thus far, it has been highly effective, and takes the burden off of a manager to have all the answers. And isn’t that what Scrum is all about? Working as a team towards a common goal
September 21st, 2007 at 12:22 am
[...] Michael Vizdos portrays an excellent three-part series of posts on retrospectives in his unique style. Check them out - Part I: The Scary Team Retrospective, Part II: Beyond the Book Retrospectives, and Part III: Walk into the Light. [...]
December 4th, 2007 at 10:41 pm
[...] This is something you can try with your Scrum Teams — either in a retrospective or some other point in time. [...]
April 6th, 2008 at 9:20 pm
[...] 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/. [...]