I Don't Like Short Duration 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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Tags:





Comments
Ben Linders replied on Mon, 2013/01/14 - 11:16am
Fully agree with this. Earlier I wrote about my experiences with an organization that decided to implement stable teams. They defined fixed teams based upon product lines, and focused upon managing work packages for the teams instead of managing team composition, i.e. fitting the work to the team i.s.o. changing teams to get the work done. See the article about establishing and maintaining stable teams