CMMI with Agile - Contradict or Complement

1

CMMI with Agile Contradict or Complement ?

By M. Rajamanickam

SCAMPI Lead Appraiser & Enterprise Agile Coach

–

2

What are we going to discuss?

•  CMMI and Agile – Myths & Realities •  Let’s Revisit CMMI •  Let’s Revisit Agile •  CMMI with Agile– Similarities and Differences •  Benefits of CMMI with Agile •  CMMI and Agile Mapping •  Q & A

3

Agile & CMMI: Some Myths •  CMMI is command and Control (Agile is self organizing) •  CMMI is a heavy weight process (Agile is light / No process) •  CMMI is a rigid model (Agile is flexible/No model) •  CMMI is Process Oriented and Agile is People Oriented •  CMMI expects/produces lot of documents (Agile does not

require/produce any document) •  CMMI is for big projects and Agile is for small projects •  CMMI and Agile are at odds with each other: They can not

go together •  There is little or no planning in Agile •  Agile teams have free run – No control… •  You need very experienced team for Agile •  Agile works in Product Development, but do not go

together with outsourcing

4

Why (or Where) do these myths come (from)? •  Historic issues from early adaptors

•  CMM: Large scale, mission critical, risk averse, contractual projects

•  Agile: Small to Medium, fast paced, in-house projects with access to customers

•  Lack of familiarity & negative perceptions of each other •  Perceived as two extremes: either CMMI world or Agile

world •  Confusing terminologies / jargons •  CMMI perceived as ‘rigid,’ ‘Waterfall’; Agile perceived

as ‘hacking’ •  Lack of right information of each other •  Improper implementation of Agile (and CMMI)

5

Let’s Revisit CMMI

6

Maturity Models – An Overview A maturity model is a structured collection of

elements that describe characteristics of effective processes. A maturity model provides

• a place to start • the benefit of a community’s prior experiences • a common language and a shared vision • a framework for prioritizing actions

A maturity model can be used as a benchmark for assessing different organizations for equivalent comparison.

7

What is CMMI®? A CMMI ® is a reference model of mature practices in a specified

discipline, used to improve and appraise a group’s capability to perform that discipline.

CMMI ® differ by • Constellation (e.g., Development, Services, Acquisition) • Structure (e.g., staged, continuous)

CMMI can help • integrate traditionally separate organizations • set process improvement goals and priorities • provide guidance for quality processes • provide a yardstick for appraising current practices

8

CMMI Model Framework

Note: GOALS are the REQUIRED components and PRACTICES are the EXPECTED components

9

The Maturity Levels

10

CMMI Maturity Levels (Staged Representation)

11

Level 1: the “Initial” Level - Success depends on heroes

Good performance is possible - but •  Requirements often misunderstood,

uncontrolled •  Schedules and budgets frequently

missed •  Progress not measured •  Product content not tracked or

controlled •  Engineering activities nonstandard,

inconsistent •  Teams not coordinated, not trained •  Defects proliferate

“Processes limit my creativity” “Processes don’t help my delivery schedule”

12

Top Management

Middle Management

Dept. B

The Organization

Dept. A Dept. C

Project 1

Div. BB Div. AA

Project 4 Project 3 Project 2 Projects

Processes

Sample Level 1 Organization - few processes in place

13

Level 2 - The Foundation

The basic foundation to be laid is good ‘Project Management’ •  Most projects fail due to bad project

management practices rather than technical issues

14

Top Management

Middle Management

Dept. B

The Organization

Dept. A Dept. C

Project 1

Div. BB Div. AA

Project 4 Project 3 Project 2 Projects

Processes

Sample Level 2 Organization

many processes in place but they are project-specific

15

Process Areas in Maturity Level 2

•  Requirement Management (REQM) •  Project Planning (PP) •  Project Monitoring and Control (PMC) •  Supplier Agreement Management (SAM) •  Measurement and Analysis (MA) •  Process and Product Quality Assurance (PPQA) •  Configuration Management (CM)

16

Maturity Level 2 – Summary

•  Maturity Levels •  Maturity Level 1 - Ad hoc, sometimes chaotic •  Maturity Level 2 - Activities planned,

performed, monitored, and controlled at the level of a project.

17

Level 3 – Process Standardization

In Level 2, Project Management is disciplined, but not standardized

•  Very difficult to run big organizations that way •  The main need is to standardize the processes

