The Secrets of Cmmi for Small Companies Webinar Speaker Slides1

7/28/2019 The Secrets of Cmmi for Small Companies Webinar Speaker Slides1

1/32

Copyright 2007 Broadsword Solutions Corporation

agileCMMIsm

Secrets ofCMMI(for Small Agile Organizations)

Jeff DaltonPresident

CMMI Lead Appraiser andCMMI Instructor


2/32


Where to find this version of the presentation . . .

For a copy of this presentation, and to receiveexcerpts from Jeffs book, Agile CMMI,simply email:

[email protected]


3/32


If you only remember one thing . . .

Benefit

Effor

t&C

ost

Scope = Cost. Agile methods are well suited to control process scope

JENTMsm= Courage to stop

$


4/32


Tectonic Shifts

Information Engineering (IE)(1991) traditional approach

Deregulation initiatives (1998),

corporate mergers (1999), and

other market drivers

XP (1999), Scrum (2001), Crystal (2001),

FDD (2001), and other agile methods

Waterfall

methodology

House Blends of

agile methodologies


5/32


Components of an SDPAll need representation, not all need to be complex

SDPProcess

Essences

and CorePrinciples

Roles andResponsibilities

Glossaryof Terms

Process

Flows

(Swimlanes)

ProcessDefinitions

StandardWork

Instructions

Templatesand

Examples

CommunicationMaterials

Training

Materials

Standards

andGuidelines


6/32


Conflicting or Collaborative?

Agile implies:

Iterative

Incremental

Action based

Team agreements

Rapid change

Scope shrinks to meet deadlinesDocument-lite

Assume a low level of constantre-work

Trust

CMMI implies:

Procedural

Extensive planning

Deliverable based

Hierarchical governance

Careful change

Budget grows to meet ScopeDocument-heavy

Avoid re-work through planningand monitoring

Governance Layers

Who (besides the CMMI zealots and the XP police) says we have to play by these rules?


7/32


CMMI and Agile often perceived as didactic

People that advocate Agile tendto disdain structure

People who support CMMI tendto want to avoidchaos and risk

. . . so it follows that most advocates of CMMI focus onplanning and that most advocates of Agile focus oniterations and failing fast.

We dont have to choose!


8/32


A Few Myths about Agile and CMMI

No documentation is required Throw me a Red Bull!

Design on the fly results in

a better product

Customers are at everymeeting making decisionswith the team

No need to record decisions-we just have a meeting

CMMI is incompatible withAgile

Appraisals or audits are notvaluable

We can only do CMMI if we

focus on developing documents,

and reports, and we hire an

expensive consultant

CMMI is something that we

implement

CMMI only applies to large ,monolithic companies

CMMI (and all process) will double

our workload and slow us down

Its designed to work with

waterfall projects so it doesnt

apply to smaller, agile projects


9/32


Where it all began: Deming vs. CrosbyWho was Agile?

Deming said quality is conformance to theprocess

Demings work was based upon the supposition that engineering was empirical, notlinear

Crosby said quality is conformance to specification

Crosby built his M3 based upon this linear manufacturing concept

The SEI used M3 as a model for CMMI but they echoed Demings belief in Process

performance

The CMMI levels are modeled after Crosby but have content based uponDemings Theory of Profound Knowledge

What does your SCAMPI Lead Appraiser think?


10/32


The case for Process, not Specification

Demings Theory of Profound Knowledge:

Cease dependence on QC, instead focus on QA built into theprocess

Collaborate with your customer

Build trust and loyalty throughout the lifecycle

Just-in-time Training

Drive out Fear

Break down departmental barriers

Remove barriers of pride

Respond quickly to changes

Is this Agile? . . . .


11/32


Agile Manifesto

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.


12/32


Blowing up the myths

The average CMMI Level 3 SCAMPI Appraisal examines 400 document

types and over 1000 artifacts

Average Agile project produced 39 artifacts

You can reduce and consolidate objective evidence and average+-70 document types for CMMI

A template, form, or document is always the obvious answer but

there are other options

Digital photos

White Board printouts

Videos

Scanned drawings, documents, and napkins

Databases Code comments

etc. . .


13/32


For Instance . . .

Code Reviews can be evidenced right in the code library (Verification)

Configuration Planning can be consolidated with Tailoring Guidelines,Configuration Audit Checklists, and Sizing and Estimating evidence (ProjectPlanning, Configuration Mgmt, OPD)

Iteration and Release frequency can produce Plan Review and Process Quality

Review evidence

Agile Methods themselves can serve as policies around planning, estimating,budgeting, and staffing eliminating the need for separate evidence

Iterations and Releases themselves are evidence of monitoring andmilestones.

In an Agile environment, core behaviors can become Alternative Practices for CMMI


14/32


Evidence: An Example

Implied by the CMMI Possible Substitute

Meeting Minutes Meeting Log

