Quest 2015 Webinar Series · Scrum and CMMI – Level 2! ! ! REQM REQM PP (plans, estimates) Green = Maturity Level 2 PAs Sprint 1 Sprint 2 Sprint 3 Backlog Planning REQM Requirements

Quest 2015 Webinar Series:

You Want to Use SCRUM, You Are Told To Use

CMMI-- How They Can Work Together Elegantly

FeaturingNeil Potter

ofThe Process Group

WEBINAR SERIESWEBINA SERIES

presents the

WEBINAR SERIESwww.qaiQUEST.org/2015

1 !

THE

GROUPPROCESS

Version 3.1!www.processgroup.com!© Copyright 2004-2014 The Process Group. All rights reserved.!

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 [email protected] www.processgroup.com

2 !

THE

GROUPPROCESS


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

3 !

THE

GROUPPROCESS


Summary of Scrum P

rodu

ct B

ackl

og

Ana

lysi

s D

esig

n C

ode

Test

Rev

iew

Bac

klog

S

prin

t Pla

nnin

g

Spr

int R

etro

spec

tive

Ana

lysi

s

1 da

y

Potentially Deliver Potentially Deliver

2-4 week Sprint

1 da

y

2-4 week Sprint

Rel

ease

Pla

nnin

g S

prin

t Pla

nnin

g

Spr

int R

evie

w

Ana

lysi

s D

esig

n C

ode

Test

Spr

int R

etro

spec

tive

Spr

int R

evie

w

Rev

iew

Bac

klog

S

prin

t Pla

nnin

g

Team defined

steps

4 !

THE

GROUPPROCESS


Summary of CMMI (Level 2) v1.3

3 Defined

2 Managed

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)

1 Initial

Process Areas Level Focus

Risk Rework

Quality Productivity

•  Allocate time for work •  Plan work •  Manage change •  Know status / quality

Causal Analysis and Resolution Organizational Performance Management 5 Optimizing

4 Quantitatively Managed

Organizational Process Performance Quantitative Project Management

5 !

THE

GROUPPROCESS


Summary of CMMI (Level 3) v1.3

3 Defined

2 Managed

1 Initial

Process Areas Level Focus

Risk Rework

Quality Productivity

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)

Causal Analysis and Resolution Organizational Performance Management 5 Optimizing

4 Quantitatively Managed

Organizational Process Performance Quantitative Project Management •  Use / refine standard

org. practices •  Estimate with data •  Coordinate projects •  Manage risk •  Systematic decisions •  Elicit requirements •  Design •  Defect removal •  Learn and improve

6 !

THE

GROUPPROCESS


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 on SEI Intro CMM-SW class!

7 !

THE

GROUPPROCESS



•  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

IN OUT


Chunks of work (increment, sprint, phase)

8 !

THE

GROUPPROCESS



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


9 !

THE

GROUPPROCESS


Similarities and Differences

•  Some requirements •  Some design • Coding •  Some test •  Some lessons learned

• No

• Most Requirements Management • Most Project Planning • Most Project Monitoring/Control • Most Measurement Analysis (effort

and progress)

In Scrum? Level 3 coverage - very dependent on how YOU define the phases

Approx. 47% coverage of Level 2

10 !

THE

GROUPPROCESS


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”)

11 !

THE

GROUPPROCESS


Maturity Level 2 and Scrum Comparison

12 !

THE

GROUPPROCESS


Scrum and CMMI – Level 2

ò ò ò REQM REQM REQM

PP (plans, estimates)

Green = Maturity Level 2 PAs

Sprint 1 Sprint 2 Sprint 3 Planning Backlog

REQM Requirements Design Code Peer Review/Test Integrate Test Release

PMC (progress tracking and corrective action) MA (objectives & measures) CM (baselines & versions) SAM (supplier selection & management) PPQA (process & product check)

Requirements Design Code Peer Review/Test Integrate Test Release

Requirements Design Code Peer Review/Test Integrate Test Release

13 !

THE

GROUPPROCESS


REQM CMMI Practice Scrum Practice SP 1.1 Develop an understanding with

the requirements providers on the meaning of the requirements.

• Review of Product Backlog (requirements) with Product Owner and team.

SP 1.2 Obtain commitment to the requirements from the project participants.

• Release Planning and Sprint Planning sessions that seek team member commitment.

SP 1.3 Manage changes to the requirements as they evolve during the project.

• Add requirements changes to the Product Backlog. • Manage changes in the next Sprint Planning

meeting. SP 1.5 Identify inconsistencies between

the project plans and work products and the requirements.

• 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.

Requirements Management

No traceability in Scrum [SP 1.4 Maintain bidirectional traceability among the requirements and work products]

14 !

THE

GROUPPROCESS


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.

• The standard tasks used in a Scrum process combined with specific project tasks (Sprint Backlog).

SP 1.2 Establish and maintain estimates of the attributes of the work products and tasks.

