cmmi with agile - contradict or complement
Post on 07-Aug-2015
64 Views
Preview:
TRANSCRIPT
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)
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
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
Process Areas in Maturity Level 3
• 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!)
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
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
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…
44
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)
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
ConductMilestoneReviews
ConductMilestoneReviews
Monitor Project Risks
Monitor Project Risks
AnalyzeIssues
AnalyzeIssues
TakeCorrective
Action
TakeCorrective
Action
Monitor Project Against Plan
ConductProgressReviews
ConductProgressReviews
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
Relevant Stakeholders
✓✖ ✓✖
✖ ✖
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
PerformConfiguration
Audits
PerformConfiguration
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
Accept theAcquiredProduct
Accept theAcquiredProduct
SelectSuppliers
Supplier Requirements
Executethe SupplierAgreement
Executethe SupplierAgreement
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 !
55
Process Areas in Maturity Level 3
• 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
Relevant Stakeholders
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
Project’s Defined Process
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
Relevant Stakeholders
Use the Project’s Defined Process
Establishthe Project’s
Defined Process
Integrate Plans
Integrated Project Plans
Integrated Project 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
SelectEvaluationMethods
Methods
SelectEvaluationMethods
Methods Criteria
Establish Evaluation
Criteria
Establish Evaluation
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
top related