Notice of Decision Meeting Log

Stakeholder Involvement Report Meeting Log

Status Reports Meeting Log

Stakeholder Communications Meeting Log

Change Request Log Reqts Log

Change Request Approval Form Reqts Log

Detailed Requirement Specification Reqts Log

Bi-Directional Traceability Matrix Reqts Log


15/32


Traditional Software and Process Development Life-Cycle

Guiding

MainlineApplicationSolution

Supporting

ApprovedBusinessCase / SOW

AssignedPM

RequirementsDevelopment

ProjectPlanning

TechnicalSolution

Validation Verification

OrganizationalProcess

Measurementand Analysis

Process and ProductQuality Assurance

Project

Monitoringand Control

Risk

Management

Configuration

Management

Requirements

Management

ApprovedAppropriations(Tracking)

ApprovedFunding

Inputs Outputs

PrioritizedDocumentation

ProcessImprovements

BusinessValue


16/32


"In theory, there is no differencebetween theory and practice, but in

practice, there is.Yogi Berra


17/32


Another way to look at Software and Process development


18/32


Obviously in small bites.

How are we going to eat this elephant?*

(a.k.a. How are we going to achieve our objectives?

No elephants were harmed during themaking of this presentation, nor in any ofour process improvement initiatives.*thanks to Steve Baker for this slide)

The SCAMPIsm Shuffle


19/32


Anything that takes time and costs moneyis scope, and scope is testable.

The CMMI Model

Guidelines for scoping process improvement

The SCAMPI MethodA suite of tests to validate and verify progress

Agile Methodologies

An empowering philosophy for action and success

A Philosophy Shift


20/32


One-Dimensional Deployment: Why Process Deployment Fails

IT orEngineering

Workers

Internal Re-engineering teamor Consulting Firm

Process Bomb


21/32


Three-Dimensional Force DeploymentThe US Militarys doctrine for waging and winning battles is effective because its scale-able, iterative,and incremental.

Logistics

Artillery

Infantry


22/32


Three-Dimensional Process Deployment

Process Design Communications Training

Assess current initiatives

Design compliant process

Process flow

Templates

Integration points

Audit process

Escalation process

Exception process

Metrics to measure success

Document and integrate into

process release schedule

Clear statement of mission

Communication of goals

Output

Deliverables

Business results

Communicate progress

Organizational Notice ofDecision (NOD)

Personalized communication

Distribution of metrics

Develop training plans

Develop standard trainingmaterials

Slides

Templates

Job-Aids

Hand-outs

Metrics to measure success

Conduct Training

Document and track training

participation

Special Interest Group (SIG)(Persistent communities of interest)

Iteration 1 Iteration 2 Iteration 3

To be successful, processes need to be owned by persistent and sustainable bodies regardless of personnel ororganizational changes.

+ +


23/32


agileCMMIsm: Encapsulated Process Objecttm

Software EngineeringProcess Group

SEPG

The SEPG isthe OWNER of

standardprocesses for

SolutionDelivery

The SIG inheritsmethods &

Attributes fromSEPG and contains

Process LEADERand the Voice ofthe Community

PersistentContainer hosting

multiple, permanentsub-processesworking groups

The SEPG is a sustainablebody that charters SIGs todesign, rollout, and maintainsub-processes. Membershipin the SEPG or SIGs mayrotate but the bodies arepersistent.

Configuration

ManagementCM

Metrics

MA

SCAMPI Appraisal

Team

Project Management

PM, PMC

Requirements

RM, RD, Traceability

Process Management

OPD, OPF


24/32


SIG Roles and Responsibilities

SIG owns a specific Sub-Process

Facilitate Design SLAMS during each iteration

Develop and maintain Process,Communication, Training

Present to SEPG before each final release

Responsibility for maintenance, upgrades,and subsequent releases


25/32


Process Roles

Provides Direction

and RequirementsDevelops and Defines

Commissions, Oversight,

Coordination, ReviewWork Products

User and FinalAcceptance

Decision-Making Bodyfor Sub-Process

Decision-Making Body(Veto power)

DecisionAuthority

Requirement orFeature Changes

Initiates ChangesChange Control BoardChange

Management

Sponsor, Strategy,Stakeholders, SMEs

SMEs, Process Owner,Appointed Reps

SIG members, SteeringCommittee

MembershipComposition

Accreditationor Certification

Performance ofASD Sub-Process

Performance ofOverall ASD Process

Accountability

Program SuccessOne Sub-ProcessOverall Perspective;

SIGs and MoreFocus

TemporaryOngoingOngoingDuration

Specific Programor Initiative

Application SolutionDelivery Sub-Process

Overall ApplicationSolution Delivery (ASD)

Ownership

SEPG SIGs SteeringCommittee

SOX

ITIL etc.

CMMIRequirements

Conf. Mgmt.