• Story Points, used to estimate the difficulty (or relative size) of a Story (requirement).

SP 1.3 Define the project life-cycle phases upon which to scope the planning effort.

• The Scrum process.

SP 1.4 Estimate the project effort and cost for the work products and tasks based on estimation rationale.

• Scrum Ideal Time estimate (similar to billable hours or Full-time Equivalents).

SP 2.1 Establish and maintain the project’s budget and schedule.

• Scrum estimates (in Ideal Time). • Estimates of what work will be in each release. • Release Plan / Sprint Backlog. • Project Taskboard.

SP 2.4 Plan for necessary resources to perform the project.

• Scrum estimates in Ideal Time • Release Plan, Sprint Backlog and assignments.

SP 2.6 Plan the involvement of identified stakeholders.

• 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.]

SP 3.2 Reconcile the project plan to reflect available and estimated resources.

• Sprint Planning meeting. • Daily Scrum meeting.

15 !

THE

GROUPPROCESS


Project Monitoring and Control

No risk assessment / tracking in Scrum [SP 1.3 Monitor risks against those identified in the project plan]

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 that need verification.

SP 1.2 Monitor commitments against those identified in the project plan.

• 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.

SP 1.6 Periodically review the project's progress, performance, and issues.

• Daily Scrum meetin g . • Sprint Review meeting. • Retrospectives.

SP 2.3 Manage corrective actions to closure.

• Tracking of actions from: Daily Scrum meetin g . Sprint Review meeting.

• [Note: This assumes that teams will track (and not lose) actions.]

16 !

THE

GROUPPROCESS


SP 1.2 Specify measures to address the measurement objectives.

• 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.”]

SP 1.4 Specify how measurement data will be analyzed and reporte d .

• The Scrum process does describe the purpose and use the Sprint and Release Burndown charts .

• [Note: CMMI expects clearly defined analysis]. SP 2.1 Obtain specified

measurement data. • Daily Scrum meeting where Sprint and Release

Burndown data are collected. SP 2.2 Analyze and interpret

measurement data. • Daily Scrum meeting where Sprint and Release

Burndown data are analyzed. SP 2.4 Report results of

measurement and analysis activities to all relevant stakeholders.

• Daily Scrum meeting where Sprint and Release Burndown charts are reviewed.

• [Note: Not all interested stakeholders will necessarily be at the Scrum meeting.]

Measurement and Analysis

17 !

THE

GROUPPROCESS


How About the Other Components of Level 2?

18 !

THE

GROUPPROCESS



•  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.

19 !

THE

GROUPPROCESS


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."

Pro

duct

Bac

klog

Ana

lysi

s D

esig

n C

ode

Test

Rev

iew

Bac

klog

S

prin

t Pla

nnin

g

Spr

int R

etro

spec

tive

Rel

ease

Pla

nnin

g S

prin

t Pla

nnin

g

Spr

int R

evie

w

Ana

lysi

s D

esig

n C

ode

Test

Spr

int R

etro

spec

tive

Spr

int R

evie

w

Rev

iew

Bac

klog

S

prin

t Pla

nnin

g

20 !

THE

GROUPPROCESS


Adding Level 3 Engineering Practices + Sprint composi-on

21 !

THE

GROUPPROCESS


Scrum and CMMI – Level 2+3


PP / IPM (plans, estimates)

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)

Green = Maturity Level 2 PAs Blue = Maturity Level 3 PAs


REQM / RD 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


22 !

THE

GROUPPROCESS


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

23 !

THE

GROUPPROCESS


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]

24 !

THE

GROUPPROCESS


Requirements (cont’d.) Using Use Cases for Elicitation [RD SG1], Definition [RD SG2]

• 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

Actor Actions System Responses

1. Select Withdrawal action.3. Select desired account.5. Enter desired amount.7. Remove cash from dispenser.

2. Display user’s accounts.4. Ask user to enter amount.6. If amount is okay, dispense

cash and debit account.

Normal flow:

25 !

THE

GROUPPROCESS


Requirements Example Analysis [RD SG3]

■  Determining Requirements Priorities

■  Using Models to Clarify Requirements

■  Reviewing and Inspecting Requirements Documents

■  Generating Test Cases

■  Reducing the Expectation Gap Through Prototyping

Find ambiguities and errors in the requirements definition.

Error

Error

Requirement Test Case ~~~~~~~~~ ~~~~~~~ ~~~~~~~~~ ~~~~~~~ ~~~~~~~~~ ~~~~~~~ ~~~~~~~~~ ~~~~~~~ ~~~~~~~~~ ~~~~~~~

26 !

THE

GROUPPROCESS












27 !

THE

GROUPPROCESS


Engineering the System •  Design:

– Architecture + design notes

•  Peer-reviews to find defects

•  Check interfaces for errors

•  Component test •  System test •  Analyze the results:

– e.g., defect density, pass/escape rate, cause

28 !

THE

GROUPPROCESS


Sprint Composition Allocating Time for Engineering

