Archive for March 23rd, 2010

• Are Microteams Valuable?

  Date: 2010.03.23 | Category: Agile, Scrum, Team, Transitions | Response: 0

  I recently encountered what I call a Scrum microteam – just two Team members, a Product Owner and a ScrumMaster.  Out-of-the-book Scrum provides guidance that Teams should be 6±2 people, not including the ScrumMaster and Product Owner.  I have been intrigued by such a small Team (glad they are filling all the roles) and these are my thoughts why Scrum suggests 4 to 8 people after understanding the forces which created this Team.

  • Overhead – Scrum impose a fair amount of overhead on Teams – planning meetings, reviews, retrospectives and daily stand-ups.  I like all the pieces of Scrum and consider them essential.  Yet, I am not convinced it is worth the effort for just two people.  Could a good project manager be sufficient?
  • Work-In-Progress of one – This might seem like a benefit, but I believe it actually increases the risk the business will get nothing of value at the end of the Sprint.  When you have microteams, you can only effectively work one story at a time.  Any delay, change in scope or discovery of emergent tasks, puts the Sprint Goal at risk.  Further subdividing the story into smaller (technical) pieces just atomizes the work, not the risk.
  • Missing cross-functional skill set – with a team of 2 to 3 people, you typically have only one functional area represented, usually programmers.  Since Scrum is framework for cross-functional teams, why use the process if you are not meeting one of the preconditions?
  • Handoffs within the Sprint – suppose you are lucky enough in your microteam to avoid all programmers – your Team has a software developer and a graphic designer – now you have the problem that their skill sets do not overlap.  When skill sets do not overlap, that creates handoffs, handoffs are a form of waste and the whole point of cross-functional teams is to eliminate handoffs.
  • Narrow Definition of Done -  when the Team is so small, they must reach out to the rest of the organization in order to get anything really done.  This is a problem on any team, but when the Team is so small, the Definition of Done only includes things within the skill set of the individual members.  The amount of undone work is significant on a microteam. Entire Sprints can be dedicated to making sure this work is done and not delivering additional value to the organization.
  • Limited impact – if your microteam is a pilot effort of Scrum for a larger organization, then the impact of Scrum will be quite limited.  Small teams work on small problems that are not that important to the organization.  There will be strong inertia to adapt Scrum rather than fix the underlying obstacles and dysfunctions – why change your organization to make life better for just two people working on a pilot?