Archive for the ‘SCRUM’ Category

ScrumButs

Friday, September 4th, 2009

scrumbut [skruhmbut] noun.
1. A person engaged in only partial Agile project management or development methodologies
2. One who engages in either semi-agile or quasi-waterfall development methodologies.
3. One who adopts only SOME tenants of the SCRUM methodology.
4. In general, one who uses the word “but” when answering the question “Do you do SCRUM?”

ScrumButs are the best part of SCRUM makes a great argument that “optimal behavior of a team cannot be predicted” and so retrospectives may be used to tweak SCRUM to optimize it for a particular team. At last a refreshing break from the SCRUM zealots who believe that any deviation from SCRUM is bad and that if you are not doing pure SCRUM then you are not doing SCRUM.

It is worth highlighting that there is a great emphasis on using retrospectives to drive positive optimizations. Pure SCRUM should be adhered to for an iteration or two and then use retrospectives to adjust as necessary for a particular team. The need for an adjustment highlights an aspect of the team behavior that may be different from that envisaged by SCRUM. The team should decide if that behavior is good and should be kept (via a ScrumBut) or if the behavior is bad and if the team should think about a change. Either way the focus is on optimizing the team behavior and this is usually good.

Splitting large Scrum teams

Sunday, August 19th, 2007

Once upon a time we decided to use SCRUM as part of our development process. Since its introduction in our team, we have had a number of successful projects and we all think its the best thing since sliced bread. We love the fact that the entire team meet for a few minutes each day and think that it provides an effective means of communication between the team members.

Over time our team size has increased from about 4-5 to a whopping 15. We still practice SCRUM but I don’t get as much out of it as I did when we had a smaller team size. Apart from the fact that it’s difficult to get a space for our stand up meetings that can accomodate the entire team and still be able to hear everybody, I find it hard to keep tuned in to what everybody is saying. There is some pressure to stick to a single SCRUM for the entire team and not split into sub-teams. The rationale is to keep the daily stand up meeting as a communication channel between the entire team. So there are two problems:

  1. How to improve the communication within the single large team to make it more effective
  2. How to keep good communication across sub-teams and multiple SCRUM groups

Here is what I found from researching the problem:

How to improve the communication within a large SCRUM team?

  1. Hyperproductivity In Large Projects Though Distributed Scrum – relates to SCRUMs between distributed team members but the team size was 59!!!!
  2. Hmmm, there seems to be a lack of advice here! The only advice that I could find was to split the team into smaller sub-teams – the “scrum of scrums“!

How to keep good communication across sub-teams and multiple SCRUM groups?

  1. Historical data that suggests keeping the SCRUM team size under under 7
  2. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information
  3. Inefficiencies and large teams – “Two common pitfalls for crowded teams: miscommunication and lack of motivation”
  4. How to organize work and structure a project with multiple teams: Let small teams focus on solutions to specific problems and coordinate activity between teams.
  5. Scrum of Scrums

I guess the tactical approach to convincing the team to move towards smaller sub-teams and multiple SCRUMs is to point out that the larger team size is reducing the effectiveness of communication within the team. However, this must quickly be followed up with evidence that co-ordination and interaction between the smaller teams can address the communication gap caused by the split. To this end, I think I like the idea of the scrum of scrums approach where there are multiple scrum teams, and one member of each team attends a SCRUM with one member from each of the other teams. In effect this one team member becomes the communication channel between the teams.