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 ∙ [email protected] ∙ www.sqe.com

mailto:[email protected]

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 [email protected]

mailto:[email protected]


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 Releases Databases

Systems of Engagement (SoE) Apps Rapid Releases AppStore

Inte

grat

ion

Test

Monitor and Optimize

Develop and Test

Web Apps Frequent Releases

Production Environment

Databases

Syst

ems

of In

tera

ctio

n (S

oI)

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

http://scaledagileframework.com/


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

Area of Focus


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

Product Cross 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

SPC PMs


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”

The

UP

side

… The D

OW

N side…

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

Software