Agile Zone is brought to you in partnership with:

Chris Spagnuolo has been working in the Geographic Information Systems (GIS) field for nearly 15 years. If it involves GIS, he's probably done it...everything from field data collection to large scale enterprise GIS deployments. Through this experience, he has reached the conclusion that the most effective way to deliver value is by the implementation of agile practices. He believes strongly in the effectiveness of agile practices and he is leading a new group to evangelize the benefits of agile. Chris is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

I Don't Like Short Duration Teams

  • submit to reddit
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.
Published at DZone with permission of Chris Spagnuolo, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.