killing the myth: agile & cmmi
DESCRIPTION
Slides presented at Agile Eastern Europe Conference in Kiev.TRANSCRIPT
Killing the myths: Agile and CMMI
Agile Eastern Europe Conference
Kiev, 23-24 September 2011
Christophe Debou
Tomasz de Jastrzebiec Wykowski [email protected]
ABOUT US
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: – [email protected]
Christophe Debou Background
• 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 de Jastrzębiec Wykowski
Tomasz de Jastrzębiec Wykowski
WHAT IS AGILE?
WHAT IS CMMI®?
Once upon a time ….
Process Improvement is an important part of the solution People
Process Technology
in-quality in-budget
on-time
Objective of improvements is
Increasing the Performance on time,
in budget, in quality
Directly influenced may be
people, processes, and
technology – therefore,
these are the dimensions to
act.
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
STRUCTURES AND CONTENTS
Staged Representation: Process Areas by Maturity Level
Causal Analysis and Resolution Organizational Performance Management
5 Optimizing
4 Quantitatively Managed
3 Defined
2 Managed
Quantitative Management
Process Standardization
Basic Project Management
Organizational Process Performance Quantitative Project Management
Decision Analysis and Resolution Integrated Project Management Organizational Process Definition Organizational Process Focus Organizational Training Product Integration Requirements Development Risk Management Technical Solution Validation Verification
Configuration Management Measurement and Analysis Project Monitoring and Control Project Planning Process and Product Quality Assurance Requirements Management Supplier Agreement Management
1 Initial
Process Areas Level Focus
Continuous Process Improvement
Risk Rework
Quality Productivity
CMMI (Staged Representation) is organized in levels
describing the capabilities of the organization
1
2
3
4
5
No or only few processes, success
dependent on people’s performance
Basic processes established
(especially project management)
Further processes being added, process standardization
and systematic process improvement
Quantitative process control with statistical methods:
Process performance predictable
Continuous process improvement
Architecture of a Process Area
Related
Process Areas Introductory
Notes
Typical Work
Products
Subpractices
Expected Informative
Specific Goals (SG)
Generic Goals (GG)
Required
Purpose
Statement
Specific Practices
(SP) Generic
Practices (GP)
Generic Practice
Elaborations
Legend
Process Area (PA)
Subpractices
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“
CMMI is a journey to excellence
CMMI Level 2 Process Areas
Project Monitoring and Control
Measurement and Analysis
Project Planning
Requirements Management
Process and Product Quality Assurance
Configuration Management
REQUIREMENTS MANAGEMENT
Requirements Development (RD)
Purpose
• Produce and analyze customer, product, and product component requirements.
Requirements Development Context -1
Analyze and Validate
Requirements
Develop Customer
Requirements
Validated Customer Requirements
Validated Product, Product Component, and Interface Requirements
Develop Product
Requirements Stakeholders’
Needs
Source: Introduction to CMMI, SEI, Accredited Course
Requirements Development Context -2
Analyze Requirements
to Achieve Balance
Analyze Requirements
(necessary and sufficient)
Customer, Product, Product Component, and Interface Requirements
Validated Requirements
Analyze and Validate Requirements
Validate Requirements
Establish Operational Concepts
& Scenarios
Establish a Definition of
Required Functionality
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.
Requirements Management Context
Requirements
Traceability Matrix
Maintain Bidirectional Traceability of Requirements
Identify Inconsistencies Between Project
Work and Requirements
Manage Requirements
Obtain an Understanding
of Requirements
Obtain Commitment
to Requirements
Manage
Requirements
Changes
Source: Introduction to CMMI, SEI, Accredited Course
Customer collaboration over contract negotiation --- Agile Manifesto ---
Requirements Management
CMMI Goal
SG 1 Requirements are managed and inconsistencies with the project plans and work products are identified
Agile Practices Gathered in Product Backlog Ordered and prioritized In form of User Stories for better
understanding. Clarified by discussion and acceptance
criteria definition. PO is the ultimate decision maker 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
PROJECT PLANNING
Project Planning Context -1
Planning Data
Establish Estimates
Develop a Project Plan
Obtain Commitment to the Plan
Project Plan
PMC
Relevant
Stakeholders
Source: Introduction to CMMI, SEI, Accredited Course
Purpose
Establish and maintain plans that define project activities
Project Planning Context -2
Determine Estimates
of Effort and Cost
Planning Data
Establish Estimates
Estimate the Scope
of the Project
Establish Estimates of
Work Product and Task
Attributes
Define Project Lifecycle
Source: Introduction to CMMI, SEI, Accredited Course
Project Planning Context -3
Planning Data
Develop a Project Plan
Plan for Project
Resources
Project Plan
Establish the Project
Plan
Identify Project Risks
Plan for Needed
Knowledge and Skills
PMC
Establish the Budget
and Schedule
Plan for Data
Management
Plan Stakeholder
Involvement
Source: Introduction to CMMI, SEI, Accredited Course
Project Planning Context – 4 Obtain Commitment
to the Plan
Reconcile Work and Resource
Levels
Project Plans
Review Plans that
Affect the Project
Obtain Plan
Commitment
Relevant
Stakeholders
Source: Introduction to CMMI, SEI, Accredited Course
“In preparing for battle I have always found that plans are useless, but planning is indispensable.”
--- Dwight David Eisenhower ---
Project Planning
CMMI Goal
SG 1 Estimates of project planning parameters are established and maintained
Agile Practices
Separate estimates for stories (Story Points) and Tasks (Ideal Hours) allows for different levels of accuracy.
Work break down structure (WBS) with different levels of details (Product, features, epics, stories and tasks)
Costs and effort can be derived from estimates (#h/SP).
Project Planning
CMMI Goal
SG 2 A project plan is established and maintained as the basis for managing the project.
Agile Practices
Planning on different levels (Product, Release, Sprint, Day).
Updating plans basing on facts (inspect & adapt)
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
Project Planning
CMMI Goal
SG 3 Commitments to the project plan are established and maintained
Agile Practices
Committed Team, PO and SM
Project plans reviewed and committed to during Release/Sprint planning meetings
Project status is reviewed (Inspect) on Daily Scrums, Reviews and Retrospectives and plans are updated
PROJECT MONITORING AND CONTROL
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.
Project Monitoring and Control Context
Project Plan
Monitor Project Against Plan
PP
Manage Corrective Action
to Closure
Monitor Project Planning
Parameters
Monitor Commitments
Monitor Project Risks
Monitor Data
Management
Conduct Milestone Reviews
Conduct Progress Reviews
Monitor Stakeholder Involvement Manage
Corrective Action
Take Corrective
Action
Analyze Issues
Source: Introduction to CMMI, SEI, Accredited Course
Responding to change over following a plan --- Agile Manifesto ---
Project Monitoring and Control
CMMI Goal
SG 1 Actual performance and progress of the project are monitored against the project plan
Agile Practices
Project status inspection on Daily Scrum, Reviews and Retrospectives
Measurements based on facts (delivered stories)
Main metric – Velocity
Concentration on TODO value, rather than on time already spent.
Project Monitoring and Control
CMMI Goal
SG 2 Corrective actions are managed to closure when the project's performance or results deviate significantly from the plan.
Agile Practices
Plans updated basing on facts.
More flexibility – in case of delays scope can be limited to meet deadlines.
Impediments collected and resolved by ScrumMaster
MEASUREMENT AND ANALYSIS
Measurement and Analysis (MA)
Purpose
• Develop and sustain a measurement capability that is used to support management information needs.
Measurement & Analysis Context
Information need
Measurement Repository
Measurement Results
Measurement Objectives
Store Data & Results
Specify Data
Collection and Storage Procedures
Procedures and Tools
Align Measurement and Analysis Activities
Provide Measurement Results
Establish Measurement
Objectives
Specify Measures
Specify Analysis
Procedures
Communicate Results
Analyze Measurement
Data
Collect Measurement
Data
Source: Introduction to CMMI, SEI, Accredited Course
“Data is of course important in manufacturing, but I place the greatest emphasis on facts.”
--- Taiichi Ohno ---
Measurements and Analysis
CMMI Goal
SG 1 Measurement objectives and activities are aligned with identified information needs and objectives.
Agile Practices
Agile Process and Quality metrics (e.g. Velocity, Code Coverage)
Use it or Lose it – too much data can hinder understanding of project status.
Measurements based on facts (delivered stories)
Measurements and Analysis
CMMI Goal
SG 2 Measurement results that address identified information needs and objectives are provided.
Agile Practices
Information radiators – visible data make project status available for everybody
Measurements analyzed on different levels (on daily, Sprint, Release basis)
CONFIGURATION MANAGEMENT
Configuration Management (CM)
Purpose
• Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and
configuration audits.
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. ”
Require ments
Sub-Areas of Development
Time (successive versions coming about)
Examples of Baselines: Design Code Test Cases
Iteration I Baseline
Iteration II Baseline
Iteration III Baseline
Baseline
Release I Baseline
Configuration Management Context
Change
Request
Database
Configuration
Management
System
Establish a Configuration Management
System
Change Requests
Action Items
Audit Results
Reports
Establish Baselines
Establish Integrity
Track and Control Changes
Create or Release
Baselines
Identify Configuration
Items
Establish Configuration Management
Records
Perform
Configuration Audits
Track Change
Requests
Control Configuration
Items
Source: Introduction to CMMI, SEI, Accredited Course
Working software over comprehensive documentation --- Principles behind the Agile Manifesto ---
Configuration Management
CMMI Goal
SG 1 Baselines of identified work products are established.
SG 2 Changes to the work products under configuration management are tracked and controlled.
SG 3 Integrity of baselines is established and maintained
Agile Practices
Configuration Management has to be supported by automated tools
Code and important documents held under version control and updated often
Common code – anyone can make changes
Anyone can add new requirements, but it’s PO who order them
Limit number of development branches in order to avoid integration issues
PROCESS AND PRODUCT QUALITY ASSURANCE
Process and Product Quality Assurance (PPQA)
Purpose
• Provide staff and management with objective insight into processes and associated work products.
Process and Product Quality Assurance Context
Reports and Records
Objectively Evaluate Processes and Work Products
Provide Objective Insight
Objectively
Evaluate Processes
Establish Records
Communicate and Ensure
Resolution of Noncompliance
Issues
Objectively Evaluate
Work Products
& Services
Relevant Stakeholders
Source: Introduction to CMMI, SEI, Accredited Course
Individuals and interactions over processes and tools --- Agile Manifesto ---
Process and Product Quality Assurance
CMMI Goal
SG 1 Adherence of the performed process and associated work products and services to applicable process descriptions, standards, and procedures is objectively evaluated.
Agile Practices
SM responsible for implementing Scrum processes by coaching and explaining the goals, not by enforcing the rules
Tools to ensure product and process quality adherence (e.g. automated tests), not to enforce it.
Retrospectives and Reviews allow for process and product quality improvements.
Team own development process.
Process and Product Quality Assurance
CMMI Goal
SG 2 Noncompliance issues are objectively tracked and communicated, and resolution is ensured.
Agile Practices
Noncompliance usually caused by problems with communication or processes. Therefore beside solving the quality problem, the root cause should be identified and removed by improving communication/process.
SUMMARY
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
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
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
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
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
Killing the myths: Agile and CMMI
Agile Eastern Europe Conference
23-24 September 2011
Christophe Debou
Tomasz de Jastrzebiec Wykowski [email protected]