Reusable Teams

Nov 3rd, 2002 by Tony in QSM3

One of the arguments against reusable software is that it doesn’t come free. We cannot reuse just any old software that’s been slapped together; we must make an additional investment to render it truly reusable. The higher that investment, the more times we must reuse the module to recoup the investment.

A similar argument is often made against using teams for software development and maintenance. Teams do require a startup cost, and in many projects this startup is so long we never recover the cost during the life of the project. This argument, however, is not against the use of teams, but in favour of better management of team formation.

Even if management were poor, the cost of team startup could be recovered by reusing the teams over a series of projects. Unfortunately, only the better software organizations seem to reuse their teams. Given that breaking up successful teams is economic nonsense, why is it so common? Long before the days of software, people understood that the practice of dissolving well-functioning teams ultimately derives from insecure management.

Isn’t it time that your software organization woke up? Just as reusable components are the basic units in hardware and software development, the software team is the basic design unit for software engineering processes. The job of the manager is to create, nurture, and maintain the teams that can be configured and reconfigured into reliable, predictable projects. Without such teams, no software organization can ever emerge from a Variable (Pattern 1) or Routine (Pattern 2) culture.

— Jerry Weinberg, Quality Software Management Vol 3, Chapter 19

No Comments