Transforming How We Deliver Value: Agility at Scale

AW6
Agile Development Concurrent Session
11/12/2014 1:30 PM
"Transforming How We Deliver
Value: Agility at Scale"
Presented by:
Amy Silberbauer
IBM
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073
888-268-8770 ∙ 904-278-0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

An executive IT specialist in the IBM Rational organization, Amy
Silberbauer is a Solution Architect charged with defining and driving
Rational’s Enterprise Scaled Agile solution, which is a critical part of
Strategic DevOps. An architect and an engineer with two decades of
software development experience, Amy is a recognized subject
matter expert on software development lifecycle solutions, including
enterprise modernization, SOA, and BPM. Her most recent
significant accomplishment is the ongoing transformation of the
solution planning and execution process for the Rational ALM
organization, which serves as a prime example of how an enterprise
can adopt scaled agile principles. Amy is a certified SAFe program
consultant.

© 2014 IBM Corporation
Transforming How We Deliver Value
Agility at Scale in IBM
Amy Silberbauer
Solution Architect, Strategic DevOps &
Enterprise Scaled Agile
IBM Rational
asilber@us.ibm.com

Learning Outcome
Understand the motivations driving Enterprise Scaled Agile transformations
Learn about the best approaches for Lean and Agile adoption at an Enterprise scale
Get an overview of the Scaled Agile Framework (SAFe)
Hear a retrospective on our experience within IBM in leading a SAFe-based scaled agile
transformation
2

Agenda
Agile and Lean: The Enterprise Point of View
Overview of the Scaled Agile Framework (SAFe)
Case Study: IBM's SAFe-Based Transformation Project
Retrospective
3

Agenda
Retrospective
4

Continuous Delivery – Great in theory, but in practice…
5
 Throughput of each process must be equal in order to avoid backlogs
 When preceding process is upgraded to a higher throughput, subsequent
processes must be upgraded to the same higher throughput in order to
maintain balance.
Slow, but
works…
Fast, but only
on some
teams…
Fast, and it
works!

Desire to increase throughput is driving change in software delivery
6
 Agile upgraded the development team to a higher throughput. This put pressure on the
next part of the delivery lifecycle (build/CI) to “keep up.”
 When build (CI) was upgraded to higher throughput, that put pressure on the next part
(deploy).
 As the deployment part of the lifecycle is addressed with higher throughput, the pressure
shifts to testing environments. Customers either need more testing environments, or
they need the capability to dynamically provision short-lived test environments. Further,
test automation becomes a necessity, not a “nice to have”.
 Rinse and repeat

Bringing together people, processes and technologies across the entire
software delivery lifecycle – spanning mobile to mainframe platforms
Systems of Record (SoR) Apps
Fewer
ReleasesDatabases
Systems of Engagement (SoE) Apps Rapid
Releases AppStore
IntegrationTest
Monitor
and Optimize
Develop
and Test
Web Apps
Frequent
Releases
Production
Environment
Databases
SystemsofInteraction(SoI)
Faster innovate cycles need to include existing systems
7

Efficient Delivery
• Less waiting and bottlenecks
• Less unproductive overhead
• Less defects and rework
8
Effective Steering
• Stakeholders
• Marketplace
• Users
Continuous
Feedback
Minimize
Waste
Feedback
cycles Efficiency
And must balance speed with effectiveness…

In applying Agile & Lean at Enterprise Scale what problems are we
trying to solve?
9
Inability to respond quickly to change
Market shifts
Business shifts
Customer feedback
Lack of focus on value delivery
Value streams become fragmented and diluted
Visibility into value delivery weak or non-existent
Unintended consequences
Inability to manage complexities of delivery across multiple inter-
dependent teams
No insight into re-planning activity that maximizes value delivery

