Quest 2015 Webinar Series: - PDF Free Download

presents the Quest 2015 Webinar Series: You Want to Use SCRUM, You Are Told To Use CMMI-- How They Can Work Together Elegantly WEBINAR SERIES WEBINAR SERIES www.qaiquest.org/2015 Featuring Neil Potter of The Process Group

You Want to Use Scrum, You are Told to Use CMMI How They can Work Together Elegantly and Both Provide Benefit Neil Potter The Process Group neil@processgroup.com www.processgroup.com 1!

Agenda Summary of Scrum and CMMI Approach Maturity Level 2 and Scrum Comparison How About Other Components of Level 2? Adding Level 3 Management and Engineering Practices Requirements / backlog Release planning, sprint planning and daily standups Sprint composition How About the Other Components of Level 3? Summary 2!

Summary of Scrum Team defined steps Potentially Deliver Potentially Deliver 1 day 1 day Product Backlog Release Planning Sprint Planning Analysis Design Code Test Sprint Review Sprint Retrospective Review Backlog Sprint Planning Analysis Design Code Test Sprint Review Sprint Retrospective Review Backlog Sprint Planning Analysis 2-4 week Sprint 2-4 week Sprint 3!

Level 5 Optimizing Summary of CMMI (Level 2) v1.3 Focus Process Areas Causal Analysis and Resolution Organizational Performance Management Quality Productivity 4 Quantitatively Managed 3 Defined Allocate time for work Plan work Manage change Know status / quality 2 Managed 1 Initial Organizational Process Performance Quantitative Project Management Integrated Project Management (IPM) Risk Management (RSKM) Decision Analysis and Resolution (DAR) Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Requirements Management (REQM) Project Planning (PP) Project Monitoring and Control (PMC) Measurement and Analysis (MA) Configuration Management (CM) Process and Product Quality Assurance (PPQA) Supplier Agreement Management (SAM) Risk Rework 4!

Level 5 Optimizing Summary of CMMI (Level 3) v1.3 Focus Process Areas Causal Analysis and Resolution Organizational Performance Management Quality Productivity 4 Quantitatively Managed Use / refine standard org. practices Estimate with data Coordinate projects Manage risk Systematic decisions Elicit requirements Design 3 Defined 2 Managed Defect removal Learn and improve 1 Initial Organizational Process Performance Quantitative Project Management Integrated Project Management (IPM) Risk Management (RSKM) Decision Analysis and Resolution (DAR) Requirements Development (RD) Technical Solution (TS) Product Integration (PI) Verification (VER) Validation (VAL) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Training (OT) Requirements Management (REQM) Project Planning (PP) Project Monitoring and Control (PMC) Measurement and Analysis (MA) Configuration Management (CM) Process and Product Quality Assurance (PPQA) Supplier Agreement Management (SAM) Risk Rework 5!

Visibility Into the Process Level 1 IN OUT Process is an amorphous entity Visibility into the project s process is limited Difficult to establish the status of the project s progress and activities Based Copyright on SEI 2004-2014 Intro CMM-SW The Process class! Group. All rights reserved.! 6!

Visibility Into the Process Level 2 Chunks of work (increment, sprint, phase) IN OUT Customer requirements and work products are managed Basic project management practices have been established Project management practices allow visibility into the project on defined occasions Management reacts to problems as they occur Based Copyright on SEI 2004-2014 Intro CMM-SW The Process class! Group. All rights reserved.! 7!

Visibility Into the Process Level 3 IN OUT Tasks in the project s defined process are visible Accurate and rapid status updates are available Management proactively prepares for risks that may arise Based Copyright on SEI 2004-2014 Intro CMM-SW The Process class! Group. All rights reserved.! 8!

Similarities and Differences No In Scrum? Some requirements Some design Coding Some test Some lessons learned Level 3 coverage - very dependent on how YOU define the phases Approx. 47% coverage of Level 2 Most Requirements Management Most Project Planning Most Project Monitoring/Control Most Measurement Analysis (effort and progress) 9!