across the organization •  And to bring the discipline of Engineering

practices

18


•  Requirements Development (RD) •  Technical Solution (TS) •  Product Integration (PI) •  Verification (VER) •  Validation (VAL) •  Organizational Process Focus (OPF) •  Organizational Process Definition (OPD) •  Organizational Training (OT) •  Integrated Project Management (IPM) •  Risk Management (RSKM) •  Decision Analysis and Resolution (DAR)

19

Sample Level 3 Organization

Div. AA

The Organization

Dept. A Dept. C

Div. BB

Projects

Processes

Project 1 Project 2

Dept. B

Project 3 Project 4

SEPG

Process Asset Library Approved life cycles Standard processes Tailoring guidelines Process database Related documents

20

CMMI – complete with High Maturity practices •  After Organizational level standardization in Level 3, the

focus is on quantitative management and continuous improvement

•  CMMI Level 4 & 5 are focused on the same

21

Summary of CMMI •  Select appropriate model representation to suit your business

goals •  Interpret the CMMI Model appropriately to your project/

organization appropriately •  CMMI process areas provide framework for process improvement

and for assessing capabilities •  Provides “outline” for corporate processes •  Specific and generic practices provide foundation for meeting

process maturity goals for each process area •  Represents industry’s set of “best practices” for engineering and

product development •  High level of compatibility/synergy with other standards and

methods

22

Things to Remember

•  CMMI is a Model, not a Standard •  CMMI Process Areas (PAs) are not Processes /

procedures

•  CMMI is not a prescriptive model, it is a descriptive model (CMMI does not prescribe ‘How’ to do it, it only mentions ‘what’ to do)

•  CMMI does not certify a company (CMMI certified Company is a misnomer!)

23

Let’s Revisit Agile Methods

24

The Basic Issue of Software Development

•  Ziv’s Uncertainty Principle •  Uncertainty is inherent and inevitable in

software development processes and products •  Humphrey’s Requirements Uncertainty

Principle •  For a new software system the requirements

will not be completely known until after the users have used it

•  Wegner’s Lemma •  It is not possible to completely specify an

interactive system

25

Agile Manifesto We are uncovering better ways of developing software by doing

it and helping others do it. Through this work we have come to value:

25 http://agilemanifesto.org/

Individuals and Interactions Processes and Tools

Working Software Comprehensive Documentation

Customer Collaboration Contract Negotiation

Responding to Change Following the Plan

over

over

over

over

That is, while there is value in the items on the right, we value the items on the left more.

26

Agile Principles •  Our highest priority is to satisfy the customer through

early and continuous delivery of valuable software.

•  Welcome changing requirements, even late in development. Agile processes harness change for

the customer's competitive advantage.

•  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the

shorter timescale.

•  Business people and developers must work together daily throughout the project.

27

•  Build projects around motivated individuals. Give them the environment and support they need, and trust

them to get the job done.

•  The most efficient and effective method of conveying information to and within a development team is

face-to-face conversation.

•  Working software is the primary measure of progress.

•  Agile processes promote sustainable development. The sponsors, developers, and users should be able to

maintain a constant pace indefinitely.

Agile Principles

28

•  Continuous attention to technical excellence and good design enhances agility.

•  Simplicity--the art of maximizing the amount

of work not done--is essential.

•  The best architectures, requirements, and designs emerge from self-organizing teams.

•  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its

behavior accordingly.

Agile Principles

29

Sequential (Waterfall) Process

Analysis

Design

Coding

Testing

Time

30

Features of traditional software!

* Standish Group Chaos Report 2002

31

Analysis

Design

Coding

Testing Ti

me

The Agile Process

32

The Agile Process

Analysis

Design

Coding

Testing Ti

me

33

Analysis

Design

Coding

Testing

20% done (100% usable!)

Ø Develop 20% of the features that deliver 80% of value

Ø Develop and deploy highest priority first

Ø Stop when you run out of time or money

Tim

e

The Agile Process

34

Traditional vs Agile Development

Requirements

Cost Schedule

Constraints

Estimate

Cost Schedule

Requirements Traditional Agile

Source: Michele Sliger: Relating PMBOK Practices to Agile Practices on StickyMinds.com

35

Scrum Overview

36

Release planning

Sprints 1 2 3 4 5 6 7

Release 1 Release 2

37

