Sunday, August 27, 2006
SCRUM at Unkasoft: the daily meeting
Last day we’ve been talking about how you can organize SCRUM sprints, but we skipped daily meeting subject.
But before we can start, we should introduce the Scrum Master role.
SCRUM suggests three roles: product owner, development team and Scrum Master.
The Scrum Master is that person who has the whole vision and the best way to apply SCRUM methodology inside your team. He/she isn’t the typical project manager or team leader, or the all-mighty-commander-boss. Scrum Master could be a person working at partial time, combining these tasks with another ones (perhaps he/she is the product owner or another programmer too), although at large projects, perhaps he/she is working at full time.
It’s important to say that Scrum Master has to be a person with enough power inside the company to make hard decisions.
Well, now we’re all introduced, so let’s continue…
The daily meeting (as well, called “daily scrum” referring to the typical rugby game movement) is the heart beating of the SCRUM project. The meeting is the place where the team is gathered, a sharing time where people talk about their progresses, doubts, ask for help and so on.
Thanks to this daily meeting, we’re averting typical end of project delays, because you’re watching the progress (or lack of) day by day.
Several dev teams I know, the project manager goes for each desk asking about the progress, or perhaps the programmer warns their manager when he/she is done.
Let’s remember SCRUM proposes auto-management, so here, the manager (Scrum Master) doesn’t review others’ work, but other team mates do.
It is important that the whole team can see whole project progress, instead of watch only him/her part. This will raise an identity feeling which could be considered the “SCRUM’s gasoline”. Without this feeling, the SCRUM project will stop as a car without gas.
And here I should remember you again: don’t try to use SCRUM at anywhere or with anybody. Choose carefully your team and your work environment.
Daily meeting shouldn’t last more than 10-15 minutes, in order to avoid typical endless meetings without a clear goal and subject. Here at Unkasoft, our daily meeting is very informal and last about 2 minutes because of our project has only two programmers (one of them is the Scrum Master too).
So don’t concoct more excuses in which you don’t have enough time to meet with your team.
SCRUM defines a “modus-operandi” more or less established. During the meeting, each team member should answer following questions:
What did you do yesterday?
With this question we’re testing two things:
What are you going to do today?
Here, each team member assigns remaining tasks of sprint backlog. Neither team nor Scrum Master should force anybody to do one task. Why? Because nobody will know better than developer which tasks he/she will make the best and the fastest. Everybody will choose tasks according his/her knowledge and experience, so step by step, tasks will be assigned in optimum way without external intervention (pure chaos theory :)
As sprint progresses, hard tasks will be left. Then, Scrum Master could suggest, but never force.
What do you need to progress?
Sometimes, people in charge of other people forget his/her main duty: manage the environment in order to people can work faster and better. However, most bosses don’t apply this management, but he/she just command without remembering why he/she should command.
With this question, programmers raise a warning about blocking sides. The Scrum Master has to do all he/she can to solve theses problems.
Some typical problems could be:
When your project was in a tight spot, these problems could be a ton. In that moment, Scrum Master should note down all problem and make a “impediment backlog”. From here on, main team priority is remove this impediment backlog. Each item will be assigned to team member or even out of team members (network admin, for example). Next day, this impediments backlog will be reviewed to remove solved problems and release blocked tasks.
But before we can start, we should introduce the Scrum Master role.SCRUM suggests three roles: product owner, development team and Scrum Master.
The Scrum Master is that person who has the whole vision and the best way to apply SCRUM methodology inside your team. He/she isn’t the typical project manager or team leader, or the all-mighty-commander-boss. Scrum Master could be a person working at partial time, combining these tasks with another ones (perhaps he/she is the product owner or another programmer too), although at large projects, perhaps he/she is working at full time.
It’s important to say that Scrum Master has to be a person with enough power inside the company to make hard decisions.
Well, now we’re all introduced, so let’s continue…The daily meeting (as well, called “daily scrum” referring to the typical rugby game movement) is the heart beating of the SCRUM project. The meeting is the place where the team is gathered, a sharing time where people talk about their progresses, doubts, ask for help and so on.
Thanks to this daily meeting, we’re averting typical end of project delays, because you’re watching the progress (or lack of) day by day.
Several dev teams I know, the project manager goes for each desk asking about the progress, or perhaps the programmer warns their manager when he/she is done.
Let’s remember SCRUM proposes auto-management, so here, the manager (Scrum Master) doesn’t review others’ work, but other team mates do.
It is important that the whole team can see whole project progress, instead of watch only him/her part. This will raise an identity feeling which could be considered the “SCRUM’s gasoline”. Without this feeling, the SCRUM project will stop as a car without gas.And here I should remember you again: don’t try to use SCRUM at anywhere or with anybody. Choose carefully your team and your work environment.
Daily meeting shouldn’t last more than 10-15 minutes, in order to avoid typical endless meetings without a clear goal and subject. Here at Unkasoft, our daily meeting is very informal and last about 2 minutes because of our project has only two programmers (one of them is the Scrum Master too).
So don’t concoct more excuses in which you don’t have enough time to meet with your team.
SCRUM defines a “modus-operandi” more or less established. During the meeting, each team member should answer following questions:
- What did you do yesterday?
- What are you going to do today?
- What do you need to progress?
What did you do yesterday?
With this question we’re testing two things:
- Everybody is working on self-assigned tasks. As we already said, SCRUM works with auto-management, where each developer chooses which tasks he/she want to make.
- Whole team can watch project progresses. A good way of improve team’s morale is assuring each member can “taste” whole progress and see others members progressing. This can help people behind can faster his/her tasks.
What are you going to do today?
Here, each team member assigns remaining tasks of sprint backlog. Neither team nor Scrum Master should force anybody to do one task. Why? Because nobody will know better than developer which tasks he/she will make the best and the fastest. Everybody will choose tasks according his/her knowledge and experience, so step by step, tasks will be assigned in optimum way without external intervention (pure chaos theory :)As sprint progresses, hard tasks will be left. Then, Scrum Master could suggest, but never force.
What do you need to progress?
Sometimes, people in charge of other people forget his/her main duty: manage the environment in order to people can work faster and better. However, most bosses don’t apply this management, but he/she just command without remembering why he/she should command.
With this question, programmers raise a warning about blocking sides. The Scrum Master has to do all he/she can to solve theses problems.
Some typical problems could be:
- Programming: “I don’t know how I can use hardware acceleration in Java”. Ask for help to others team mates.
- Dependencies: “in order to implement this feature, I need rendering engine was stable”. Add new items to sprint backlog to assign these tasks.
- Management: “I haven’t network access” or “I delaying due every time I compile, I spend 30 minutes”. Scrum Master must solve theses problems.
When your project was in a tight spot, these problems could be a ton. In that moment, Scrum Master should note down all problem and make a “impediment backlog”. From here on, main team priority is remove this impediment backlog. Each item will be assigned to team member or even out of team members (network admin, for example). Next day, this impediments backlog will be reviewed to remove solved problems and release blocked tasks.
posted by JM : 11:55 pm
