agilecmmi - sepg nashville final - broadsword|agile, cmmi...

Copyright 2007 Broadsword Solutions Corporation

agileCMMIsm

CMMI For Small Agile Organizations

Jeff Dalton President

CMMI Lead Appraiser and

CMMI Instructor


Where to find this version of the presentation . . .

For a copy of this presentation, and to receive excerpts from Jeff’s book, “Agile CMMI,” simply email

[email protected]


If you only remember one thing . . .

Benefit

Effo

rt &

Cos

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

JENTMsm = Courage to stop

$


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


Components of an SDP All need representation, not all need to be complex

SDP Process

Essences and Core Principles

Roles and Responsibilities

Glossary of Terms

Process Flows

(Swimlanes)

Process Definitions

Standard Work

Instructions

Templates and

Examples

Communication Materials

Training Materials

Standards and

Guidelines


Conflicting or Collaborative?

Agile implies:

Iterative

Incremental

Action based

Team agreements

Rapid change

Scope shrinks to meet deadlines

Document-lite

Assume a low level of constant re-work

Trust

CMMI implies:

Procedural

Extensive planning

Deliverable based

Hierarchical governance

Careful change

Budget grows to meet Scope

Document-heavy

Avoid re-work through planning and monitoring

Governance Layers

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


CMMI and Agile often perceived as didactic …

People that advocate Agile tend to disdain structure People who support CMMI tend to want to avoid chaos and risk . . . so it follows that most advocates of CMMI focus on

planning and that most advocates of Agile focus on iterations and failing fast.

We don’t have to choose!


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 every

meeting making decisions with the team

•  No need to record decisions-

we just have a meeting •  CMMI is incompatible with

Agile

•  Appraisals or audits are not valuable

•  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 •  It’s designed to work with “waterfall” projects so it doesn’t apply to smaller, agile projects


Where it all began: Deming vs. Crosby Who was Agile?

Deming said “quality is conformance to the process”

–  Deming’s work was based upon the supposition that engineering was empirical, not linear

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 Deming’s belief in Process

performance

The CMMI “levels” are modeled after Crosby but have content based upon Deming’s “Theory of Profound Knowledge” What does your SCAMPI Lead Appraiser think?


The case for Process, not Specification

Deming’s Theory of Profound Knowledge:

–  Cease dependence on QC, instead focus on QA built into the process

–  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? . . . .


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 on the right, we value the items on the left more.


Blowing up the myth

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


For Instance

•  Code Reviews can be evidenced right in the code library (Verification) •  Configuration Plan can be consolidated with Tailoring Guidelines,

Configuration Audit Checklists, and Sizing and Estimating evidence •  Iteration and Release frequency can produce Plan Review and Process Quality

Review evidence

•  Agile Methods will often dictate policies around planning, estimating, budgeting, and staffing to serve as evidence

•  Iterations and Releases themselves are evidence of monitoring and milestones.

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


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 Reqt’s Log

Change Request Approval Form Reqt’s Log

Detailed Requirement Specification Reqt’s Log

Bi-Directional Traceability Matrix Reqt’s Log


Traditional Software and Process Development Life-Cycle

Guiding

Mainline Application Solution

Supporting

Approved Business Case / SOW

Assigned PM

Requirements

Development

Project Planning

Technical

Solution

Validation

Verification

Organizational Process

Measurement and Analysis

Process and Product Quality Assurance

Project Monitoring and Control

Risk Management

Configuration Management

Requirements Management

Approved Appropriations (Tracking)

Approved Funding

Inputs Outputs

Prioritized Documentation

Process Improvements

Business Value


"In theory, there is no difference between theory and practice, but in

practice, there is.“ Yogi Berra


Another way to look at Software and Process development


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 the making of this presentation, nor in any of our process improvement initiatives.

The SCAMPIsm Shuffle


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

The CMMI Model…

Guidelines for scoping process improvement

The SCAMPI Method… A suite of tests to validate and verify progress

Agile Methodologies… An empowering philosophy for action and success

A Philosophy Shift


“One-Dimensional” Deployment: Why Process Deployment Fails

IT or Engineering

Workers Internal “Re-engineering team”

or Consulting Firm

Process Bomb


Three-Dimensional Force Deployment The US Military’s doctrine for waging and winning battles is effective because it’s scale-able, iterative, and incremental.

Logistics

Artillery

Infantry


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 of Decision (NOD)

•  Personalized communication

•  Distribution of metrics

•  Develop training plans

•  Develop standard training materials

•  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 or organizational changes.

+ +


agileCMMIsm: Encapsulated Process Objecttm

Software Engineering Process Group

SEPG

The SEPG is the OWNER of standard

processes for Solution Delivery

The SIG inherits methods &

Attributes from SEPG and contains Process LEADER and the Voice of the Community

Persistent Container hosting multiple, permanent sub-processes working groups

The SEPG is a sustainable body that charters SIGs to design, rollout, and maintain sub-processes. Membership in the SEPG or SIGs may rotate but the bodies are persistent.

