Short duration teams

Tuesday, May 27, 2008 9:31:39 AM (Mountain Daylight Time, UTC-06:00)

One of the key benefits of agile and Scrum is the growth and maturing of the teams that work together.  The longer a team works together, the more it learns about itself and its members.  The team learns what works well for them and what doesn't and they use this information to adapt their practices.  This learning is central to the continuous improvement of practices that drive the engine of great agile teams. 

However, a problem exists in many organizations (especially consulting organizations) that may denigrate the effectiveness of this core agile practice.  I'm talking about short duration development teams.  If you've worked in the consulting world, you've been there before.  Teams are assembled in a mix-n-match fashion  to tackle specific contract jobs.  Many of these jobs are short term, just a few months in duration.  Then, the team is disassembled, put back into the "resource pool" and reassigned to other jobs with new teams.  Sometimes teams get to hang together on the next job, but many times, they are separated and placed on new teams with new team members.  The problem I see with this is that these teams don't work together long enough to really learn about what's working and what's not.  They don't gain the benefit of working agile and finding ways to improve their practices.  I think that in addition to not gaining the valuable learning experiences, shorter term teams don't have the chance to really gel as a team.  By the time they become familiar enough with each other and build an good level of trust and loyalty to really make strides in improving their practices, they're torn apart and reassigned. 

My preference would be to see teams work together as cohesive units for long periods of time.  This allows the team time to grow and mature together.  It builds trust and loyalty within the team that leads to a team's commitment to building the best products and developing the best practices they can as a team.  These teams have the time to do some real learning and real improvement.  Our team here in Ft. Collins has worked both ways and I'd have to say, we've made much greater advances when we worked together as a team for longer durations than when we've been split up amongst several smaller teams for short term projects.

Tuesday, May 27, 2008 6:22:41 PM (Mountain Daylight Time, UTC-06:00)
I agree with Chris. Of course, the question becomes how to make this happen. I've been talking with several organizations recently who are figuring this out. I find it helpful to think in terms of a persistent team (as Chris described) that has work flowing in and out of it. (As opposed to the traditional focus on a static project which must be resourced.) That project work might be aggregated into a single team product backlog--Team Purple is working on Project 1 and Project 2 simultaneously. The advantage there is that the single backlog can reflect relative priorities between the projects. The down side is that it's a macro-version of task-switching. Another pattern is that for our persistent team, projects flow in and out sequentially. Team Orange completes Project 3, then completes Project 4. The advantage is focus, and all of Project 3 (or, whatever PO determines is "done" for the project) is completed more quickly. The down side is that none of Project 4 is delivered until Project 3 is done. Ultimately, what's best depends on the nature of the projects, customers, goals, etc.

What other patterns have you seen?
Comments are closed.