How do we do it in practice?
10
Culture
• Get executive-level decision making out of the weeds!
• Apply lean and agile principles to the process at all levels
• Change your idea about what Quality means
Organization
• Adopt a Programs of Projects (team-of-teams) infrastructure
• Establish a Program Management Team that orchestrates the cross-cutting work across Teams to
deliver value, not function
• Don’t forget the role of architecture -- the Enterprise Architecture is critical!
Planning
• Plan at the Program level to inform Team-based planning but leave the Teams alone!
• Plan for Business Releases comprised of content delivered in smaller iterations
• Review and adjust plans for each iteration based on feedback, changing business requirements
Execution
• Enable Teams to be efficient and effective by automating testing, release and deployment
• Enable the Program to be efficient and effective by ensuring visibility into progress to deliver
value to customers at the Business Release boundary

Agenda
Retrospective
11

Scaled Agile Framework (SAFe) in a Continuous Delivery model
SAFe best practices and
guidance based on lean
and agile principles apply
to all layers in a team-of-
teams infrastructure to
help enterprise
organizations focus on
improving efficiency and
effectiveness by
synchronizing the
alignment, collaboration
and delivery
http://scaledagileframework.com
12

Agenda
Retrospective
13

Our motivation: increase efficiency and effectiveness of our
continuous delivery process…
14
Pressures
Wasted time on low-value
activities
Feature delivery cycle time too
slow
No insight into ability to deliver
value
Improvements
Adoption of lean and agile
principles organization-wide
Portfolio-level planning on
business release boundary
Data persistence through
tooling for visibility, traceability,
reporting
But first, we had to address the hardest part 
Change the way we work!

Addressing the culture shift – Find our WOW! factor
“What if… ?”
15
Team Lead
I could clearly
map my team’s
work to high
priority business
themes?
I could get
visibility into
which work items
are proposed for
the next few
iterations?
What if we
could do this
with our own
tools??
Product/Release Manager
We could
streamline the
arduous internal
processes?
I could see which
items are at risk
across all of the
teams?
I could get status
without having to
ask for it?
I didn’t have to
spend my days
creating
spreadsheets and
PPTs?
Business Executive
I could see how we
are investing and
where I can re-
balance?
I could show
customers our
roadmap and
vision based on
real-time
information?
We had a great
example of
business planning
and IT execution
aligned with SAFe
to share with
clients?

Why SAFe?
• Not IBM! Independently developed
• Based on sound lean and agile principles applied
across all layers of an enterprise organization
• Well-defined
• Addresses issues current enterprises face today
It’s important to
our customers
• Consistent terminology that is well-defined (so we don’t
have to do that!)
• Standard framework known across the industry (so we
don’t have to prove the value!)
• Experts that can help
It’s important to
us
• By leading a SAFe-based transformation internally, we
have personal understanding of the challenges and
benefits specifically when applying our own tools to
address the issues
Lead by
example
16

Why SAFe to address the pressures of continuous delivery?
Manage
Scale
• We need to coordinate plans and delivery of
value across multiple Teams
Manage
Complexity
• We need to manage the development and
delivery of large complex solutions: Strategic
Re-Use, DevOps
Re-Plan
• We need the ability to quickly and easily make
trade-offs across the Program to maximize the
delivery of value to clients and to our business
Improve
• We must increase our efficiency and
effectiveness
• Adoption of Lean thinking from the Portfolio to
the Team is a requirement, not just an
interesting pursuit
17

SAFe Alignment and Extension Points
18
AreaofFocus

Strategic
Theme
Portfolio Epic
Timeline: 1-3 years
Program Epic
Timeline: Business Release
Feature (Capability)
Timeline: Quarterly Release(s)
Plan Items (Functionality)
Timeline: Quarterly Release
Stories/Tasks
Timeline: Sprint
Coping with Complexity
SAFe Extended
Business Planning Artifacts
(Portfolio/Solution Level)
Articulates investment priorities and decisions that
drive IT execution in support of the business
strategy
Solution Artifacts
(Cross-Product Level)
Identifies end-user capabilities
required to deliver value
Product
Artifacts
Defines work to
deliver
capabilities for
one or more
Features
Alignment of IBM Design Thinking with
Planning & Execution process
Capability Scenarios
Release Hills
User Activity
SAFe extensions
19

