CMMI and Agile – is convergence possible? An example of project using combined process Ivan Gumenyuk, EMC Saint-Petersburg Center Of Excellence [email_address] October, 25, 2008

Introduction Why need to talk about it? Too antagonistic views in both camps New time may require new approaches, including combination of old ones Convergence is real CMM(I) Some history Pros & Cons, where applicable Agile Pros & Cons, where applicable How it was in our project? Examples of “collaboration” of both approaches

Why need to talk about it?

Too antagonistic views in both camps

New time may require new approaches, including combination of old ones

Convergence is real

CMM(I)

Some history

Pros & Cons, where applicable

Agile

Pros & Cons, where applicable

How it was in our project?

Examples of “collaboration” of both approaches

CMM(I): some history CMMI is not “waterfall model” CMM – appeared in 1987 as an instrument for assessment of software companies 5 maturity levels: Chaotic, Repeatable, Defined, Managed and Optimized Set of Key Process areas, Goals, Features and Practices Documentation is not a goal, but a clue to prove the maturity level Quality as result of strict approach

CMMI is not “waterfall model”

CMM – appeared in 1987 as an instrument for assessment of software companies

5 maturity levels: Chaotic, Repeatable, Defined, Managed and Optimized

Set of Key Process areas, Goals, Features and Practices

Documentation is not a goal, but a clue to prove the maturity level

Quality as result of strict approach

CMMI: Pros & Cons CMM(I) pros and cons Well defined methodology, well defined process / Somewhat rigid Good documenting of products, systems and processes / much efforts for this, not suitable for small organizations/projects Level 3 is enough in many cases (for project mgmt) Level 4 and 5 are for process mgmt and improvement CMMI is more flexible than CMM, more process areas defined High quality and predictability are main goals CMM(I) fits for large projects/organizations with high quality requirements, complex systems CMM(I) does not fit for small projects, fast changing environment, simple systems with “good-enough” quality CMM(I) is good for distributed projects

CMM(I) pros and cons

Well defined methodology, well defined process / Somewhat rigid

Good documenting of products, systems and processes / much efforts for this, not suitable for small organizations/projects

Level 3 is enough in many cases (for project mgmt)

Level 4 and 5 are for process mgmt and improvement

CMMI is more flexible than CMM, more process areas defined

High quality and predictability are main goals

CMM(I) fits for large projects/organizations with high quality requirements, complex systems

CMM(I) does not fit for small projects, fast changing environment, simple systems with “good-enough” quality

CMM(I) is good for distributed projects

CMM(I): Applicability

Agile Started in late 199x, “Agile Manifest” announced in 2001 Set of software development methodologies that use iterative approach intensive collaboration and communication adaptive project management frequent intermediate releases, “always workable product” concept “ test first”…

Started in late 199x, “Agile Manifest” announced in 2001

Set of software development methodologies that use

iterative approach

intensive collaboration and communication

adaptive project management

frequent intermediate releases, “always workable product” concept

“ test first”…

From Agile to CMMI… My current project used Agile in the beginning… local team only SCRUM + Scrum Of Scrums Monthly sprints packed into quarterly releases Backlog for task assignment What changed? Initial prototype was done – architecture grew up significantly Lots of components, interfaces; complex integration Became 4 locations, one is in Russia – different time zone, language, no prior domain area experience Team grew up from tens to 100+ Not enough documentation – delays start of newcomers More people + more complexity = trunk unstability

My current project used Agile in the beginning…

local team only

SCRUM + Scrum Of Scrums

Monthly sprints packed into quarterly releases

Backlog for task assignment

What changed?

Initial prototype was done – architecture grew up significantly

Lots of components, interfaces; complex integration

Became 4 locations, one is in Russia – different time zone, language, no prior domain area experience

Team grew up from tens to 100+

Not enough documentation – delays start of newcomers

More people + more complexity = trunk unstability

From Agile to CMMI… What was done (CMMI elements) High-level System Specification was written (500+ pages) describing components, their interfaces, features-to-components mapping Feature teams were created, with separate planning Strict procedures for check-ins to the trunk Planning of integrations Test plans – product-wide and per features More focus on automated testing (product-wide) Instead of base releases based on set of tasks from a backlog – monthly planning toward final Code Complete milestone, based on feature plans & integration plans Defect handling process This helped! More ease newcomers adaptation – there are documents to read Improved communication Improved planning and tracking of the project More trunk stability, less lost efforts

