Welcome back to another week at www.implementingscrum.com.This week I am writing to you about something that usually gives me a shiver down my back.Meetings.
More to the point — useless meetings.
You know the type. Let’s have a meeting to have a meeting to discuss what we talked about at our last meeting and review what we have not completed but might get done before we have the next meeting in a few weeks.
Ug.
Breath.
This idea started with an email my wife got from a friend last week that basically said, “I am in a meeting and want to stick a pencil through my eye.”
I know the feeling.
This familiar to you?
Then… I am reading one of the copies of CIO Magazine (specific link here) from when I was gone last month and….
Let me recap what Scrum and “Meetings” have in common (this is correlating an the “five tips” talked about in the brief article I read by Diann Daniel):
1) Schedule only when necessary.
OK. In Scrum, you have a daily standup meeting. Fifteen minutes max. This is your daily planning.
You also have a Sprint Review meeting — where your outside stakeholders can come and see what is happening — working software is preferred.
You also have a Sprint Retrospective — where you and the team work on things that went well, went not-so-well, and what specific few items you can work on improving in your next iteration.
2) Reduce the frequency.
So it may seem that Scrum has a lot of “meetings” to some people.
Hmmm.
These “meetings” should ideally start turning into how people do work together on a daily basis.
3) Create an agenda.
This one is easy.
Daily — The three questions. What have you done since yesterday, what are you going to do today, and what are your impediments.
Keep it simple.
4) Recap.
If there are impediments (things in your way)… the ScrumMaster is responsible for making sure the impediments get removed. This does not mean the ScrumMaster must remove them; however, it usually takes a ScrumMaster role to make sure that things are getting out of your way. One of the ways this gets accomplished is by working with the team in showing them how to remove their own impediments. Cool when it works.
5) Do the minutes.
So in Scrum (and agile in general) one of the items in the Agile Manifesto is, “Working software over comprehensive documentation.” To me, this means that you should not ignore the fact that risks (possibly impediments) need to be tracked in an organization (see my blog entry on compliance!). Remember though… do not overkill it. Do what is needed and move on.
When people are transitioning from “old waterfall” development techniques to this agile stuff (Scrum in particular), sometimes they have a hard time remembering that the old ways they did meetings were ineffective and gave people a bad taste in their mouths (translation: UGGGGGGG WHY AM I HERE?!@@?).
As a ScrumMaster, part of your daily workings with the team will involve them in talking to one another.
Some people call that “meeting.”
Time to get over it and start working together.
Getting some ideas of how to help get this working in your organization?
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!
November 5, 2007
This week Tony and I complete the last of a three part series on Retrospectives. Part one is here and part two is there (smile).
First, let me ask you a question — what do you see when you look at this cartoon strip?
Really think about it.
There is no right or wrong answer. Your objective and subjective opinion matters.
Now, lets take a moment to step back and see what the team has come up with. OK, so the team right now is you, and use me as the facilitator.
Make a list of what you think these are. Go ahead. Nobody is watching you, its OK.
If you have done the exercise above, take a moment and step back (take some time) to reflect on the different pictures that have been developed from your list.
Take some time and think about them.
Close your eyes — do not fall asleep — and visualize this. Open them when you are done so you can continue reading this blog entry!
Hmmm.
The list may be pretty long.
Maybe take the top two or three things on the list you created.
Can you use them to make a difference on what you do daily with Scrum Teams?
What are you personally going to do with this information now?
Thank you for taking the time to do this, as I know your time is valuable.
Now.
Guess what we just did?
We used a framework from the book, “Agile Retrospectives, Making Good Teams Great,” by Esther Derby and Diana Larsen. Other great books on various agile topics can be found here.
The framework has five things — and go back up (now that you have the list) — to help you get the most from your retrospectives.
- Set the Stage
- Gather Data
- Generate Insights
- Decide What to Do
- Close the Retrospective.
Wow.
You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!
September 17, 2007
This week we are covering a topic near and dear to a lot of people in the Scrum Community.
Retrospectives. Part Deux.
Last week I covered the “old way” team have done them.
This week.
How some teams do it today.
So called, “By the Book.”
Ooops.
But Mike, “It LOOKS so easy!”
Three Questions:
1) What went right?
2) What went wrong?
3) What can we improve the next iteration?
If a team begins to mature and grow, this type of format will become mind-numbing and create no real value to the team.
Think about it.
And. I mean this in the nicest way.
A lot of team members are technical.
And a lot of them can be introverted.
This means they may not like answering the same darn question after every Sprint.
Ug.
Even extroverts will get bored by this.
Really.
And then things start going South.
Your teams become less effective.
And.
Team members that are in this situation may recognize there is a problem.
In real life, they may not say anything. Usually — and this is unfortunate — they do not say anything.
Productivity suffers.
People start questioning what they are doing.
And the ScrumMaster may not have a clue.
Yikes.
What next?
The next part of this series will discuss what you as a ScrumMaster can do. And even as a team member on a Scrum Team.
If you are on a team today and see this is a problem, please get the word out that NEXT WEEK I will reveal some great solutions that may help you and your team become more effective.
Or at least take a shot at it.
Stick with it!
You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!
September 10, 2007
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
« Newer Articles
