Killing the myths: Agile and CMMI Agile Eastern Europe Conference Kiev, 23-24 September 2011Christophe Debou Tomasz de Jastrzebiec WykowskiChristophe.Debou@kuglermaag.com Tomasz.Wykowski@procognita.com
Aug 2005 CMMI 4 SVC Service CMMI Release Project Started CMMI: History1987 1991 1993 1995 1997 2000 2002 2006 2009 2010 CMMI-SE/SWFirst CMM SW-CMM v1.1 Version 1.0 CMMI-DEVPublished Published Published Version 1.2 Published Model Refined CMMI-SE/SW/IPPD/A CMMI Initiative and Published as Version 1.1 Launched SW-CMM v1.0 Published Software Acquisition (SA-CMM), CMMI V 1.3 Systems Engineering (SE-CMM), Integrated Product Development (IPD-CMM), Organizational Workforce Capability Development (People CMM) Developed
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-qualityProcess Technology
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• Does not require purchase of software or tools• Mean for process Improvement not process compliance
Why Maturity Models• Benchmarking• Improving• Institutionalizing• Good Practice catalogue
Continuous Representation: Process Areas by Category Category Process Areas Organizational Process Definition Process Organizational Process Focus Management Organizational Performance Management Organizational Process Performance Organizational Training Integrated Project Management Project Monitoring and Control Project Planning Project Quantitative Project Management Management Requirements Management Risk Management Supplier Agreement Management Product Integration Requirements Development Engineering Technical Solution Validation Verification Causal Analysis and Resolution Configuration Management Support Decision Analysis and Resolution Measurement and Analysis Process and Product Quality Assurance
Staged Representation: Process Areas by Maturity Level Level Focus Process Areas Quality Productivity5 Optimizing Continuous Causal Analysis and Resolution Process Organizational Performance Management Improvement4 Quantitatively Quantitative Organizational Process Performance Managed Management Quantitative Project Management3 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 Verification2 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 Risk1 Initial Rework
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 performance1
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 ElaborationsLegend Required Expected Informative
Problems and SolutionsProblems Solutions„CMMI forces us to do thingswe do not need.“„Employee have no freedom.Every single step isdescribed.“„We cannot maintainprocesses because of theirfast pace of changes“
Requirements Development Context -4 Develop Develop Analyze and Customer Product ValidateStakeholders’ Requirements Requirements Requirements Needs Validated Customer Validated Product, Product Component, and Requirements Interface Requirements
Requirements Development Context -5 Analyze and Validate Requirements Establish Establish a Analyze Operational Definition of Analyze Requirements Concepts Required Requirements to Achieve & Scenarios Functionality Balance Validate RequirementsCustomer, Product, Product Component, and Validated Interface Requirements Requirements
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 Manage Requirements Obtain Manage Obtain an Commitment RequirementsUnderstanding to of Changes RequirementsRequirements Maintain Bidirectional Traceability of Requirements Requirements Identify Inconsistencies Between Project Work and Traceability Matrix Requirements
Customer collaboration over contract negotiation --- Agile Manifesto ---
Requirements Management CMMI Goal Agile PracticesSG 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
Project Planning (PP)Purpose• Establish and maintain plans that define project activities.
Project Planning Context -1 Establish Planning Develop a Estimates Data Project Plan Obtain Project Commitment Plan to the Plan Relevant Stakeholders PMCSource: Introduction to CMMI, SEI, Accredited Course
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 LifecycleSource: Introduction to CMMI, SEI, Accredited Course
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 PlanSource: Introduction to CMMI, SEI, Accredited Course
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 StakeholdersSource: Introduction to CMMI, SEI, Accredited Course
“In preparing for battle I have always found thatplans are useless, but planning is indispensable.” --- Dwight David Eisenhower ---
Project Planning CMMI Goal Agile PracticesSG 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).
Project Planning CMMI Goal Agile PracticesSG 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
Project Planning CMMI Goal Agile PracticesSG 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
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 ContextSource: 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
Responding to change over following a plan --- Agile Manifesto ---
Project Monitoring and Control CMMI Goal Agile PracticesSG 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.
Project Monitoring and Control CMMI Goal Agile PracticesSG 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 projects deadlines. performance or Impediments collected and resolved results deviate by ScrumMaster significantly from the plan.
Measurement and Analysis (MA)Purpose• Develop and sustain a measurement capability that is used to support management information needs.
Measurement & Analysis Context Source: Introduction to CMMI, SEI, Accredited Course Align Measurement and Analysis Activities Specify Establish Data Specify Specify Collection Measurement AnalysisInformation 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
“Data is of course important in manufacturing, but I place the greatest emphasis on facts.” --- Taiichi Ohno ---
Measurements and Analysis CMMI Goal Agile PracticesSG 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)
Measurements and Analysis CMMI Goal Agile PracticesSG 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.
Configuration Management (CM)Purpose• Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.
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 Baselineversionscoming Iteration II Baselineabout) Iteration III Baseline Release I Baseline
Configuration Management ContextSource: 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
Working software over comprehensive documentation --- Principles behind the Agile Manifesto ---
Configuration Management CMMI Goal Agile PracticesSG 1 Baselines of identified Configuration Management has to be work products are supported by automated tools established. Code and important documents heldSG 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 themSG 3 Integrity of baselines is Limit number of development established and branches in order to avoid maintained integration issues
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 ContextSource: 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
Individuals and interactions over processes and tools --- Agile Manifesto ---
Process and Product Quality Assurance CMMI Goal Agile PracticesSG 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.
Process and Product Quality Assurance CMMI Goal Agile PracticesSG 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.
The Appraisal Method Appraisal Team Appraisal Requirements Findings, The Actual Recommendations Process Practice Lessons Learned/ Improvements Organization/ ProjectsOrganizational ProcessProcess Suite Deployment
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 react• Transparency• Concentrates on learning – inspect & adapt• 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 readingArticles:• 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 2008Reports:• CMMI for Development, Version 1.3, Technical Report, CMU/SEI- 2010-TR-033, November 2010Books:• 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 2011Christophe Debou Tomasz de Jastrzebiec WykowskiChristophe.Debou@kuglermaag.com Tomasz.Wykowski@procognita.com