Approach: Run the Business! Identify problem areas Add practices to address them Focus on high-risk areas of project, not low risk Source does not matter:» WWW» PMI» CMMI» ITIL»... Goal = achieve desired result (not documentation ) 10!

Maturity Level 2 and Scrum Comparison 11!

Scrum and CMMI Level 2 PMC (progress tracking and corrective action) MA (objectives & measures) CM (baselines & versions) SAM (supplier selection & management) PPQA (process & product check) Backlog Planning REQM REQM REQM ò ò ò Sprint 1 Sprint 2 Sprint 3 REQM PP (plans, estimates) Green = Maturity Level 2 PAs Requirements Design Code Peer Review/Test Integrate Test Release Requirements Design Code Peer Review/Test Integrate Test Release Requirements Design Code Peer Review/Test Integrate Test Release 12!

Requirements Management REQM CMMI Practice Scrum Practice SP 1.1 Develop an understanding with the requirements providers on the meaning of the requirements. SP 1.2 Obtain commitment to the requirements from the project participants. SP 1.3 Manage changes to the requirements as they evolve during the project. SP 1.5 Identify inconsistencies between the project plans and work products and the requirements. Review of Product Backlog (requirements) with Product Owner and team. Release Planning and Sprint Planning sessions that seek team member commitment. Add requirements changes to the Product Backlog. Manage changes in the next Sprint Planning meeting. Daily Standup Meeting to identify issues. Release planning and Sprint Planning sessions to address inconsistencies. Sprint Burndown chart that tracks effort remaining. Release Burndown chart that tracks story points that have been completed. This shows how much of the product functionality is left to complete. No traceability in Scrum [SP 1.4 Maintain bidirectional traceability among the requirements and work products] 13!

