Killing the Myth: Agile & CMMI

Killing the myths:
Agile and CMMI

Agile Eastern Europe Conference
Kiev, 23-24 September 2011

Christophe Debou Tomasz de Jastrzebiec Wykowski
Christophe.Debou@kuglermaag.com Tomasz.Wykowski@procognita.com

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.debou@kuglermaag.com

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

Tomasz de Jastrzębiec Wykowski

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

Process Technology

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

Staged Representation: Process Areas by
Maturity Level
Level Focus Process Areas Quality
Productivity
5 Optimizing Continuous Causal Analysis and Resolution
Process Organizational Performance Management
Improvement
4 Quantitatively Quantitative Organizational Process Performance
Managed Management Quantitative Project Management
3 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
Verification
2 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 Risk
1 Initial Rework

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 performance

1

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
Elaborations

Legend Required Expected Informative

Problems and Solutions
Problems Solutions
„CMMI forces us to do things
we do not need.“

„Employee have no freedom.
Every single step is
described.“
„We cannot maintain
processes because of their
fast pace of changes“

CMMI is a journey to excellence

CMMI Level 2 Process Areas


Project Planning

Configuration Management

Measurement and Analysis


Requirements Development (RD)
Purpose
• Produce and analyze customer, product, and
product component requirements.

Requirements Development Context -1

Develop Develop Analyze and
Customer Product Validate
Stakeholders’ Requirements Requirements Requirements
Needs

Validated Customer Validated Product, Product Component, and
Requirements Interface Requirements
Source: Introduction to CMMI, SEI, Accredited Course

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
Requirements

Customer, Product, Product Component, and Validated
Interface Requirements Requirements

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

Context

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

Customer collaboration over contract negotiation
--- Agile Manifesto ---

CMMI Goal Agile Practices
SG 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

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
PMC

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
Lifecycle


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 Plan

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
Stakeholders

“In preparing for battle I have always found that
plans are useless, but planning is indispensable.”
--- Dwight David Eisenhower ---

Project Planning
SG 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).

Project Planning
SG 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

Project Planning
SG 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

PROJECT
MONITORING
AND CONTROL

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.

Context
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

Responding to change over following a plan

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

SG 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
project's deadlines.
performance or  Impediments collected and resolved
results deviate by ScrumMaster
significantly from
the plan.

Measurement and Analysis (MA)
Purpose
• Develop and sustain a measurement capability
that is used to support management
information needs.

Measurement & Analysis Context

Align Measurement and Analysis Activities
Specify
Establish Data Specify
Specify Collection
Measurement Analysis
Information 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

“Data is of course important in manufacturing,
but I place the greatest emphasis on facts.”
--- Taiichi Ohno ---

Measurements and Analysis
SG 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)

Measurements and Analysis
SG 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.

Configuration Management (CM)
Purpose
• Establish and maintain the integrity of
work products using configuration
identification, configuration control,
configuration status accounting, and
configuration audits.

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 Baseline
versions
coming
Iteration II Baseline
about)

Iteration III Baseline

Release I Baseline

Configuration Management Context
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
Management
Items System Records
Reports

Working software over comprehensive documentation
--- Principles behind the Agile Manifesto ---

SG 1 Baselines of identified  Configuration Management has to be
work products are supported by automated tools
established.  Code and important documents held
SG 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 them
SG 3 Integrity of baselines is
 Limit number of development
established and
branches in order to avoid
maintained integration issues

PROCESS AND
PRODUCT QUALITY
ASSURANCE

Process and Product Quality
Assurance (PPQA)
Purpose
• Provide staff and management with objective
insight into processes and associated work
products.

Context

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

Individuals and interactions over processes and tools


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


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

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

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

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

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

Further reading
Articles:
• 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 2008
Reports:
• CMMI for Development, Version 1.3, Technical Report, CMU/SEI-
2010-TR-033, November 2010
Books:
• Jeffrey K. Liker, David Meier “The Toyota Way Fieldbook” , McGraw-
Hill, 2005

Killing the myths:
Agile and CMMI
Agile Eastern Europe Conference
23-24 September 2011

Christophe Debou Tomasz de Jastrzebiec Wykowski
Christophe.Debou@kuglermaag.com Tomasz.Wykowski@procognita.com

Killing the Myth: Agile & CMMI

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (10)

Ähnlich wie Killing the Myth: Agile & CMMI

Ähnlich wie Killing the Myth: Agile & CMMI (20)

Mehr von Tomasz Wykowski, CST

Mehr von Tomasz Wykowski, CST (14)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Killing the Myth: Agile & CMMI

Hinweis der Redaktion