The Theory
A stand-up is a 15 minute meeting, based on three questions:
1. What did you do?
2. What are you working on?
3. What's preventing you from getting it done?
You have someone who keeps the meeting focused (the scrum master) and you don't let non-team members involved. This is the concept of chickens and pigs. Who are the pigs? Anyone who is directly working on the project - they have some skin in the game.
Tasks involved are chosen from the backlog. A key part of this process is that there is no dictation of tasks. Everyone magically chooses what they want to work on. Everyone sits (or stands), looking at some kind of white board (where electronic or physical) and they all jump up choosing what they want to work on.
So now you can easily say "What did you do?" Tell us what you did the day before. Tell us what you're currently working on. Any problems? If there were any, you then discussed them outside of the meeting.
The Reality
Our scrum/stand-up meetings tend to be an hour, so there wasn't a whole lot of standing possible. Earlier on, I tried offering incentives for keeping them under 15 minutes and cheered every time we made it short.
In truth, many on the team struggled between "what did you do" and "what are you working on?" People who had been there while the organization had tried other methodologies before, smiled at the "quaint" new process. Been there, done that. Slowly, many of them came on board but then it became a question of how much work you could expect to get done in a day.
How much time is really available in a 7.5 hour work-day?
Allowing 60 minutes for lunch and other breaks and then an hour for email or other administrative items, now you're down to about 5.5 hours. Smaller organizations may balk at an hour for other tasks but in larger organizations, the water cooler and impromptu meetings take up a large chunk of unplanned time. Often, you don't get to pick your own team. They also aren't full-time resources - they have other meetings, paid leave and their own issues. All businesses have the same scenarios - but in larger organizations, those realities are codified, set in stone by employee contracts, rather than being flexible in smaller businesses.
The wonderful theory of scrum where everyone's focus is head-down, let's get this done, is exactly that - a theory that may exist where bread and butter is a daily consideration, but in a larger organization, sadly, that isn't always the case. So the hour or half-hour time became the norm.
An hour allows us also to walk through some features and include some design discussion. So the "stand-up" became the "what is everyone working on and doing" and then focusing on issues, code reviews or, perhaps more importantly, areas that need clarification.. In an environment where getting people's attention was competing with regular office work, this helped ensure that all of the good parts worked well.
What it also made very clear was when you had resources that were struggling and how best to deal with them. People learn or approach things in different ways: some are visual, some are conceptual, others like to have time to choose actions on their own. If the results weren't happening, tasks were broken down into even smaller chunks, allowing them to find their own groove.
The small team approach was also a great help. Whenever the project manager decided to have larger meetings, they quickly degenerated into people who wouldn't say a word and others who would talk and talk but say nothing. In other words, politics raised its ugly head. When they had a larger budget, they would create separate teams for business analysts, for testers and for developers. This misses the point of personal responsibility. Whether each group had their own scrums or let everyone go off on their own was unknown. In a scrum environment, results are really all that matters.
What was the ideal size of team? In my experience, it ended up being teams of 4-5 (especially for hitting a 15-30 even 60 minute scrum). When the team was larger, the head of each group would then meet with their counterparts and so on. The only way this worked was when the team leads were equally as strong.
Analyst Team DB Team Dev Team BA Team. Test Team. Documentation
Each of these teams had 5 people in them. Again, this only worked when each team would work the same way. When one group stopped handling their teams the same way and fell back to the old habits of waterfall, the only way to ensure the overall project worked properly was to make sure the Head-Team stand-up enforced this. Whenever the Head Team stand-up failed to work, then the individual teams suffered in terms of the overall project - BUT it became a lot harder on them.
A great resource was the Microsoft Press book Project Management with Scrum. It has a lot of great real-world examples and while it usually came back to strictly following the theory, it also showed that creativity in its implementation does have its place.
Again this is what we found in the project process. I'd love to hear your experiences on this.
A stand-up is a 15 minute meeting, based on three questions:
1. What did you do?
2. What are you working on?
3. What's preventing you from getting it done?
You have someone who keeps the meeting focused (the scrum master) and you don't let non-team members involved. This is the concept of chickens and pigs. Who are the pigs? Anyone who is directly working on the project - they have some skin in the game.
Tasks involved are chosen from the backlog. A key part of this process is that there is no dictation of tasks. Everyone magically chooses what they want to work on. Everyone sits (or stands), looking at some kind of white board (where electronic or physical) and they all jump up choosing what they want to work on.
So now you can easily say "What did you do?" Tell us what you did the day before. Tell us what you're currently working on. Any problems? If there were any, you then discussed them outside of the meeting.
The Reality
Our scrum/stand-up meetings tend to be an hour, so there wasn't a whole lot of standing possible. Earlier on, I tried offering incentives for keeping them under 15 minutes and cheered every time we made it short.
In truth, many on the team struggled between "what did you do" and "what are you working on?" People who had been there while the organization had tried other methodologies before, smiled at the "quaint" new process. Been there, done that. Slowly, many of them came on board but then it became a question of how much work you could expect to get done in a day.
How much time is really available in a 7.5 hour work-day?
Allowing 60 minutes for lunch and other breaks and then an hour for email or other administrative items, now you're down to about 5.5 hours. Smaller organizations may balk at an hour for other tasks but in larger organizations, the water cooler and impromptu meetings take up a large chunk of unplanned time. Often, you don't get to pick your own team. They also aren't full-time resources - they have other meetings, paid leave and their own issues. All businesses have the same scenarios - but in larger organizations, those realities are codified, set in stone by employee contracts, rather than being flexible in smaller businesses.
The wonderful theory of scrum where everyone's focus is head-down, let's get this done, is exactly that - a theory that may exist where bread and butter is a daily consideration, but in a larger organization, sadly, that isn't always the case. So the hour or half-hour time became the norm.
An hour allows us also to walk through some features and include some design discussion. So the "stand-up" became the "what is everyone working on and doing" and then focusing on issues, code reviews or, perhaps more importantly, areas that need clarification.. In an environment where getting people's attention was competing with regular office work, this helped ensure that all of the good parts worked well.
What it also made very clear was when you had resources that were struggling and how best to deal with them. People learn or approach things in different ways: some are visual, some are conceptual, others like to have time to choose actions on their own. If the results weren't happening, tasks were broken down into even smaller chunks, allowing them to find their own groove.
The small team approach was also a great help. Whenever the project manager decided to have larger meetings, they quickly degenerated into people who wouldn't say a word and others who would talk and talk but say nothing. In other words, politics raised its ugly head. When they had a larger budget, they would create separate teams for business analysts, for testers and for developers. This misses the point of personal responsibility. Whether each group had their own scrums or let everyone go off on their own was unknown. In a scrum environment, results are really all that matters.
What was the ideal size of team? In my experience, it ended up being teams of 4-5 (especially for hitting a 15-30 even 60 minute scrum). When the team was larger, the head of each group would then meet with their counterparts and so on. The only way this worked was when the team leads were equally as strong.
Project Team of 30 (including B/As, testing , DBAs, etc)
Head Team Stand-ups (5)
Team Lead for Analyst/DB/Dev/BA/Test/Documentation
Analyst Team DB Team Dev Team BA Team. Test Team. Documentation
Each of these teams had 5 people in them. Again, this only worked when each team would work the same way. When one group stopped handling their teams the same way and fell back to the old habits of waterfall, the only way to ensure the overall project worked properly was to make sure the Head-Team stand-up enforced this. Whenever the Head Team stand-up failed to work, then the individual teams suffered in terms of the overall project - BUT it became a lot harder on them.
A great resource was the Microsoft Press book Project Management with Scrum. It has a lot of great real-world examples and while it usually came back to strictly following the theory, it also showed that creativity in its implementation does have its place.
Again this is what we found in the project process. I'd love to hear your experiences on this.
Comments