Project Planning PP CMMI Practice Scrum Practice SP 1.1 Establish a top-level work breakdown structure (WBS) to estimate the scope of the project. Backlog). SP 1.2 SP 1.3 SP 1.4 SP 2.1 SP 2.4 SP 2.6 SP 3.2 Establish and maintain estimates of the attributes of the work products and tasks. Define the project life-cycle phases upon which to scope the planning effort. Estimate the project effort and cost for the work products and tasks based on estimation rationale. Establish and maintain the project s budget and schedule. Plan for necessary resources to perform the project. Plan the involvement of identified stakeholders. Reconcile the project plan to reflect available and estimated resources. The standard tasks used in a Scrum process combined with specific project tasks (Sprint Story Points, used to estimate the difficulty (or relative size) of a Story (requirement). The Scrum process. Scrum Ideal Time estimate (similar to billable hours or Full-time Equivalents). Scrum estimates (in Ideal Time). Estimates of what work will be in each release. Release Plan / Sprint Backlog. Project Taskboard. Scrum estimates in Ideal Time Release Plan, Sprint Backlog and assignments. Scrum process roles (including team, Scrum Master, Product Owner). [Note: The stakeholders listed in Scrum might not be the complete list of stakeholders for the project, e.g., customers, other impacted teams.] Sprint Planning meeting. Daily Scrum meeting. 14!

Project Monitoring and Control PMC CMMI Practice Scrum Practice SP 1.1 Monitor the actual values of the project planning parameters against the project plan. Sprint Burndown chart that tracks effort remaining. Release Burndown chart that tracks completed story points. This shows how much of the product functionality is left to complete. Project Task Board used to track stories (requirements) that are done, in progress, or ones SP 1.2 Monitor commitments against those identified in the project plan. SP 1.6 Periodically review the project's progress, performance, and issues. SP 2.3 Manage corrective actions to closure. No risk assessment / tracking in Scrum [SP 1.3 Monitor risks against those identified in the project plan] that need verification. Discussions on team commitments at the: Daily Scrum meeting. Sprint Review meeting. Sprint Burndown chart that tracks effort remaining. Release Burndown chart that tracks Story Points that have been completed. This shows how much of the product functionality is left to complete. Daily Scrum meeting. Sprint Review meeting. Retrospectives. Tracking of actions from: Daily Scrum meeting. Sprint Review meeting. [Note: This assumes that teams will track (and not lose) actions.] 15!

Measurement and Analysis SP 1.2 Specify measures to address the measurement objectives. SP 1.4 Specify how measurement data will be analyzed and reported. SP 2.1 Obtain specified measurement data. SP 2.2 Analyze and interpret measurement data. SP 2.4 Report results of measurement and analysis activities to all relevant stakeholders. Sprint Burndown chart that tracks effort remaining. Release Burndown chart that tracks story points that have been completed. This shows how much of the product functionality is left to complete. [Note: These two measures could be used to track the progress of declared project objectives, such as On time, and On budget. ] The Scrum process does describe the purpose and use the Sprint and Release Burndown charts. [Note: CMMI expects clearly defined analysis]. Daily Scrum meeting where Sprint and Release Burndown data are collected. Daily Scrum meeting where Sprint and Release Burndown data are analyzed. Daily Scrum meeting where Sprint and Release Burndown charts are reviewed. [Note: Not all interested stakeholders will necessarily be at the Scrum meeting.] 16!

How About the Other Components of Level 2? 17!

How About the Other Components of Level 2? Configuration Management (CM): CM is not specifically called out in Scrum. However, in an Agile environment it is pretty easy to add a layer of CM to protect your work. Product and Process Quality Assurance (PPQA): Some basic PPQA activities are being done naturally when the Scrum Master checks that the Scrum process is being followed. Scrum does not specifically call out a level of objective process and product check, nor does it state that particular standards or processes should be defined and used. Supplier Agreement Management (SAM): Not included in Scrum. 18!

Adding Gates and Governance Establish gates at the end of each, or several, sprints:! Negotiate upfront what will be available at the gates (some design, some code, some tests)." Work with process QA staff early so that there is agreement as to what will be audited and when." Product Backlog Release Planning Sprint Planning Analysis Design Code Test Sprint Review Sprint Retrospective Review Backlog Sprint Planning Analysis Design Code Test Sprint Review Sprint Retrospective Review Backlog Sprint Planning 19!

Adding Level 3 Engineering Practices + Sprint composi-on 20!

Scrum and CMMI Level 2+3 PMC (progress tracking and corrective action) MA (objectives & measures) CM (baselines & versions) SAM (supplier selection & management) PPQA (process & product check) IPM (planning with assets, data, program-level tracking) RSKM (risk management) OT (planned training program) OPF (process improvement focus) OPD (process asset creation / update) DAR (tradeoffs using criteria) Backlog Planning REQM REQM REQM ò ò ò Sprint 1 Sprint 2 Sprint 3 REQM / RD PP / IPM (plans, estimates) Green = Maturity Level 2 PAs Blue = Maturity Level 3 PAs Requirements (RD) Design (TS) Code (TS) Peer Review/Test (VER) Integrate (PI) Test (VAL) Release Requirements (RD) Design (TS) Code (TS) Peer Review/Test (VER) Integrate (PI) Test (VAL) Release Requirements (RD) Design (TS) Code (TS) Peer Review/Test (VER) Integrate (PI) Test (VAL) Release 21!

Requirements / Backlog Priority User Story Estimate (Points) As an account owner, I want to withdraw cash As an account owner, I want to deposit cash As an account owner, I want to deposit check(s) As an account owner, I want to deposit foreign check(s) Typical format: As a <user>, desired action 1-liners can be ambiguous and lead the developer to guess 22!

Requirements Example: Using Use Cases for Elicitation [RD SG1], Definition [RD SG2] Name: Withdraw Cash Actor: Account Owner Preconditions: 1. The Account Owner is logged in to the ATM. 2. The Account Owner has at least 1 account with a positive balance. 3. The ATM contains cash. Postconditions: 1. The requested amount of cash has been dispensed. 2. The account balance is reduced by the amount withdrawn plus any fees. 3. The ATM cash balance is reduced by the amount withdrawn. Priority: High [SG = Specific Goal] 23!

Requirements (cont d.) Using Use Cases for Elicitation [RD SG1], Definition [RD SG2] Normal flow: Actor Actions 1. Select Withdrawal action. 3. Select desired account. 5. Enter desired amount. 7. Remove cash from dispenser. System Responses 2. Display user s accounts. 4. Ask user to enter amount. 6. If amount is okay, dispense cash and debit account. Alternative Flow: Step 4: display list of common amounts, let user select one Exceptions: Step 6: amount is not a multiple of $20.00 Step 6: amount exceeds $400 Step 6: amount exceeds account balance Step 6: amount exceeds cash available in ATM 24!

Requirements Example Analysis [RD SG3] Find ambiguities and errors in the requirements definition. Determining Requirements Priorities Using Models to Clarify Requirements Reviewing and Inspecting Requirements Documents Generating Test Cases Reducing the Expectation Gap Through Prototyping Requirement Test Case ~~~~~~~~~ ~~~~~~~ ~~~~~~~~~ ~~~~~~~ ~~~~~~~~~ ~~~~~~~ ~~~~~~~~~ ~~~~~~~ ~~~~~~~~~ ~~~~~~~ Error Error 25!

Design: Architecture + design notes Peer-reviews to find defects Check interfaces for errors Component test System test Analyze the results: Engineering the System e.g., defect density, pass/escape rate, cause 27!

Sprint Composition Allocating Time for Engineering The intent of Scrum is to produce a potentially shippable product every sprint. This could be very small in earlier sprints, and larger is later sprints. Tasks such as, User story analysis and architecture, can be added to the first few sprints 90% Analysis, 10% Code Example % s Final testing and odds-and-ends will likely end up on the backlog and be grouped into a last few sprints. Sprint: 1 2 3 4 5 80% Analysis, 20% Code 70% Analysis, 30% Code 60% Analysis, 40% Code 50% Analysis, 50% Code 28!

Adding Level 3 Management Practices Release planning, sprint planning and daily standups 29!

Planning Using Best Practices and Data Use existing assets [IPM SG1] The Organization s Process Assets Organization's Set of Standard Processes Lifecycle Model Descriptions Work Environment Standards Team Rules and Guidelines Tailoring Guidelines Organization's Process Asset Library Organization's Measurement Repository Use Project A s Process Project A Plan Project B s Process Project B Plan Refine Project C s Process Project C Plan [IPM = Integrated Project Management] 31!

Planning - Dependencies & Stakeholders Manage [IPM SG1], Dependencies [IPM SG2] Dependencies Deliverable from a Scrum team Program manager or Scrum of Scrums Ship Date" Sprint start Sprint end Deliverable 2" Deliverable 8" Package" & Ship" Deliverable 1" Deliverable 7" Integrate" & Test" Deliverable 3" Deliverable 4" Deliverable 5" Deliverable 6" "Jan "Feb "Mar "Apr "May "Jun" 32!

Planning Using Risk Management Risk [RSKM SG2+3] Action items will likely be more numerous and detailed" Status of action items" Risk Item! (Potential Future Problem)! Consequence! Lkli.! Imp.! Pri.! Action- Likelihood! Action-Impact! Who! When! Status! New operating system might not be stable! Unable to ship! 10! 10! 100! Test OS more! Identify 2nd OS! Joe! System communication problems with XYZ! Feature x unavailable! 8! 9! 72! Develop sys interface doc! Add replan milestone! Kim! We may not have the requirements right! Requirements may change late in the cycle! Database S/W might be late! Database expert might leave! Delay next project + no usage of demo! 9! 6! 54! Prototype of UI!! Use Case style requirements! New defects! 7! 7! 49! Prototype top 10 requirements! Revenue delay! Schedule delay! 4! 8! 32! Check with supplier! 2! 10! 20! Make sure Jim is happy! Total! 327! Incremental release! Limit distribution! Limit distribution! Help supplier! Earmark Fred! Lois! Joe! Pete! Jane! Keep track of the top 20% or top 2-3 risks 33!

Daily Standups Risk [RSKM SG2+3] + Manage [IPM SG2] Duration: 5-15 mins per day. What: What did you do since the last meeting? What will you do before the next meeting? What is impacting progress (impediments)? What risks (potential problems) do you see? What is state of each task on the Critical Path (longest calendar path)? [IPM = Integrated Project Management] 34!

How About the Other Components of Level 3? 35!

Collecting and Using Retrospective Data (Improve [OPF], update assets [OPD], train [OT]) Backlog Planning Sprint 1 Sprint 2 Sprint 3 Training needs Retrospective / progress / quality data Retrospective / progress / quality data Retrospective / progress / quality data Organize Improve the process Add tailoring options Improve tools Train 37!

Summary Scrum/Agile is a framework. Scrum is a good implementation for many of the practices in Level 2. The source of new practices is not important: Realize that they do exist, and have done for decades. Goals and problems can be addressed by adding practices to Scrum/Agile. Care needs to be taken to: a) keep the new practice small and easy to use. b) refine the practice over time. c) maintain the intent of Agile (early feedback, visibility). 38!

