Ride and drive anythingExtreme conditionsHigh pressureDo impossible
1. 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
2. ABOUT US
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.firstname.lastname@example.org
4. Christophe Debou Background
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
6. Tomasz de Jastrzębiec Wykowski
7. WHAT IS AGILE?
8. WHAT IS CMMI®?
9. Once upon a time ….
10. 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
11. 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
12. STRUCTURESAND CONTENTS
13. 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
14. 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
15. 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
16. 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“
17. CMMI is a journey to excellence
18. CMMI Level 2 Process AreasRequirements Management Project Planning Project Monitoring and Control Configuration Management Measurement and AnalysisProcess and Product Quality Assurance
20. Requirements Development (RD)Purpose• Produce and analyze customer, product, and product component requirements.
21. Requirements Development Context -1 Develop Develop Analyze and Customer Product ValidateStakeholders’ Requirements Requirements Requirements Needs Validated Customer Validated Product, Product Component, and Requirements Interface Requirements Source: Introduction to CMMI, SEI, Accredited Course
22. 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 RequirementsCustomer, Product, Product Component, and Validated Interface Requirements Requirements
23. 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.
24. Requirements Management ContextSource: 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
25. Customer collaboration over contract negotiation --- Agile Manifesto ---
26. 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
28. 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 PMCSource: Introduction to CMMI, SEI, Accredited Course
29. 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
30. 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
31. 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
32. “In preparing for battle I have always found thatplans are useless, but planning is indispensable.” --- Dwight David Eisenhower ---
33. 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).
34. 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
35. 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
36. PROJECTMONITORINGAND CONTROL
37. 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.
38. 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
39. Responding to change over following a plan --- Agile Manifesto ---
40. 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.
41. 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.
42. MEASUREMENTAND ANALYSIS
43. Measurement and Analysis (MA)Purpose• Develop and sustain a measurement capability that is used to support management information needs.
44. 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
45. “Data is of course important in manufacturing, but I place the greatest emphasis on facts.” --- Taiichi Ohno ---
46. 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)
47. 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.
49. Configuration Management (CM)Purpose• Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.
50. 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
51. 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
52. Working software over comprehensive documentation --- Principles behind the Agile Manifesto ---
53. 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
54. PROCESS ANDPRODUCT QUALITYASSURANCE
55. Process and Product Quality Assurance (PPQA)Purpose• Provide staff and management with objective insight into processes and associated work products.
56. 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
57. Individuals and interactions over processes and tools --- Agile Manifesto ---
58. 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.
59. 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.
61. 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
62. 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
63. 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
64. 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
65. 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
66. 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