The document provides background information on two speakers, Christophe Debou and Tomasz de Jastrzebiec Wykowski, who will be presenting at the Agile Eastern Europe Conference on killing the myths about Agile and CMMI. The speakers' backgrounds demonstrate experience with both traditional approaches like CMMI and adaptive approaches like Scrum and Kanban. The presentation will discuss what Agile and CMMI are, compare their structures and contents, and address common problems and misconceptions when combining the two frameworks.
Report
Share
Report
Share
1 of 77
Download to read offline
More Related Content
Killing the Myth: Agile & CMMI
1. Killing the myths:
Agile and CMMI
Agile Eastern Europe Conference
Kiev, 23-24 September 2011
Christophe Debou Tomasz de Jastrzebiec Wykowski
Christophe.Debou@kuglermaag.com Tomasz.Wykowski@procognita.com
3. Christophe Debou
• Business Development Director: Central and Eastern Europe
• Process Director
• Accredited CMMI Trainer for CMMI for Development and CMMI for
Services
• Experiences:
– About 10 Years Quality Management and Process Improvement
• Alcatel, as Coordinator of CMM Initiative, for the overall company (1994-1997).
• Q-Labs as consultant and member of management team (1997 – 2001)
• KUGLER MAAG CIE (2006)
• Customers e.g.: Alcatel, Ericsson, Bosch, Giesecke und Devrient, …
– About. 5 Years Senior Management
• Board member of ComArch
• Contact:
– Christophe.debou@kuglermaag.com
5. Tomasz de Jastrzębiec Wykowski
• 1000 years of experience in
software development
• Hands-on practice using both
traditional approaches (based
on PMBOK, ISO, CMM and
CMMI) and adaptive ones
(Scrum, Kanban, Extreme
Programming)
• Since 2010 trainer, coach and
consultant @ ProCognita
http://www.linkedin.com/in/wykowski
Tomasz.Wykowski@procognita.com
19. Process Improvement is an important
part of the solution
People
Objective of improvements is
Increasing the Performance on time,
in budget, in quality
on-time
Directly influenced may be
people, processes, and
technology – therefore,
these are the dimensions to
act.
in-budget in-quality
Process Technology
20. CMMI is a FRAMEWORK
• Not a Standard for developing products or
development processes
• Not a life cycle, nor a process, does not require
waterfall
• Not a prescription
• Is a description
• Mean for process Improvement not process
compliance
22. Staged Representation: Process Areas by
Maturity Level
Level Focus Process Areas Quality
Productivity
5 Optimizing Continuous Causal Analysis and Resolution
Process Organizational Performance Management
Improvement
4 Quantitatively Quantitative Organizational Process Performance
Managed Management Quantitative Project Management
3 Defined Process Decision Analysis and Resolution
Standardization Integrated Project Management
Organizational Process Definition
Organizational Process Focus
Organizational Training
Product Integration
Requirements Development
Risk Management
Technical Solution
Validation
Verification
2 Managed Basic Project Configuration Management
Management Measurement and Analysis
Project Monitoring and Control
Project Planning
Process and Product Quality Assurance
Requirements Management
Supplier Agreement Management Risk
1 Initial Rework
23. CMMI (Staged Representation) is organized in levels
describing the capabilities of the organization
5 Continuous process improvement
Quantitative process control with statistical methods:
4 Process performance predictable
Further processes being added, process standardization
and systematic process improvement
3
Basic processes established
(especially project management)
2
No or only few processes, success
dependent on people’s performance
1
24. Architecture of a Process Area
Process Area (PA)
Purpose Introductory Related
Statement Notes Process Areas
Specific Goals (SG)
Generic Goals (GG)
Specific
Practices
(SP)
Generic
Practices
Typical Work Subpractices (GP)
Products
Generic Practice
Subpractices
Elaborations
Legend Required Expected Informative
25. Problems and Solutions
Problems Solutions
„CMMI forces us to do things
we do not need.“
„Employee have no freedom.
Every single step is
described.“
„We cannot maintain
processes because of their
fast pace of changes“
27. CMMI Level 2 Process Areas
Requirements Management
Project Planning
Project Monitoring and Control
Configuration Management
Measurement and Analysis
Process and Product Quality Assurance
30. Requirements Development Context -1
Develop Develop Analyze and
Customer Product Validate
Stakeholders’ Requirements Requirements Requirements
Needs
Validated Customer Validated Product, Product Component, and
Requirements Interface Requirements
Source: Introduction to CMMI, SEI, Accredited Course
31. Requirements Development Context -2
Analyze and Validate Requirements
Establish Establish a Analyze
Operational Definition of Analyze Requirements
Concepts Required Requirements to Achieve
& Scenarios Functionality (necessary and Balance
sufficient)
Validate
Requirements
Customer, Product, Product Component, and Validated
Interface Requirements Requirements
32. Requirements Management
(REQM)
Purpose
• The purpose of Requirements Management
(REQM) is to manage the requirements of the
project’s products and product components
and to identify inconsistencies between those
requirements and the project’s plans and
work products.
33. Requirements Management
Context
Source: Introduction to CMMI, SEI, Accredited Course
Manage Requirements
Obtain Manage
Obtain an Commitment Requirements
Understanding to
of Changes
Requirements
Requirements Maintain
Bidirectional
Traceability of
Requirements
Requirements
Identify
Inconsistencies
Between Project
Work and Traceability Matrix
Requirements
35. Requirements Management
CMMI Goal Agile Practices
SG 1 Requirements are Gathered in Product Backlog
managed and Ordered and prioritized
In form of User Stories for better
inconsistencies understanding.
with the project Clarified by discussion and acceptance
plans and work criteria definition.
products are PO is the ultimate decision maker
identified Team committing to Sprint scope
Scope updated basing on facts.
Implemented functionality demoed and
accepted at Sprint Review.
Automated acceptance tests to ensure
traceability and identify inconsistences
37. Project Planning Context -1
Purpose
Establish and maintain plans that define project activities
Establish Planning Develop a
Estimates Data Project Plan
Obtain
Project
Commitment
Plan
to the Plan
Relevant
Stakeholders
PMC
Source: Introduction to CMMI, SEI, Accredited Course
38. Project Planning Context -2
Establish Estimates
Establish
Estimate Estimates of
the Scope Work Product
of the Project and Task
Attributes Planning
Data
Determine
Estimates
of Effort
and Cost
Define
Project
Lifecycle
Source: Introduction to CMMI, SEI, Accredited Course
39. Project Planning Context -3
Planning Data
Develop a Project Plan
Establish Plan
for Data Plan for
the Budget Identify
Management Project
and Project Risks
Resources
Schedule
Plan Establish Plan for
Stakeholder the Project Needed
Involvement Plan Knowledge
and Skills
PMC
Project Plan
Source: Introduction to CMMI, SEI, Accredited Course
40. Project Planning Context – 4
Obtain Commitment
to the Plan
Review
Plans that
Affect the
Project
Reconcile
Project Work and
Plans Resource
Levels
Obtain
Plan
Commitment
Relevant
Stakeholders
Source: Introduction to CMMI, SEI, Accredited Course
41. “In preparing for battle I have always found that
plans are useless, but planning is indispensable.”
--- Dwight David Eisenhower ---
42. Project Planning
CMMI Goal Agile Practices
SG 1 Estimates of Separate estimates for stories (Story
project planning Points) and Tasks (Ideal Hours)
parameters are allows for different levels of accuracy.
established and Work break down structure (WBS)
maintained with different levels of details
(Product, features, epics, stories and
tasks)
Costs and effort can be derived from
estimates (#h/SP).
43. Project Planning
CMMI Goal Agile Practices
SG 2 A project plan is Planning on different levels (Product,
established and Release, Sprint, Day).
maintained as the Updating plans basing on facts
basis for managing (inspect & adapt)
the project. Budget and schedule derived from
estimates. Owned by PO
Risks captured in User Stories. High
risk stories implemented first.
Transparency of status.
Committed Team, PO and SM
Cross-functional Team
44. Project Planning
CMMI Goal Agile Practices
SG 3 Commitments to Committed Team, PO and SM
the project plan Project plans reviewed and
are established and committed to during Release/Sprint
maintained planning meetings
Project status is reviewed (Inspect)
on Daily Scrums, Reviews and
Retrospectives and plans are updated
46. Project Monitoring and Control (PMC)
Purpose
• Provide understanding of the project’s
progress so that appropriate corrective
actions can be taken when the project’s
performance deviates significantly from
the plan.
47. Project Monitoring and Control
Context
Source: Introduction to CMMI, SEI, Accredited Course
Manage
Corrective Action
to Closure
Monitor Project Against Plan
Monitor Analyze
Project Monitor Monitor Issues
Monitor Data
Planning Commitments Project
Parameters Risks Management
PP
Take
Project Plan Corrective
Action
Conduct Conduct Monitor
Milestone Progress Stakeholder
Reviews Reviews Involvement Manage
Corrective
Action
49. Project Monitoring and Control
CMMI Goal Agile Practices
SG 1 Actual Project status inspection on Daily
performance and Scrum, Reviews and Retrospectives
progress of the Measurements based on facts
project are (delivered stories)
monitored against Main metric – Velocity
the project plan
Concentration on TODO value, rather
than on time already spent.
50. Project Monitoring and Control
CMMI Goal Agile Practices
SG 2 Corrective actions Plans updated basing on facts.
are managed to More flexibility – in case of delays
closure when the scope can be limited to meet
project's deadlines.
performance or Impediments collected and resolved
results deviate by ScrumMaster
significantly from
the plan.
52. Measurement and Analysis (MA)
Purpose
• Develop and sustain a measurement capability
that is used to support management
information needs.
53. Measurement & Analysis Context
Source: Introduction to CMMI, SEI, Accredited Course
Align Measurement and Analysis Activities
Specify
Establish Data Specify
Specify Collection
Measurement Analysis
Information Measures and Storage
Objectives Procedures
need Procedures
Measurement Objectives Measurement Procedures
Repository and Tools
Measurement Results
Provide Measurement Results
Store Analyze Collect
Communicate Data & Measurement Measurement
Results Results Data Data
54. “Data is of course important in manufacturing,
but I place the greatest emphasis on facts.”
--- Taiichi Ohno ---
55. Measurements and Analysis
CMMI Goal Agile Practices
SG 1 Measurement Agile Process and Quality metrics
objectives and (e.g. Velocity, Code Coverage)
activities are Use it or Lose it – too much data can
aligned with hinder understanding of project
identified status.
information needs Measurements based on facts
and objectives. (delivered stories)
56. Measurements and Analysis
CMMI Goal Agile Practices
SG 2 Measurement Information radiators – visible data
results that address make project status available for
identified everybody
information needs Measurements analyzed on different
and objectives are levels (on daily, Sprint, Release basis)
provided.
58. Configuration Management (CM)
Purpose
• Establish and maintain the integrity of
work products using configuration
identification, configuration control,
configuration status accounting, and
configuration audits.
59. Baseline SG1: Establish baselines of identified
work products
• A set of specifications or work products that has been formally reviewed and agreed
on, which thereafter serves as the basis for further development, and which can be
changed only through change control procedures. ”
Sub-Areas of Development
Require Design Code Test Cases
ments Examples of Baselines:
Time
(successive Iteration I Baseline
versions
coming
Iteration II Baseline
about)
Iteration III Baseline
Release I Baseline
60. Configuration Management Context
Source: Introduction to CMMI, SEI, Accredited Course
Track
Track Control and
Establish Baselines
Change Configuration Control
Requests Items Changes
Create or
Release
Baselines
Establish Integrity
Change Audit
Requests Results
Establish a Perform
Configuration Change Configuration
Audits Action
Management Request
Items
System Database
Configuration Establish
Identify Configuration
Configuration Management
Management
Items System Records
Reports
61. Working software over comprehensive documentation
--- Principles behind the Agile Manifesto ---
62. Configuration Management
CMMI Goal Agile Practices
SG 1 Baselines of identified Configuration Management has to be
work products are supported by automated tools
established. Code and important documents held
SG 2 Changes to the work under version control and updated
often
products under
configuration Common code – anyone can make
changes
management are
tracked and controlled. Anyone can add new requirements,
but it’s PO who order them
SG 3 Integrity of baselines is
Limit number of development
established and
branches in order to avoid
maintained integration issues
64. Process and Product Quality
Assurance (PPQA)
Purpose
• Provide staff and management with objective
insight into processes and associated work
products.
65. Process and Product Quality Assurance
Context
Source: Introduction to CMMI, SEI, Accredited Course
Objectively Evaluate Processes and Work Products
Objectively
Objectively Evaluate
Evaluate Work
Processes Products
& Services
Reports and Records
Provide Objective Insight
Communicate
and Ensure Establish
Resolution of Records
Noncompliance
Issues
Relevant
Stakeholders
67. Process and Product Quality Assurance
CMMI Goal Agile Practices
SG 1 Adherence of the SM responsible for implementing
performed process Scrum processes by coaching and
and associated explaining the goals, not by enforcing
work products and the rules
services to Tools to ensure product and process
applicable process quality adherence (e.g. automated
descriptions, tests), not to enforce it.
standards, and Retrospectives and Reviews allow for
procedures is process and product quality
objectively improvements.
evaluated.
Team own development process.
68. Process and Product Quality Assurance
CMMI Goal Agile Practices
SG 2 Noncompliance Noncompliance usually caused by
issues are problems with communication or
objectively tracked processes. Therefore beside solving
and the quality problem, the root cause
communicated, should be identified and removed by
and resolution is improving communication/process.
ensured.
71. Agile Processes
• Realistic – defined with support of those who will be using
it, not ‘theoretical experts’
• Live – Revised basing on lesson learned from individual
project
• Flexible – can be tailored to team and project needs, should
allow creativity, not introduce artificial limits
• Learnable – Written using language understandable by
those who will be using it
• Supportive – must be perceived as helpful by those who
will be using it.
• Lean – limit the ‘waste’ in the processes. Remove all
activities that does not add value to final product.
• Owned - by those who per form work
72. CMMI Processes
• Realistic – defined with support of those who will be using
it, not ‘theoretical experts’
• Live – Revised basing on lesson learned from individual
project
• Flexible – can be tailored to team and project needs, should
allow creativity, not introduce artificial limits
• Learnable – Written using language understandable by
those who will be using it
• Supportive – must be perceived as helpful by those who
will be using it.
• Lean – limit the ‘waste’ in the processes. Remove all
activities that does not add value to final product.
• Owned - by those who per form work
73. Agile
• Culture of high trust
• Collaboration with customer
• Flexibility and ability to adapt
• Transparency
• Learning and exploring
• Self organizing – delegating power to the team
• Working software
• Tools & techniques implements ‘how’ of CMMI’s ‘what’.
• Supports CMMI, but do not cover all requirements
74. CMMI
• Organizational development and learning
• A model, not a cookbook
• Can be applied in any context and organizational
size (just a matter of interpretation)
• Is not in contradiction with Agile Philosophy and
techniques
• Wider coverage
• Focus on institutionalization of good practices
• Implement CMMI rather than applying it
75. Further reading
Articles:
• Paul S. Adler “Building better Bureaucracies” The Academy of
Management Executive, Vol. 12, No. 4, p. 36, 1999
• Hillel Glazer, Jeff Dalton, David Anderson, Michael D. Konrad, Sandra
Shrum “CMMI or Agile: Why Not Embrace Both!” SEI Technical Note
CMU/SEI-2008-TN-003 November 2008
Reports:
• CMMI for Development, Version 1.3, Technical Report, CMU/SEI-
2010-TR-033, November 2010
Books:
• Jeffrey K. Liker, David Meier “The Toyota Way Fieldbook” , McGraw-
Hill, 2005
77. Killing the myths:
Agile and CMMI
Agile Eastern Europe Conference
23-24 September 2011
Christophe Debou Tomasz de Jastrzebiec Wykowski
Christophe.Debou@kuglermaag.com Tomasz.Wykowski@procognita.com
Editor's Notes
Ride and drive anythingExtreme conditionsHigh pressureDo impossible