Q & A Neil Potter The Process Group neil@processgroup.com www.processgroup.com 39!

Appendix 40!

Waterfall / Scrum processgroup.com/monthlytidbits.html#tidbit12 41!

Generic Practices? Approximately half of the Level 2 GPs of REQM, PP, PMC and MA are implemented by Scrum. GP 2.2 GP 2.3 GP 2.4 GP 2.6 GP 2.8 Establish and maintain the plan for performing the REQM/PP/PMC/MA process. Provide adequate resources for performing the REQM/PP/PMC/MA process, developing the work products, and providing the services of the process. Assign responsibility and authority for performing the process, developing the work products, and providing the services of the REQM/PP/PMC/MA process. Place designated work products of the REQM/PP/PMC/MA process under appropriate levels of control. Monitor and control the REQM/PP/PMC/MA process against the plan for performing the process and take appropriate corrective action. The Scrum lifecycle definition and the milestones to perform Scrum. The resources and schedule time allocated to perform Scrum planning, monitoring and requirements activities. The resource assignments allocated to perform Scrum planning, monitoring and requirements activities. [Note: Scrum does not explicitly require CM to be done. However, this can be performed using a digital camera, backed up drive, or share drive with versioning and controls turned on.] Scrum Master monitoring that the steps of Scrum are followed. 42!