Main Differences (CMMI & Agile) CMMI Agile Discipline Agility Predictability Performance Proactive Reactive Descriptive (What) Prescriptive (How) Quantitative Qualitative Stability Speed Institutionalization (Project & Organization)

Project Specific (Individual projects)

Standardization Innovation Documented knowledge Tacit knowledge Scalable Scalable? Knowledge sharing across the organization

Knowledge sharing within the project

38

Myths Revisited… •  Some myths:

•  CMMI is command and Control (agile is self organizing) •  CMMI is a heavy weight process (Agile is light / no

process) •  CMMI is a rigid model (Agile is flexible/no model) •  CMMI is Process Oriented and Agile is People Oriented •  CMMI expects/produces lot of documents (Agile does not

require/produce any documents) •  CMMI is for big projects and Agile is for small projects •  CMMI and Agile can not go together •  There is little or no planning in Agile •  Agile teams have free run – no control •  You need very experienced team for Agile •  Agile and outsourcing do not go together

39

What is the Reality? •  CMMI is NOT Command and Control, you can interpret CMMI

to your specific needs •  CMMI need not be heavy weight, can be ‘tailored’ to specific

project needs •  CMMI is a model, not a standard.

•  If CMMI is perceived as rigid, the problem could be inappropriate interpretation

•  While CMMI is process oriented, this does not ignore people (relook at the definition of Process as per CMMI). •  Agile is equally process oriented too

(Look at the Scrum Process and rules) •  CMMI does not expect any unnecessary documents.

•  If you can not justify a document, do not produce it.

40

•  While CMMI is conceived for big project environments, it works very well with small projects too (with appropriate interpretation and tailoring)

•  Many big and complex projects implement Scrum (Eg. Yahoo!) •  Agile and CMMI can work very well with each other

•  There are instances companies have appraised at CMMI Level 5 with Agile processes

•  Agile too stresses on planning, in fact in multiple levels •  Daily Planning, Sprint Planning, Release Planning, Product

Planning, Product Strategy, etc., •  Agile teams are self organizing:

•  More effective than command and control •  You do not need all experienced people in Agile

•  Experts and new bees work well in an Agile team •  Agile methods suit well for Product Development Environment

•  However, they can be adjusted for outsourcing environment

What is the Reality?

41

What are the Similarities?

•  Both Agile and CMMI focus on Planning •  Target of both are High Performance Organization •  Both have process (of varying details, though) •  Both are based on experience •  Both may not work on ‘any’ project

Advantages of using both: •  CMMI provides the discipline where as Scrum brings in the

flexibility & speed •  Agile practices could become more mature with CMMI (Matured

Agile!) •  Agility could be institutionalized across the organization through

CMMI •  Organizational cross learning of agility through CMMI practices

42

Lots of work have already been done!

•  Standard references are available both from CMMI Community and Agile Community

•  CMMI or Agile: Why Not Embrace Both! (Hillel Glazer, Jeff Dalton & Dave Anderson)

•  Scrum and CMMI – Going from Good to Great (Jeff Sutherland, Carsten Ruseng Jakobsen)

•  Scrum and CMMI Level 5: The Magic Potion for Code Warriors (Jeff Sutherland, Carsten Ruseng Jakobsen & Kent Johnson)

•  And many more…

43

CMMI & Scrum Cross Mapping for Maturity Level 2

44


•  Requirement Management (REQM) •  Project Planning (PP) •  Project Monitoring and Control (PMC) •  Supplier Agreement Management (SAM) •  Measurement and Analysis (MA) •  Process and Product Quality Assurance (PPQA) •  Configuration Management (CM)

45

Requirements Management •  Purpose:

•  The purpose of Requirements Management (REQM) is to manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products.

Requirements

Obtain anUnderstanding

of Requirements

ObtainCommitment

to Requirements

Traceability Matrix

MaintainBidirectional Traceability ofRequirements

IdentifyInconsistenciesBetween Project

Work and Requirements

Manage Requirements

Manage Requirements

Changes

Requirements

Obtain anUnderstanding

of Requirements

ObtainCommitment

to Requirements

Traceability Matrix

MaintainBidirectional Traceability ofRequirements

IdentifyInconsistenciesBetween Project

Work and Requirements

Manage Requirements

Manage Requirements

Changes

✔ ✔ ✔

✖

✔

46

What needs to be done… •  Do the preparative activates in Sprint Zero

