Re-starting with Team Meetings & SCRUM
By Ales Cernosek on May 25, 2009
After having a short pause caused by a team reduction, we re-started our team meetings again. The major difference is that we have changed a meeting format from every week 2 hours long team meetings to a SCRUM methodology approach.
There are a lot of articles about SCRUM, so I'm not going to describe this methodology in detail again. Anyone interested in such methodology can find a lot of articles and books on Internet. I also put some of my learning resources at the end of this article.
What I'm going to write here is what I expect from this change and what is a practical impact to the team.
- Different planning - since majority of our work is connected to OpenSolaris and Solaris, we created a product backlog that contains features we would like to deliver within 6 months (typical time frame between 2 OpenSolaris releases). Since there are a lot of changes or urgent requirements, we setup 14 days between SPRINT meetings in order to quickly react to such requests. Recommended time frame for SPRINT is 2-6 weeks, so we will see in future whether the time is OK and it remains the same or we will choose longer period.
- Better responding on high priority tasks - since everybody is aware of tasks that are 'in place' or planned and everybody can do any team member work (theoretically!) the team can react on high priority tasks by splitting them among different team members. Therefore I do not expect the situation when one guy is overloaded with high priority tasks whereas other people work on P3-P4 tasks. Moreover since each task contains resource estimation, you know that by doing additional task you have to skip task(s) with the same resource estimation.
- You can see your status immediately - with knowing team resources available for SPRINT (subtracting holidays, trainings, ...) and each task resource requirements you can see clearly overall status and you can understand whether you are able to accomplish your plan in time. Simple chart showing those data can help you to understand 'where you are' at first sight.
- Team information exchange - previous 1-2hours long team meetings held on weekly basis were replaced by short (15-min) meetings that are held every day (at specific time). By meeting every day, you can have more fresh info. Moreover we work with other teams located in different locations and time zones remotely. So it can help them to be informed what our plans are and what we do by showing them SCRUM data.
- People can learn how to estimate work properly - typically, when planning (according to my experience), people usually underestimate the resources/time needed for task completion (and I'm not an exception here). So if you have to estimate every SPRINT, you can learn what was a proposed requirement and what is a reality, so your estimations will be more and more accurate in future, I believe.
There are also several points that may make SCRUM more difficult:
- The team does not deliver new features only, but also do QA tasks or other long-terms activities. A question is how to identify and estimate such long-term activities (sometimes ongoing).
- There are a lot of situations where new urgent requests or customer escalations appear. Those situations must be resolved ASAP, so other (planned) tasks must be postponed.
- Majority of team activities are not substitutable, meaning that there are several key areas that requires deep knowledge and substituting tasks is very difficult or almost impossible.
Whether those expectations mentioned above will be fulfilled or not I'll see in future with having longer practical experience. And if time allows,there may be some additional article about practical experiences after some time, including tools we have chosen.
And one more thing: Last time I mentioned team photos in my last article about this team. So here are some from a team meeting studying SCRUM framework :-).
Left side photo: from the left: Javier, Rado, Hroosa, HnHn (Honza) and Ales.
In the middle:
sprint backlog (stickers on the white-board) containing planned tasks
to be accomplished within 14 days. Each task can exist at one of 4
stages. The goal is to have all stickers/tasks at the bottom (sometimes
it's easy if you have bad stickers with bad glue :-) )