#1: Business Requirements Example Requirements Format (RD SG 2) Vision and Scope #2: User Requirements Quality Attributes System Requirements Business Rules Use Cases #3:Functional Requirements Requirements Information Other Nonfunctional Requirements Constraints Based on In Search of Excellent Requirements, Copyright 2000 by Karl E. Wiegers. Modifications & additions Copyright 2002 The Process Group Copyright 2004-2011 The Process Group. All rights reserved.! PGV1! 43!

Agile Principles - 1 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. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. CMMI compatible Source: http://agilemanifesto.org/ 44!

Agile Principles - 2 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. 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. 45!

References 1. Implementing Scrum (Agile) and CMMI Together. Process Group Post newsletter, March 2009." processgroup.com/pgpostmar09.pdf" 2. Adding Practices to Scrum to Achieve Your Goals (and comparison with CMMI Level 3)" processgroup.com/pgpostapr2013.pdf" 3. Scrum definition" scrumalliance.org" 4. CMMI: Guidelines for Process Integration and Product Improvement." cmmiinstitute.com/assets/reports/10tr033.pdf" 5. Scrum and CMMI Level 5: The Magic Potion for Code Warriors, by Jeff Sutherland, Carsten Ruseng Jakobsen, and Kent Johnson." http://jeffsutherland.com/scrum/sutherlandscrumcmmihicss2008.pdf 6. Potter, N., Sakry, M., Making Process Improvement Work - A Concise Action Guide for Software Managers and Practitioners, Addison-Wesley, 2002." processgroup.com/book.html" 46!