•  may not be classical Agile practice!

Sprints Zero 1 2 3 4 5 6 7

Release 1 Release 2

47

Major activities in Sprint Zero •  Identify Team (& Get them on board)

•  Train the team on Agile, if not done already •  Gather high level requirements (Build Initial

Product Backlog) – Write initial User Stories •  (Relative) Estimation of User Stories •  Release Planning, if required (with cost estimation) •  High level architecture (where required) •  Logistics Setup (Technical Infrastructure) •  Identify major risks, constraints & assumptions •  Prepare an overall plan (and still be flexible!)

•  Sprint Zero may not have potentially shippable product increment. That’s OK!

48

Project Planning •  Purpose:

•  The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.

Determine Estimates

of Effortand Cost

PlanningData

Establish Estimates

Estimate the Scope

of the Project

EstablishEstimates of

Work Productand Task

Attributes

Define ProjectLifecycle

Determine Estimates

of Effortand Cost

PlanningData

Establish Estimates

Estimate the Scope

of the Project

EstablishEstimates of

Work Productand Task

Attributes

Define ProjectLifecycle

Establish the Budget

andSchedule

Planning Data

Develop a Project Plan

Planfor Data

Management

Plan Stakeholder

Involvement

Plan forProject

Resources

Project Plan

Establishthe Project

Plan

IdentifyProject Risks

Plan forNeeded

Knowledge and Skills

PMC

Establish the Budget

andSchedule

Planning Data

Develop a Project Plan

Planfor Data

Management

Plan Stakeholder

Involvement

Plan forProject

Resources

Project Plan

Establishthe Project

Plan

IdentifyProject Risks

Plan forNeeded

Knowledge and Skills

PMC

Obtain Commitment to the Plan

ReconcileWork andResource

Levels

ProjectPlans

ReviewPlans that

Affect the Project

ObtainPlan

CommitmentRelevant

Stakeholders

Obtain Commitment to the Plan

ReconcileWork andResource

Levels

ProjectPlans

ReviewPlans that

Affect the Project

ObtainPlan

CommitmentRelevant

Stakeholders

✔ ✔

✔

✔

✔ ✓✖ ✓✖ ✖

✖ ✖ ✖

✖

✔

✔

49

Project Monitoring and Control Context •  Purpose: Provide understanding into the project’s progress so that appropriate

corrective actions can be taken when the project’s performance deviates significantly from the plan.

Project Plan

MonitorData

Management Monitor

Commitments

Monitor Project

PlanningParameters

ConductMilestoneReviews

Monitor Project Risks

AnalyzeIssues

TakeCorrective

Action

Monitor Project Against Plan

ConductProgressReviews

Monitor StakeholderInvolvement Manage

Corrective Action

PP

ManageCorrective Action

to Closure

Project Plan

MonitorData

Management

MonitorData

Management Monitor

Commitments Monitor

Commitments

Monitor Project

PlanningParameters

Monitor Project

PlanningParameters





AnalyzeIssues

AnalyzeIssues

TakeCorrective

Action

TakeCorrective

Action

Monitor Project Against Plan



Monitor StakeholderInvolvement

Monitor StakeholderInvolvement Manage

Corrective Action

ManageCorrective

Action

PP

ManageCorrective Action

to Closure

✔ ✔ ✓✖ ✖

✓✖ ✔ ✔

✔

✔

✔

50

Measurement and Analysis •  Purpose:

•  The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability used to support management information needs.

Information need

SpecifyMeasures

Measurement Repository

CollectMeasurement

Data

Measurement Results

EstablishMeasurement

Objectives

Communicate Results

SpecifyAnalysis

Procedures

Measurement Objectives

StoreData &Results

Analyze Measurement

Data

SpecifyData

Collectionand StorageProcedures

Procedures and Tools

Align Measurement and Analysis Activities

Provide Measurement Results

Information need

SpecifyMeasures

Measurement Repository

CollectMeasurement

Data

Measurement Results

EstablishMeasurement

Objectives

Communicate Results

SpecifyAnalysis

Procedures

Measurement Objectives

StoreData &Results

Analyze Measurement

Data

SpecifyData

Collectionand StorageProcedures

Procedures and Tools

Align Measurement and Analysis Activities

Provide Measurement Results

✖ ✓✖ ✖ ✖

✖ ✔ ✔ ✔