What was done (CMMI elements)

High-level System Specification was written (500+ pages) describing components, their interfaces, features-to-components mapping

Feature teams were created, with separate planning

Strict procedures for check-ins to the trunk

Planning of integrations

Test plans – product-wide and per features

More focus on automated testing (product-wide)

Instead of base releases based on set of tasks from a backlog – monthly planning toward final Code Complete milestone, based on feature plans & integration plans

Defect handling process

This helped!

More ease newcomers adaptation – there are documents to read

Improved communication

Improved planning and tracking of the project

More trunk stability, less lost efforts

Combining both approaches CMMI has Agile elements inside… Spiral model was created in 1989… there are models of iterative development in CMMI Long-term milestones planning works well with Scrum between these milestones … and Agile has CMMI inside! Configuration Management, Integration Management, Requirements Management – these and others CMMI process areas de-facto exist in every good Agile project as well

CMMI has Agile elements inside…

Spiral model was created in 1989… there are models of iterative development in CMMI

Long-term milestones planning works well with Scrum between these milestones

… and Agile has CMMI inside!

Configuration Management, Integration Management, Requirements Management – these and others CMMI process areas de-facto exist in every good Agile project as well

Adding CMMI to Agile… Increased team size caused more check-ins and trunk became unstable? Need to make deliveries to trunk more formal and strict… Cannot quickly fix a bug in a year-old product version? Think about better documenting design and interfaces… Team growth, got another location? Think of writing system specification and common document repository… After testing ended it turned out that one are was not tested at all? Full list of requirements given to the testing team as early as possible could help… Several iterations were spent to improve the new product and it turned out that competitors are already on the market? Long-term planning of Go To Market date need to be done, then stick to the date… …

Increased team size caused more check-ins and trunk became unstable?

Need to make deliveries to trunk more formal and strict…

Cannot quickly fix a bug in a year-old product version?

Think about better documenting design and interfaces…

Team growth, got another location?

Think of writing system specification and common document repository…

After testing ended it turned out that one are was not tested at all?

Full list of requirements given to the testing team as early as possible could help…

Several iterations were spent to improve the new product and it turned out that competitors are already on the market?

Long-term planning of Go To Market date need to be done, then stick to the date…

…

Adding Agile to CMMI … Too long design phase caused late start of coding? Early prototyping, iterative design phase will help… QA team cannot start test cycle because Development does not give final build? Create tests just after early requirements available, run and debug tests on early builds… Complains that formal code reviews take too much time and still there are defects found? Make code review process more light-weight, but provide time for experienced engineers to do reviews… Project has already 30+ people and it’s impossible to track it? Scrum in small groups and Scrum Of Scrums can be useful… …

Too long design phase caused late start of coding?

Early prototyping, iterative design phase will help…

QA team cannot start test cycle because Development does not give final build?

Create tests just after early requirements available, run and debug tests on early builds…

Complains that formal code reviews take too much time and still there are defects found?

Make code review process more light-weight, but provide time for experienced engineers to do reviews…

Project has already 30+ people and it’s impossible to track it?

Scrum in small groups and Scrum Of Scrums can be useful…

…

Conclusion … Combining CMMI and Agile is possible; it’s real and obvious CMMI formally describes many practices that are already in place in many Agile projects Current tendency is not to create new code from scratch, but re-use and integrate what’s available Waterfall model does not work here Traditional methods of efforts estimation does not work Main phases are integration, testing and bug fixing Requirements & Architecture Search of appropriate solutions Modification of components Testing of Components Integration of Components Testing of the product

Combining CMMI and Agile is possible; it’s real and obvious

CMMI formally describes many practices that are already in place in many Agile projects

Current tendency is not to create new code from scratch, but re-use and integrate what’s available

Waterfall model does not work here

Traditional methods of efforts estimation does not work

Main phases are integration, testing and bug fixing

Thank you! [email_address]