Portfolio Kanban Drives Epics into the Programs
RAW
IDEA BACKLOG
∞
Business
Release N+1
PORTFOLIO
BACKLOG
Business
Release N
Backlog
Triage
EVALUATION
QUEUE
free slot
50 WIP Review
ALM
PROGRAM
BACKLOG
PRODUCT
BACKLOGS
“small” product level item
triaged to Product Backlog
“large” product level item
to be evaluated
for Portfolio Backlog
Program
Kanban
Program
Portfolio
ProductCross
Product
Epic
(Business,
Architectural)
Cross-Product Portfolio Epic
“cracked” into ALM & Product level
Program Epics (on Backlogs) via
Program Kanban
Product
Release X
Backlog
Product
Release X
Backlog
Note: need to show a similar thing inc. Features
SPCPMs

PORTFOLIO
The Portfolio Kanban Planning Process
21

RAW
IDEA BACKLOG
∞
ANALYSIS QUEUE
Review (preliminary estimates) and Analysis (lightweight
business case) occur here
ANALYSIS
WIP
DRAFT - > SUBMITTED
Summary
Description
Business Benefit
Customer Benefit
Customer(s)
*Submitted Epics on RIB
SUBMITTED -> REVIEWED -> ANALYZING
Strategic Theme
User/Business Value (H,M,L)
Time Criticality (H, M, L)
Risk Reduction/Opp Enablement (H, M, L)
Job Size (S,M,L)
[Potentially] Affected Teams
*Triaged, Reviewed, Analysis Epics on EQ
ANALYZING -> READY
Affected Teams[s] Release Cycles (quarters)
Affected Teams[s] PM Estimates
Cost Estimate
Lightweight Business Case
*Approved Epics on Portfolio Backlog
Business Release N+1
PORTFOLIO
BACKLOG
Business Release N
Business Release “Next”
Portfolio Planning: Epic Kanban System
FUNNEL
The “capture” state, all new ideas
welcome
Portfolio
Epic [Draft]
Portfolio
Epic
[Reviewed]
Portfolio
Epic
[Analyzing]
Portfolio
Epic [Ready]
Portfolio
Epic
[Submitted]
Portfolio
Epic
[Approved]
Triage
Analyze
(PULL)
Triage Review
SPC
Analysis
Team
PMs
EVALUATION
QUEUE
free slot
50 WIP Self-Limiting
ROADMAP
These Epics have made it through the
Portfolio Kanban with “go” approval
Review
Analyze
(PULL)
22

Coping with Scale
23
20+ Teams
500 – 600 Resources
 3 major solutions
 11 “core” products
 5+ additional components

PROGRAM
The Program Kanban Planning Process
24

Challenge: Coping with Complexity
ALM Foundation CLM Lifecycle Project
* not all Products use Plan Items
** Design, Release Management
Product A – workitem 1
Product B – workitem 1
Product C – workitem 1
Product D – workitem 1
Product C – workitem 3
Product D – workitem 2
Portfolio Epic
Program Epic 2
Program Epic 1
Plan Item y
Plan Item* x
Feature 1
Feature 5
Feature 4
Feature 3
Plan Item 1**
Product RTC Repositories
Feature 2
tracks
tracks
tracks
tracks
tracks
child
child
child
child
child
child
Capability
Design
Artifacts
25

Challenge: ALM Foundation is actually the Portfolio
A “Program of Programs”
26
Capability
Teams
• Aligned with Value Streams
• Capability teams created to
deliver major cross-cutting
solutions within context of
Strategic Themes
• Transient, but could have multi-
year lifespan
Functional
Teams
• Doing work across all capabilities
• Persistent, never go away
• Represent non-development
teams:
• Design
• Architecture
• Test
 “Conceptual” ARTs – no code bits – for Foundation and each Capability

