Agile CMMI: No Oxymoron



CMMI (1.2) focuses on learning at the organizational level (and provides both project-based and organizationally based mechanisms for such learning). But some organizations implementing CMMI struggle to create the necessary environment and infrastructure for individual and team empowerment. TSP provides a “how to” solution consisting of team roles and other guidance that directly implement most CMMI practices while addressing the needs of both teams and individuals. A concise description of TSP with examples can be found in Watts Humphreys’ Winning with Software: An Executive Strategy (Addison-Wesley, 2002). The TSP website also provides information about TSP technology, training and adoption reports, including a mapping to CMMI.



Agility vs. the Team Software Process
Agile software development is anything but antithetical to TSP.

Agile Value Statement How TSP Relates
Individuals and interactions over processes and tools TSP holds that the individual is key to product quality and effective member interactions are necessary to the team’s success.

  • Project launches strive to create gelled teams.
  • Weekly meetings and communication are essential to sustain them.
  • Teams define their own processes in the launch.
Working software over comprehensive documentation

TSP teams can choose evolutionary or iterative lifecycle models to deliver early functionality—the focus is on high quality from the start. TSP does not require heavy documentation.

  • Documentation should merely be sufficient to facilitate effective reviews and information sharing.

Customer collaboration over contract negotiation

Learning what the customer wants is a key focus of the launch. Sustaining customer contact is one reason for having a customer interface manager on the team.

  • Focus on negotiation of a contract is more a factor of the organization than of whether TSP is used.

Responding to change over following a plan

TSP teams expect and plan for change by:

  • Adjusting the team’s process through process improvement proposals and weekly meetings.
  • Periodically relaunching and replanning whenever the plan is no longer a useful guide.
  • Adding new tasks as they are discovered; removing tasks that are no longer needed.
  • Dynamically rebalancing the team workload as required to finish faster.
  • Actively identifying and managing risks.

Read the full article at:
http://www.ddj.com/dept/architect/184415287

From ahm507.blogspot.com
,