2. 2
Agenda
§ Client Agile History
§ Problem of Scaling
§ Scaled Agile Framework
§ RTC SAFe Process Template
§ Team Organizational Model
§ Merging SCM Systems with RTC
§ Adding XP Practices
§ How it all Worked
§ Metrics
§ The Results
3. Kim Werner
LinkedIn: http://www.linkedin.com/in/kimtwerner
§ Agile Community of Practice Lead
§ 25+ years IT experience in all roles
§ CSM, CSP Certified
§ Certified SAFe SPC
§ Agile Player Coach
§ Former Chairman/Founder - North FL RUG
§ RUP, OOAD, and several Rational Tools Certified
§ IBM Regional Jazz Mentor Program
§ IBM Lead for Agile Transformation Community -
developerWorks
§ EPF Content Lead – Evolutionary Design Plugin for
OpenUP
Yes. It’s -20F.
Yes. It’s a snow shelter Yes. I’m crazy!
Yes. That’s me!
Kwerner@BlueMercuryConsulting.com
Twitter: @kwernerus
4. § Enterprise ALM Technology
Deployment Specialists
§ Software Engineering process
improvement
– Waterfall, Iterative, Lean, Agile
– RM, A&D, Development
– CM, QA, Build, Deploy
– Report
§ BlueJazz: knowledge repository
– People, process, tools
– Award Winner IBM Innovate 2013 Best
of Show
§ Agile Transformation Experts
– CSM, CPO, CST, CSP
– SAFe: Certified trainers and
implementers
– DAD
– Innovation Games
§ Scrum Alliance
– Certified Scrum Trainers
– Certified Scrum Masters
– Certified Scrum Product Owners
§ IBM
– IBM Premier business partner
www.BlueMercuryConsulting.com
Blue Mercury Consulting Overview
5. Client’s Agile History
§ Major U.S. Health Services Insurer serving 3.7 Million
customers
§ Majority of the SDLC is waterfall
§ 2010 – Introduced Scrum, RTC, Agile Requirements
– 3 Independent Teams
– Saved 1.6 Million, Reduced Time-to-market, higher quality
§ 2011 – Scaled Agile Adoption to include Scrum of Scrums
– 6 Interdependent Teams
– Organizational model changes:
Über Scrum Master, Über Product Owner
– Introduced RRC
– Scaling Issues in Planning started to rise
§ 2012 – Adopted SAFe as a Scaling Model
– Major re-platforming Initiative
– 12 Interdependent Teams plus waterfall integration
– Around 150 People
5
6. Problems of Scaling
§ SoS – Scrum Of Scrums
– Becomes more difficult after 6 or so Teams
– Planning & Ceremonial Events conflict
§ Doesn’t really address a Portfolio & Program View
– Still thinks of smaller “projects”
– Planning Roadmap horizons are still short
§ Fails to recognize that Waterfall still exists
§ Governance & Authority start to fail
– No Clear Content Authority once you scale to a Program or Portfolio level
– Who resolves priorities across dozens of teams?
– Who then drives releases?
§ Reporting & Metrics aren’t sufficient across large numbers of teams or programs
§ Traditional sources of information (Scrum/Agile Alliance) aren’t mature to help this
– Note: In Jan ‘2013 Ken Schwaber introduced CIF –Continuous Improvement Framework
6
7. The Scaled Agile Framework (SAFe)
The Scaled Agile Framework is a proven, publicly-facing framework
for applying Lean and Agile practices at enterprise scale
Well defined in books
and on the web
Synchronizes vision, planning,
interdependencies, and
delivery of many teams
Works well for teams of
50 – 150 people
Has been scaled to hundreds
of teams and thousands of
people
For more info, see
ScaledAgileFramework.com
8. SAFe: Refine the Time Boxes View
§ Sprint
– Strict Time box iteration where all Define
Build and Test takes place by a Team
– 2 weeks in duration
§ Sprint Release
– Working Increment of Software
– Tested, Potentially Shippable, Demonstrable
§ PSI
– Potentially Shippable Increment. The
culmination of a number of Features (and
their stories) into a production ready release
– Involves the output of several teams
– Occurs every 10 weeks
8
9. SAFe - HIP Sprints
§ Hardening: Some system tests, product and
regulatory validations, documentation may not be
practical every iteration
§ Innovation: Provides an opportunity for innovation
spikes, hackathons, and necessary infrastructure
improvements
§ Planning: Any Future PSI Pre-work and then
Holding PSI planning events, continuous
education during hardening supports cadence and
continuous improvement
9
10. SAFe: Refine Terminology around Requirements
§ Epic
– Represents a large collection of
needs of Business Users
– Typically spans Releases
§ Feature
– A capability that is valuable to a
business (High Level User Story)
– Features Span Sprints
§ User Story
– Description of a small piece of
functionality by a system or
organization
– Part of a Sprint
12. SAFe: Release Train Organizational Structure
12
1) Each train represents a
value stream;
something(s) customers
BUY
2) Every individual
pictured is dedicated to
this program
3) Only Train engineer,
PLM, and Product
Managers do not report
to Dev./delivery
manager
4) Dedicated architect and
project managers
reporting to Dev./Del
mgr.
5) Dedicated RTE drives
planning, execution
(SoS) and Regular
Inspect and Adapt
13. SAFe Specialized Team: System Team
§ Builds/supports Development Infrastructure
and Environments
§ Collaborates with vendors to procure
environments and tools for development
teams
§ Integrates code for all development teams
within the program
§ Leads the execution of end to end system
testing
§ Creates systems, utilities, and scripts to
automate deployment
13
14. SAFe Specialized Team: Release Management Team
§ Most enterprises have this in some
form. SAFe recognizes that and
makes it essential to the framework
§ Provides Governance for
Synchronized Releases including
any Release Controls
§ Decision Authority to Negotiate
contents of Feature Sets
§ Works with other non-Agile teams
for coordination
§ Deployment/Back-out Plan Owner
14
16. SAFe Template RTC Customizations
§ New workitem types needed
to be created:
– Milestone
(for Releases)
– Feature
– Recursive Epic
(for Themes)
– PlanRisk & Risk Action
16
17. SAFe Template RTC Customizations
§ RTC already has Scrum & Kanban process templates but it didn’t have one for SAFe
§ New Roles and Security
– Product Manager
– Release Train Engineer (As an Uber Scrum Master)
17
18. SAFe Team Organizational Model
§ Teams have a natural hierarchy as do Timelines
§ New Team Categories & Recursive Timelines were created
to support the SAFe organizational model and future
Reporting needs
– System team, Release Management Team, Architecture, UX
18
19. What about Waterfall?
§ It’s unlikely that an entire organization of hundreds or thousands will go all in with regards to
an Agile adoption.
§ Contrary to myth, Agile practices cannot be done for everything
– Anyone ever procure hardware or work with any government bureaucracy in an Agile time-boxed
manner?
§ The trick is to treat them like another Program then when to Synchronize and how often
19
20. What about Requirement Traceability?
§ RRC was leveraged to house High-level Business Capability Requirements
§ Functional Requirements as User Stories Housed in RTC and then traced
20
21. Merging SCM Systems
§ Client used multiple tools
– Dimensions, CVS for Source Code
Management
– Ant for Builds
– Manual Merging & Deployment
§ We needed to leverage RTC’s SCM & Build
§ Parallel Development was still going on
§ Solution:
– Uni-Directional synchronization between SCM
for new legacy code
– Shared libraries for shared JARs
– Customized build Scripts
21
22. Add in more XP Practices
§ SAFe’s bottom (Team) layer refers to
ScrumXP as the process model
§ This means to achieve the optimum benefits,
incorporating (where it makes sense) some
engineering practices from eXtrememe
Programming is essential
§ Incorporate ATDD (Acceptance Test Driven
Development)
– Leverages a Test First Strategy
– Start with your Conditions of Satisfaction of a User
Story
– Add in TDD (Test Driven Development) such a jUnit
– Add in Functional Test Automation
§ Incorporate CI (Continuous Integration)
– Make the jUnits part of the Build
§ Adding a ATDD & CI bakes the quality in and
ensures stable builds
22
23. How it all Worked: The Summary
§ Establish Organizational Authority
– Product, Delivery, and Release Management
§ Derive Portfolio Epics based upon enterprise
Investment Themes
§ Decompose Epics into the supporting Features
§ Define the Roadmap by PSI & Feature set
– At least 3 to 4 PSI’s out (30-40 wks)
– Define PSI Objectives
§ Staff teams by Feature sets
§ Product Owners of each team work with their
Product Managers to derive User Stories for each
candidate Feature nominated for the upcoming
PSI
– Vetted by their teams
§ Conduct PSI Planning Session
– Hold offsite to accommodate the number of people
– Gain commitment for the PSI
23
24. How it all Worked: PSI Planning
§ Similar to Sprint Planning but covering a
10 week PSI
§ Product Managers meet prior to nominate/refine the
PSI Features for the stated PSI Objectives
– They, in turn, meet with their Product Owners
so that the Product Owners can work with their teams to
nominate Stories for the candidate Feature set
§ Typical Agenda:
– Business Context (State of the Business & Upcoming
Objectives)
– Shared Vision update (Business &
Architectural Features)
– Team Breakouts (30 Min)
- Teams huddle
- Revise Team-level PSI objectives
- Define Sprint Goals to match the Objectives
- Plan their Stories by Sprint for the PSI
24
25. How it all Worked: PSI Planning
§ Imagine planning 10 weeks of work with
120-150 people
§ How do you keep on cadence and
moving forward with the shared PSI
objective?
§ The answer is to Synchronize!!
§ At the end of each Team Breakouts, the
team Product Owners & Scrum Masters
join an SoS (15 Min)
– Each team describes how they will
implement the Feature through the Stories
– Shared Features are important as other
teams depend on this
– Facilitates inter-team collaboration
§ Using information gathered in the SoS,
Teams may revise/refine their plans
25
26. How it all Worked: PSI Planning
§ Product Management roams between teams’ during their
PSI planning
– Ensuring the Teams’ objectives & Sprint Goals are consistent with
the overall PSI Objective
§ Architects also roam between teams to ensure consistent
architectural oversight
– While best designs come from the teams, they still must fit within
the Architecture
26
27. How it all Worked: PSI Planning
§ The PSI planning continues until all of the
teams involved in the PSI planning have fully
committed to delivering the Features of the
planned PSI
– This is done in a mass show of hands. Everyone
must be on board
– At the inception of this initiative, it actually took 2
full days. Later we were able to streamline it to 1
day
– Make certain Plans are updated in RTC before they
leave
– Teams should be set up for Sprint Planning the
next day
§ Tips & Tricks for success
– Have a large room
– Fast Wi-Fi
– Plenty of power Strips for laptops
– Feed the peeps
27
28. How it all Worked: The Demo
§ Demos are now done at different points
– Teams do their Sprint Review Demo
– Then, a separate integrated demo is done
by the System team called a System Demo
§ A System demo ensure that multiple
teams’ work can all integrate well
together
– System demos typically occur some time
after the Teams’ demo
§ At the end of the HIP Sprint, a more
formalized demonstration takes place
at the end
– Product Management accepts/rejects the
Features
28
29. How it all Worked: When do you Release?
§ Scrum suggests that the code is potentially shippable at the end of a Sprint
§ This doesn’t make sense for Large Programs unless you’re talking priority bug fixes
§ What do you do? Develop on Cadence but Deliver on Demand
29
31. Reporting Metrics – Feature % Completed
§ Metrics had scaled as well. Now it became more important to determine whether or not the
Program will make it’s PSI Commitments
§ RTC out of the box, didn’t have this kind of reporting and Insight was on a longer term
deployment schedule. Only solution was to extract from RTC and create from Excel
31
32. Reporting Metrics – Feature Points Completed
§ SAFe embraces relative size estimation so story points matter. Accordingly rolled up story
points by feature has value as well
§ Showing Planned vs. Actual at this level is helpful
32
33. Reporting Metrics – Don’t Forget those Burndowns!
§ Burndowns are yet another holistic view at a Program Level and they scale as well
33
36. 36
Daily Apple TV giveaway
§ Complete your session surveys online each day at a conference kiosk or on
your Innovate 2013 Portal!
§ Each day that you complete all of that day’s session surveys, your name will
be entered to win the daily Apple TV!
§ On Wednesday be sure to complete your full conference evaluation to receive
your free conference t-shirt!
37. 37
Please note the following
IBM’s statements regarding its plans, directions, and intent are subject to change or
withdrawal without notice at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general product
direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a commitment,
promise, or legal obligation to deliver any material, code or functionality. Information
about potential future products may not be incorporated into any contract. The
development, release, and timing of any future features or functionality described for our
products remains at our sole discretion.
Performance is based on measurements and projections using standard IBM
benchmarks in a controlled environment. The actual throughput or performance that any
user will experience will vary depending upon many factors, including considerations
such as the amount of multiprogramming in the user’s job stream, the I/O configuration,
the storage configuration, and the workload processed. Therefore, no assurance can be
given that an individual user will achieve results similar to those stated here.