51

Process and Product Quality Assurance •  Purpose:

•  The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.

Reports and Records

Objectively Evaluate Processes and Work Products

Provide Objective Insight

Objectively

EvaluateProcesses

EstablishRecords

Communicateand Ensure

Resolution ofNoncompliance

Issues

ObjectivelyEvaluate

Work Products

& Services

Relevant Stakeholders

Reports and Records

Objectively Evaluate Processes and Work Products

Provide Objective Insight

Objectively

EvaluateProcesses

EstablishRecords

Communicateand Ensure

Resolution ofNoncompliance

Issues

ObjectivelyEvaluate

Work Products

& Services


✓✖ ✓✖

✖ ✖

52

Configuration Management •  Purpose:

•  Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

Change RequestDatabase

ConfigurationManagement

System

Identify Configuration

Items

EstablishConfigurationManagement

Records

Establish aConfigurationManagement

System

PerformConfiguration

Audits

ChangeRequests

ActionItems

Audit Results

Create or Release

Baselines

Reports

Establish Baselines

Establish Integrity

ControlConfiguration

Items

TrackChange

Requests

Track andControlChanges

Change RequestDatabase

ConfigurationManagement

System

Identify Configuration

Items

EstablishConfigurationManagement

Records

Establish aConfigurationManagement

System


Audits


Audits

ChangeRequests

ActionItems

Audit Results

ActionItems

Audit Results

Create or Release

Baselines

Reports

Establish Baselines

Establish Integrity

ControlConfiguration

Items

TrackChange

Requests

Track andControlChanges

One of the major issues of Agile is the

lack of explicit focus of CM activities. This can be taken care by the

CMMI processes

53

Supplier Agreement Management Purpose

•  Manage the acquisition of products and services from suppliers external to the project for which there exists a formal agreement.

Product

EstablishSupplier

Agreements

DetermineAcquisition

Type

TransitionProducts

Accept theAcquiredProduct

SelectSuppliers

Supplier Requirements

Executethe SupplierAgreement

Establish Supplier Agreements

Satisfy Supplier Agreements

Supplier Agreement

PI

TS

Monitor Selected Supplier

Processes

Evaluate Selected Supplier

Work Products

Product Product

EstablishSupplier

Agreements

DetermineAcquisition

Type

TransitionProducts

TransitionProducts



SelectSuppliers

Supplier Requirements



Establish Supplier Agreements

Satisfy Supplier Agreements

Supplier Agreement Supplier Agreement

PI

TS

Monitor Selected Supplier

Processes

Evaluate Selected Supplier

Work Products

Agile methods do not talk about any sub contracting. Use your CMMI processes, if

needed. Ensure the sub contractor

also follows Agile !

54

CMMI & Scrum Cross Mapping for Maturity Level 3

55


•  Requirements Development (RD) •  Technical Solution (TS) •  Product Integration (PI) •  Verification (VER) •  Validation (VAL) •  Organizational Process Focus (OPF) •  Organizational Process Definition (OPD) •  Organizational Training (OT) •  Integrated Project Management (IPM) •  Risk Management (RSKM) •  Decision Analysis and Resolution (DAR)

56

Engineering Process Areas

•  Most of the Engineering practices

are not explicitly covered in Scrum. However, it is suggested to use the following Agile Methods / practices:

•  Popular eXtreme Programming (XP) practices •  Peer Programming •  Refactoring •  Continuous Integration (CI) •  Test Driven Development

(TDD) •  It is also a good practice to use

tools for TDD & CI

57

Organizational Standardization PAs •  Organizational Process Focus (OPF) •  Organizational Process Definition (OPD) •  Organizational Training (OT)

•  Scrum (or any other Agile Methods) do not explicitly address any of the practices of OPF, OPD and OT. The focus of most of the Agile methods are at project level (not organizational standardization of practices).

•  However, institutionalizing these practices at the Organizational level (which does not hinder Agile implementation in the projects) will help in making Enterprise Agile, which is a new topic of interest with the Agile Community.

58

Integrated Project Management •  Purpose:

•  Establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes.

• Process and Product Measures

• Documentation• Lessons Learned

OPF

Project’s Defined Process

Use Org. Proc. Assets for Planning

ProjectActivities

Managethe Project Using theIntegrated

Plans

ManageStakeholderInvolvement

StakeholderCoordination