Success: Cadence is synchronized across the Portfolio
27
ALM Foundation Roadmap
2014 2015 2016
2015 Business Release
Capability Design Hills
2014 Q3 2014 Q4 2015 Q1 2015 Q2
2014 Q3 Quarterly Release
Week 1 2 3 4 5 6 7 8 9 10 11 12
Sprint S1 S2 RC1 RC2 RC3
Strategic Re-Use Capability Design Hills
Hill 1 Work in configurations with artifacts and links
Hill 2 Create and use product definitions
Hill 3 Track and report on configurations of engineering artifacts
Hill 4 Technical Foundation

Roadmap plans at various levels of granularity
28
 ALM Foundation Roadmap Plan for all Capabilities
 Capability Team Roadmap Plans for individual solutions
Our Teams contribute functionality to multiple different Capabilities (sub-
Programs), so this enables:
 Ranking of all Features within the context of the ALM Foundation Program based on
the capacity across the Portfolio
 Ability to re-plan broadly and re-balance resources across ALM Foundation directed
at specific capabilities based on feedback quarterly
 Provide a broad roadmap view across the Portfolio
 Enable capability teams to plan independently while still informing that broader
context

Complete Roadmap view with Features ranked by WSJF
29
Solution Features
informed by IBM
Design Thinking
Proposed
Roadmap
WSJF for
ranking
Visibility into work
across all Strategic
Themes

Agenda
Retrospective
30

Challenges
Identifying the
right “kidney”
• Finding the right
resources, Teams,
Programs,
Strategic Themes
for optimal
execution
Writing good
Epics and
Features
• User grammar or
not?
• Coarse-grained or
fine-grained?
Reaching
“Steady State”
• Really getting rid
of spreadsheets
• Identifying the right
metrics
What’s been hard?
31

Initial Release Planning Retrospective
32
“…this has allowed CLM and SSE SVT
to do all their planning in one project,
using a common process, which has
great benefits”
“Interlock between Design &
Epics/Features has helped Feature
elaboration”
“The Feature level is exactly the level
that SVT needs to be testing against”
“Having a view of the plans at the
business tactic level”
“Ability to link Features to Product Plan
Items has helped identify gaps”
“Ability to create a Capability Roadmap
has gone some way towards developing
an overall roadmap”
“Ability to capture MVP has helped team
identify and prioritize Issues and Risks”
“Missing sizing fields at product level
and solution level. Results in using
Spreasdsheets”
“We need to find the right way to
manage the 24 month roadmap vs just
the current quarter”
“Inconsistences at the interface
between Program and Product (e.g. not
all teams use Plan Items) makes
planning and reporting very difficult”
“Architecture work and explorations are
not adequately represented”
“We need development for each of the
product teams to totally buy in and
standardize on one approach.. ”
“Need better clarity on what work should
be at the ALM level versus the Product
Level”
TheUPside…
TheDOWNside…
The AHA! Moment…
“We need a more
rigorous ranking
process!”

Program
 Originally started with Program, then realized we
had to really address Portfolio first
 Now need to return to Program and introduce the
same maturity in our planning process
 Realized that our ALM Foundation Program is
actually Portfolio!
Current Status
33
Portfolio
 Portfolio planning process pretty well “baked”
 In recent planning meeting, we finally got some
positive feedback…
This
$#&%*
works!

INFRASTUCTURE & TOOLING
The Details
34

The Tooling
35

The Portfolio Epic
36
Representation of
Kanban planning
activities
WSJF as part of
Triage
Lightweight
Business Case
content

The Feature
37
Alignment to
Strategic Theme
Planning &
Execution
information
WSJF & Team
Impact

The Schema
38

Transforming How We Deliver Value: Agility at Scale

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (18)

Similar to Transforming How We Deliver Value: Agility at Scale

Similar to Transforming How We Deliver Value: Agility at Scale (20)

More from TechWell

More from TechWell (20)

Recently uploaded

Recently uploaded (20)

Transforming How We Deliver Value: Agility at Scale