90%

Ana

lysi

s, 1

0% C

ode

80%

Ana

lysi

s, 2

0% C

ode

70%

Ana

lysi

s, 3

0% C

ode

60%

Ana

lysi

s, 4

0% C

ode

50%

Ana

lysi

s, 5

0% C

ode

• 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

• 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

Example %’s

29 !

THE

GROUPPROCESS


Adding Level 3 Management Practices

Release planning, sprint planning and daily standups

30 !

THE

GROUPPROCESS












31 !

THE

GROUPPROCESS


Planning Using Best Practices and Data Use existing assets [IPM SG1]

Organization's Measurement

Repository Team Rules

and Guidelines

Organization's Set of Standard

Processes

Lifecycle Model

Descriptions

Tailoring Guidelines

Organization's Process Asset

Library

Project A’s Process

The Organization’s Process Assets

Project A Plan

Project B’s Process

Project B Plan

Project C’s Process

Project C Plan

Work Environment

Standards

Refine

Use

[IPM = Integrated Project Management]

32 !

THE

GROUPPROCESS


Planning - Dependencies & Stakeholders Manage [IPM SG1], Dependencies [IPM SG2]

Package"& Ship"

"Jan "Feb "Mar "Apr "May "Jun"

Ship Date"

Integrate"& Test"

Deliverable 8"

Deliverable 7"

Deliverable 6"Deliverable 5"Deliverable 4"Deliverable 3"

Deliverable 2"

Deliverable 1"

Sprint start Sprint end

Program manager or Scrum of Scrums

Dependencies Deliverable from a Scrum team

33 !

THE

GROUPPROCESS


Planning Using Risk Management Risk [RSKM SG2+3]

Keep track of the top 20% or top 2-3 risks

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!

Delay next project + no usage of demo!

9! 6! 54! Prototype of UI!!Use Case style requirements!

Incremental release!Limit distribution!

Lois!

Requirements may change late in the cycle!

New defects! 7! 7! 49! Prototype top 10 requirements!

Limit distribution!

Joe!

Database S/W might be late!

Revenue delay!

4! 8! 32! Check with supplier!

Help supplier! Pete!

Database expert might leave!

Schedule delay!

2! 10! 20! Make sure Jim is happy!

Earmark Fred! Jane!

Total! 327!

34 !

THE

GROUPPROCESS


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]

35 !

THE

GROUPPROCESS



36 !

THE

GROUPPROCESS












37 !

THE

GROUPPROCESS


Collecting and Using Retrospective Data (Improve [OPF], update assets [OPD], train [OT])


Training needs Retrospective / progress / quality data

Retrospective / progress / quality data

Retrospective / progress / quality data

Organize

•  Improve the process •  Add tailoring options •  Improve tools •  Train

38 !

THE

GROUPPROCESS


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).

39 !

THE

GROUPPROCESS


Q & A

Neil Potter

The Process Group [email protected] www.processgroup.com

40 !

THE

GROUPPROCESS


Appendix

41 !

THE

GROUPPROCESS


Waterfall / Scrum

processgroup.com/monthlytidbits.html#tidbit12

42 !

THE

GROUPPROCESS


Generic Practices? •  Approximately half of the Level 2 GPs of REQM, PP, PMC and MA

are implemented by Scrum. GP 2.2 Establish and maintain the plan

for performing the REQM/PP/PMC/MA process.

• The Scrum lifecycle definition and the milestones to perform Scrum.

GP 2.3 Provide adequate resources for performing the REQM/PP/PMC/MA process, developing the work products, and providing the services of the process.

• The resources and schedule time allocated to perform Scrum planning, monitoring and requirements activities.

GP 2.4 Assign responsibility and authority for performing the process, developing the work products, and providing the services of the REQM/PP/PMC/MA process.

• The resource assignments allocated to perform Scrum planning, monitoring and requirements activities.

GP 2.6 Place designated work products of the REQM/PP/PMC/MA process under appropriate levels of control.

• [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.]

GP 2.8 Monitor and control the REQM/PP/PMC/MA process against the plan for performing the process and take appropriate corrective action.

• Scrum Master monitoring that the steps of Scrum are followed.

© Copyright 2004-2011 The Process Group. All rights reserved.! 43 !

THE

GROUPPROCESS

PGV1!www.processgroup.com!

Example Requirements Format (RD SG 2) #1: Business

Requirements

Vision and Scope

#2: User Requirements

Use Cases

#3:Functional Requirements

Requirements Information

Constraints

Other Nonfunctional Requirements

Business Rules

Quality Attributes

System Requirements

Based on In Search of Excellent Requirements, Copyright © 2000 by Karl E. Wiegers. Modifications & additions Copyright © 2002 The Process Group

44 !

THE

GROUPPROCESS


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/

45 !

THE

GROUPPROCESS


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.

✔

✔ ✔

✔

✔ ✔

✔

46 !

THE

GROUPPROCESS


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"