Issues

Contributeto the

OrganizationalProcessAssets

ManageDependencies

ResolveCoordination

Issues

Documented Critical

Dependencies

Collaborative Activities

and Issues

Coordinate and Collaborate with


Use the Project’s Defined Process

Establishthe Project’s

Defined Process

Integrate Plans

Integrated Project Plans

Establish the Project’s

Work Environment

OPD

• Process and Product Measures

• Documentation• Lessons Learned

OPF



Use Org. Proc. Assets for Planning

ProjectActivities

Managethe Project Using theIntegrated

Plans

ManageStakeholderInvolvement

StakeholderCoordination

Issues

Contributeto the

OrganizationalProcessAssets

ManageDependencies

ResolveCoordination

Issues

Documented Critical

Dependencies

Collaborative Activities

and Issues

Coordinate and Collaborate with


Use the Project’s Defined Process

Establishthe Project’s

Defined Process

Integrate Plans



Establish the Project’s

Work Environment

OPD

59

Interaction Between OPD and IPM

Project A’sDefined Process

Project B’sDefined Process

Project A’sProject Plan

Project C’sDefined Process

Project B’sProject Plan

Project C’sProject Plan

TailoringGuidelines

Lifecycle ModelDescriptions

Organization’sMeasurement

Repository

Organization’s Process

Asset Library

Organization’s Setof Standard Processes

ProcessArchitectures

Project Environment

Organizational Assets

OPD

IPM IPM IPM

Work EnvironmentStandards

Project A’sDefined Process

Project B’sDefined Process

Project A’sProject Plan

Project C’sDefined Process

Project B’sProject Plan

Project C’sProject Plan

TailoringGuidelines

Lifecycle ModelDescriptions

Organization’sMeasurement

Repository

Organization’s Process

Asset Library

Organization’s Setof Standard Processes

ProcessArchitectures

Project Environment

Organizational Assets

OPD

IPM IPM IPM

Work EnvironmentStandards

60

Risk Management •  Purpose:

•  Identify potential problems before they occur so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

DetermineRisk

Sourcesand

Categories

DefineRisk

Parameters IdentifyRisks

Evaluate, Categorize,

andPrioritize

Risks DevelopRisk

MitigationPlans

ImplementRisk

MitigationPlans

Risk Repository

Prepare for Risk Management Identify and Analyze Risks

Mitigate Risks

Establish a Risk

ManagementStrategy

PP

DetermineRisk

Sourcesand

Categories

DefineRisk

Parameters IdentifyRisks

Evaluate, Categorize,

andPrioritize

Risks DevelopRisk

MitigationPlans

ImplementRisk

MitigationPlans

Risk Repository

Prepare for Risk Management Identify and Analyze Risks

Mitigate Risks

Establish a Risk

ManagementStrategy

PP

61

Decision Analysis and Resolution •  Purpose:

•  Analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.

•  Applicability: •  Documented guidelines should be provided when formal

evaluation processes are to be used. •  Not supported in Agile. Existing CMMI processes may be used

with proper modifications (looking at Agile requirements of DAR)

62

Decision Analysis and Resolution - Context

Establish Guidelinesfor Decision

Analysis

Guidelines

Evaluate Alternatives

SelectEvaluationMethods

Methods Criteria

Establish Evaluation

Criteria

SelectSolutions

IdentifyAlternative Solutions

ProposedAlternatives

EvaluateAlternatives

Other PAs

Establish Guidelinesfor Decision

Analysis

Guidelines

Evaluate Alternatives


Methods


Methods Criteria


Criteria


Criteria

SelectSolutions

IdentifyAlternative Solutions

ProposedAlternatives

EvaluateAlternatives

Other PAs

63

Conclusion

•  Agile and CMMI could be complimentary to each other & they bring lot of advantages to an organization

•  Agile brings in the flexibility & speed whereas CMMI provides the discipline (and sustenance)

•  Agile practices could become more mature with CMMI (Matured Agile!)

•  Agility could be institutionalized across the organization through CMMI

•  Organizational cross learning of agility through CMMI practices

64

M. Rajamanickam ([email protected])

SCAMPI Lead Appraiser & Enterprise Agile Coach

Managing Partner, ProXL Consulting, Chennai – 600 101

CMMI with Agile - Contradict or Complement

Software

Transcript of CMMI with Agile - Contradict or Complement