Is Your Agile Development SAFe?
David P. Quinn
SM
SCAMPI is a service mark of Carnegie Mellon University
1
What Is Agile?
The 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.
2
Great Benefits to Agile
 Quick iterations focused on working software
 Greater collaboration with fewer extended meetings
 Plan the work and work the plan
 Continuous develop, build, integrate, and test cycles
 Adaptable to changes
 Insight into work in progress
 Working most important items/functions first
 Clear definition of what “done” means
3
Inhibitors to Agile
 Dependencies on other teams
– Not practicing Agile
– Different iterative cycles
– Lack of interactions
 Poorly timed enterprise architecture changes
– Won’t allow a cycle to complete
 Stakeholders who don’t stay involved in the project
 Lack of support mechanisms outside of the project team
4
Addressing the Problems
 The Scaled Agile Framework (SAFe)
 SAFe is a proven, publicly-facing framework for applying Lean
and Agile practices at enterprise scale
‒ Synchronizes alignment, collaboration, and delivery
‒ Well defined in books and on the web
‒ Scales successfully to large numbers of practitioners and teams
 Core values
–
–
–
–
Alignment
Code Quality
Program Execution
Transparency
http://ScaledAgileFramework.com
5
The Great Melting Pot
 Practices and principles from:
–
–
–
–
Scrum
XP
Lean
Kanban
 Various levels (don’t think CMMI® levels) addressing
implementation
– Portfolio
– Program
– Team
 Let’s look at SAFe in more detail with an eye towards
CMMI-DEV practices
® Capability Maturity Model and CMMI are registered in the U.S. Patent & Trademark Office.
6
The Big Picture of SAFe
Page 7
7
SAFe and CMMI-DEV
 Like many Agilists, people involved in SAFe view CMMIDEV as an impediment to Agile
– This is usually based on misinterpretations and stereotypes of
CMMI-DEV
 SAFe provides a standard process/framework that is
tailored to an organization’s specific needs
– Programs and projects then tailor SAFe practices at their level
to their specific needs
– Sounds a lot like OPD and IPM from CMMI-DEV
 So, can SAFe and CMMI-DEV coexist in an organization?
– Let’s examine SAFe with an eye towards CMMI-DEV practices
® Capability Maturity Model and CMMI are registered in the U.S. Patent & Trademark Office.
8
The Big Picture of SAFe
Page 9
9
Portfolio Level
 Strategic direction for business goals and enterprise
technology needs [RD SP 1.1]
– Business Epics span multiple releases and adjust to the market
direction and business climate
– Technical Epics continuously evolve the architecture to address
changes in technology
 Value Streams help prioritize business needs [RD SP 3.2]
– Most value for the available effort
 Maintained in a Portfolio Backlog [RD SP 1.2]
– The beginnings of requirements traceability [REQM SP 1.4]
10
Program Level - 1
 Program Backlog incorporates Portfolio Backlog items and
Product Management features into a vision and roadmap
– Besides traceability, aids in balancing requirements [RD SP 3.4]
 Agile Release Train coordinates activities across teams,
establishing a cadence for teams to match [IPM SP 1.4, SP 1.5]
 Release Planning Session gets all teams and product owners
together to discuss features to be developed [IPM SP 2.1]
 All teams commit to what they will work in the coming time box
[PP SG3]
11
Program Level - 2
 At the end of each time box, integrate potentially shippable
increments [PI SG3]
 “Scrum of Scrums” coordinate needs across project teams and
ensure everyone is able to meet their commitments [IPM SP 1.5
and PMC SP 1.2]
12
Team Level
 Sprint Planning Session defines what the team will work
during the time box [REQM SP 1.2]
 Sprint/Team Backlog lists work that needs to be performed
during the time box [PP SP 1.1]
 Team visually tracks work in progress, work completed, and
work waiting to be started [PMC SP 1.1] during daily stand
up meeting [PMC SP 1.6]
13
Team Level - 2
 Sprint Review demonstrates work completed to the
Product Owner for acceptance [PMC SP 1.7, VAL SP 2.1]
 Sprint Retrospective reviews team performance to identify
potential performance improvements [GP 3.2]
14
Key Roles
 Scrum/Agile Master – Facilitates daily stand up meetings;
updates Sprint Backlog [PMC SP 1.2]; ensures process fidelity
[PPQA SP 1.1; GP 2.9]
 Agile Team – Cross-functional team fully capable of defining,
building, and testing increments of customer value in a short
time box. [TS SG2, SG3]
 Release Train Engineer – Facilitates program-level processes
and execution; drives program-level continuous improvement
[IPM SG2]
 System Architect – Focuses on making design decisions that
must be made now to support future features [TS SG 1]
 Release Management Team – Coordinates and facilitates the
delivery of productized software (the whole product solution)
developed by its associated Agile Release Train [CM SP 1.3]
15
Standardizing the Defined Process
 As a framework, it is not a “methodology” (just like CMMI) but it
provides the guidance for consistent performance of Agile
processes and team operations [OPD SG1]
 Agile Teams constantly measure their performance to ensure
they are making adequate progress and to calculate their
general velocity for planning future time box workloads [MA
SG2]
 Various retrospectives at both the team and program levels
actively seek improvement suggestions to improve performance
for the next time box [OPF SP 1.3]
 SAFe requires that people be adequately trained to perform
specialized roles such as the Release Train Engineer [GP 2.5, OT]
 Successful SAFe organizations incorporate tools to automate
process flow and minimize data entry [GP 2.3, IPM SP 1.3]
– These tools often act as the repository for SCAMPI evidence
16
What Does SAFe Miss in CMMI-DEV?
 Like many Agile approaches, reporting measures outside the
project team is not emphasized
– Not differentiating measures that are truly team specific (velocity, story
points) from measures that could be shared (defect closure rate,
cost/effort variance)
 Improvements tend to be held at the team level, not shared
across teams
– Common problem in many organizations starting up CMMI
 Objectively evaluating compliance with processes, standards,
and procedures
– Though the Scrum Master provides most process enforcement
17
What Detractors Have to Say
SAFe
CMMI-DEV
 Not real Agile
 Constrains developers with
specified time boxes
 It’s a linear model
 Value processes over people
 It’s a top-down control
approach for management
 Doesn’t support Agile
 Turns developers into
automatons
 It focuses on Waterfall
 Check the box exercise
 It’s a top-down control
approach for management
18
www.mosaicsgroup.com
SAFe and CMMI
 Agile can have a great impact on software organizations
 Inhibitors frequently block Agile teams from getting the greatest
benefits from Agile
 The Scaled Agile Framework (SAFe) defines an enterprise
approach for Agile
 Each program and team tailors Agile practices based on Lean
principles
 This is very similar to the concepts within the CMMI-DEV
Maturity Level 3
 SAFe has its detractors, which make the same arguments against
CMMI-DEV
 With some fairly straightforward interpretation, organizations
implementing SAFe should be able to successfully be appraised
against the CMMI-DEV
19
MOSAIC Technologies Group, Inc.
8161 Maple Lawn Blvd, Suite 430
Fulton, Maryland 20759-2571
Tel: (301) 725-0925
Fax: (301) 725-0985
www.mosaicsgroup.com
David P. Quinn
Chief Quality Officer
Certified SCAMPISM Lead Appraiser
Introduction to CMMI® Instructor
Direct: (240) 459-1334
Mobile: (717) 451-2149
dquinn@mosaicsgroup.com
20
www.mosaicsgroup.com