Configuration Management

CM

Metrics

MA

SCAMPI Appraisal

Team

Project Management

PM, PMC

Requirements

RM, RD, Traceability

Process Management

OPD, OPF


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


Process Roles

Ownership Overall Application Solution Delivery (ASD)

Application Solution Delivery Sub-Process

Specific Program or Initiative

Duration Ongoing Ongoing Temporary

Focus Overall Perspective; SIGs and More One Sub-Process Program Success

Work Products Commissions, Oversight, Coordination, Review Develops and Defines Provides Direction

and Requirements

Accountability Performance of Overall ASD Process

Performance of ASD Sub-Process

Accreditation or Certification

Membership Composition

SIG members, Steering Committee

SMEs, Process Owner, Appointed Reps

Sponsor, Strategy, Stakeholders, SMEs

Change Management Change Control Board Initiates Changes Requirement or

Feature Changes

Decision Authority

Decision-Making Body (Veto power)

Decision-Making Body for Sub-Process

User and Final Acceptance

SEPG SIGs Steering Committee

SOX ITIL … etc.

CMMI Requirements Conf. Mgmt.

PPQA … etc.


SDP Product Release Approach Solution 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 professionals

involved in the delivery and support of software applications; SDP provides the tools and clarity we need to do our jobs.

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

process descriptions, templates, and Standards and Guidelines which are delivered and maintained by an SDP project team.


Agile Process Deployment in Three Releases (CMMI Level 3)

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

Launch SIGs

• Process Management

• Configuration Management

• Process Quality

• Metrics and Measurement

• Requirements

• Engineering

Level III Class C

Train and mentor teams

Level III Class B

Level III Class A

Leve

l III

Cla

ss C

Leve

l III

Cla

ss B

Leve

l III

Cla

ss A

Celebrate!

Celebrate!

Celebrate!

R1.0 R2.0 R3.0


Case Study: CMMI SCAMPI “C” in 3Q05

NI PI LI FIRM 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 OEISpecific 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 3 % Complete 0% 50% 75% 100% 0%Specific Goal 4 % CompleteGeneric 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


Case Study: CMMI SCAMPI “A” in 4Q06

NI PI LI FIRM PP PMC SAM M&A PPQA CM

Specific Goal 1 % Complete 100% 75% 100% 25% 100% 100%Specific Goal 2 % Complete 100% 100% 50% 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 OEISpecific 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 3 % Complete 100% 100% 100% 100% 100%Specific Goal 4 % CompleteGeneric 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


•  Requirements Development (RD)

•  Technical Solution (TS)

•  Verification (VER)

•  Validation (VAL)

•  Organizational Process Focus (OPF)

•  Organizational Process Definition (OPD)

•  Organizational Training (OT)

•  Risk Management (RM)

•  Decision Analysis and Resolution (DAR)

•  Integrated Project Management

Pre-Assessment

Maturity Level 3 Appraisal Results


Maturity Level 3 Appraisal Results: The Generics

•  GP2.1: Establish an Organizational Policy

•  GP2.2: Plan the Process

•  GP2.3: Provide Resources

•  GP2.4: Assign Responsibility

•  GP2.5: Train People

•  GP2.6: Manage Configurations

•  GP2.7: Identify and Involve Relevant Stakeholders

•  GP2.8: Monitor and Control the Process

•  GP2.9: Objectively Evaluate Adherence

•  GP2.10: Review Status with Higher-Level Management

•  GP3.1: Establish a Defined Process

•  GP3.2: Collect Improvement Information

Pre-Assessment


Solutions Delivery Performance Indices The SD Indices are a reusable architecture that reflects the success and value of the Solutions Delivery Organization by aggregating performance metrics in a logical and meaningful way.

Solution Delivery Performance How Are we Doing?

Process Deployment Index

Systems Engineering Process Group (SEPG)

SIGs TAGs

Process Results Index

Process Owners

Practice Areas

Projects Projects

Process Compliance Index

Process Owners

Project Leaders

Project and Process

Audit

SDP Process

Audit

Are we successful Designing, building, deploying, and maintaining the Process?

Do the results from each Process Area show improved

project performance?

Is our process appropriate, are we complying with it, and

are we continuously improving it?


Conclusion …

•  CMMI and Agile are complementary – perceived differences are often in approach, not substance.

•  CMMI CW is too much Crosby and not enough Deming

•  You can implement a CMMI-compliant SDP that is Agile and brings you the repeatability and predictability offered by CMMI

•  There are many alternatives to the CMMI expected practices and example artifacts – think Agility (and help your Lead Appraiser learn)!


Questions?

Jeff Dalton

[email protected]

This presentation can be found at:

http://www.BroadswordSolutions.com


About Broadsword

Broadsword helps companies build world-class software development organizations with solutions that enable IT to compete and win in the global economy. For more information about Broadsword, or CMMI Appraisals and Training, contact [email protected]

agilecmmi - sepg nashville final - broadsword|agile, cmmi...

Documents