PPQA etc.


26/32


SDP Product Release ApproachSolution Delivery Process (SDP) is an Agile methodology for delivering and

supporting software-based business solutions

SDP is a Process

To be used by all IT and Engineering professionalsinvolved in the delivery and support of softwareapplications; SDP provides the tools and clarity weneed to do our jobs.

SDP is a Product A suite of work products including process flows,

process descriptions, templates, and Standards andGuidelines which are delivered and maintained by anSDP project team.


27/32


Agile Process Deployment in Three Releases (CMMI Level 3)

2Q07 3Q07 4Q07 1Q08 2Q08 3Q08 4Q08

Launch SIGs

Process Management

ConfigurationManagement

Process Quality

Metrics andMeasurement

Requirements

Engineering

Level III Class C

Train and mentorteams

Level III Class B

Level III Class A

LevelIIIClassC

Le

velIIIClassB

Le

velIIIClassA

Celebrate!

Celebrate!

Celebrate!

R1.0 R2.0 R3.0


28/32


Case Study: CMMI SCAMPI C in 3Q05

NI PI LI FI

RM PP PMC SAM M&A PPQA CM

Specific Goal 1 % Complete 20% 25% 71% 25% 50% 0%

Specific Goal 2 % Complete 29% 100% 25% 50% 0%

Specific Goal 3 % Complete 33% 0%Generic Goal 2 % Complete 20% 20% 10% 20% 20% 0%

Generic Goal 3 % Complete 0% 0% 0% 0% 0% 0%

Specific Practices 5 14 10 7 8 4 7Generic Practices 12 12 12 12 12 12 12

Current Status 13% 21% 45% 18% 30% 0%

RD TS PI VER VAL OPF OPD OT IPM RKM IT ISM DAR OEI

Specific Goal 1 % Complete 50% 0% 67% 100% 100% 33% 33% 0% 20% 67% 50%

Specific Goal 2 % Complete 67% 75% 100% 0% 100% 25% 0% 67% 50%


Specific Goal 4 % Complete

Generic Goal 3 % Complete 17% 17% 83% 17% 25% 17% 33% 0% 100% 0% 0%Specific Practices 10 9 9 8 5 7 5 7 13 7 8 5 6 6Generic Practices 12 12 12 12 12 12 12 12 12 12 12 12 12 12

Current Status 33% 35% 81% 54% 75% 25% 33% 0% 62% 29% 25%

CMMI Managed - Level 2

CMMI Defined - Level 3

(300 Engineers, 25 PMs, web development)


29/32


Case Study: CMMI SCAMPI A in 4Q06 (D+18 Months)

NI PI LI FI

RM PP PMC SAM M&A PPQA CM

Specific Goal 1 % Complete 100% 75% 100% 25% 100% 100%


Specific Goal 3 % Complete 100% 100%Generic Goal 2 % Complete 100% 100% 100% 90% 100% 100%

Generic Goal 3 % Complete 100% 100% 100% 0% 100% 100%

Specific Practices 5 14 10 7 8 4 7Generic Practices 12 12 12 12 12 12 12

Current Status 100% 95% 100% 41% 100% 100%

RD TS PI VER VAL OPF OPD OT IPM RKM IT ISM DAR OEI

Specific Goal 1 % Complete 100% 100% 100% 100% 100% 100% 100% 100% 80% 67% 50%

Specific Goal 2 % Complete 67% 100% 100% 100% 100% 100% 100% 100% 100%


Specific Goal 4 % Complete

Generic Goal 3 % Complete 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 0%

Specific Practices 10 9 9 8 5 7 5 7 13 7 8 5 6 6Generic Practices 12 12 12 12 12 12 12 12 12 12 12 12 12 12

Current Status 92% 100% 100% 100% 100% 100% 100% 100% 93% 92% 25%

CMMI Managed - Level 2

CMMI Defined - Level 3


30/32


Conclusion

CMMI and Agile are complementary perceiveddifferences are often in approach, not substance.

CMMI CW is too much Crosby and not enough Demingand Agile

You can implement a CMMI-compliant SDP that is

Agile and brings you the repeatability andpredictability offered by CMMI The Best of Both!

There are many alternatives to the CMMI expected

practices and example artifacts think Agility (and help

your Lead Appraiser learn)!


31/32


Questions?

Ask about CMMI and Agile on Jeffs Blog at:

http://asktheCMMIAppraiser.blogspot.com

For this presentation and others email:

[email protected]

248.341.3367

www.broadswordsolutions.com


32/32


About Broadsword

Broadsword helps companies build world-class

software development organizations with

Process Innovation solutions that enable them to

compete and win in the global economy.

For more information about Broadsword, or

CMMI Appraisals and Training, contact

[email protected] or visitwww.broadswordsolutions.com

Documents

The Secrets of Cmmi for Small Companies Webinar Speaker Slides1