In this talk we discuss some of the best practices we have learned for successfully Launching an ART. We discuss how Rational Team Concert (#RTC) can be used to help coordinate the various team activities such as use story analysis, portfolio program and sprint planning, and communicating with the PPM, Agile program and team. The presentation is from the 2015 #ibminterconnect Conference #feggreed2021 DCB-3094 Scaling Agile Launching a SAFe Agile Release Train using Rational Team Concert – Lesson Learned

1. © 2015 IBM Corporation
DCB-3094 Scaling Agile
Launching a SAFe Agile Release Train
using Rational Team Concert – Lesson Learned
Reedy Feggins, PMP
WW Solution Architect,
SAFe SPC, CSM
DevOps Continuous Delivery SME

2. 1
Notices and Disclaimers
Copyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or
transmitted in any form without written permission from IBM.
U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with
IBM.
Information in these presentations (including information relating to products that have not yet been announced by IBM) has been
reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM
shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY
WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM
THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS
OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of
the agreements under which they are provided.
Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without
notice.
Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are
presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual
performance, cost, savings or other results in other operating environments may vary.
References in this document to IBM products, programs, or services does not imply that IBM intends to make such products,
programs or services available in all countries in which IBM operates or does business.
Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not
necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither
intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.
It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal
counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s
business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or
represent or warrant that its services or products will ensure that the customer is in compliance with any law.

3. 2
Notices and Disclaimers (con’t)
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products in connection with this
publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.
IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to
interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED,
INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE.
The provision of the information contained herein is not intended to, and does not, grant any right or license under any
IBM patents, copyrights, trademarks or other intellectual property right.
•IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document
Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand, ILOG,
Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®,
pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®,
QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®, urban{code}®, Watson, WebSphere®,
Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation,
registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other
companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at:
www.ibm.com/legal/copytrade.shtml.

4. What is Scaled Agile Framework
(SAFe)

5. What is SAFe?
• A proven, publicly-facing framework for applying
Lean and Agile practices at enterprise scale
http://scaledagileframework.com/
Synchronizes
alignment,
collaboration and
delivery for large
numbers of teams
Synchronizes
alignment,
collaboration and
delivery for large
numbers of teams
CORE VALUES
1. Program Execution
2. Alignment
3. Code Quality
4. Transparency
4
Leffingwell et al. © 2014
Scaled Agile, Inc.

6. Framework Creator: Dean Leffingwell
Founder and CEO
ProQuo, Inc., Internet identity
Senior VP
Rational Software
Responsible for Rational Unified
Process (RUP) & Promulgation
of UML
Founder/CEO
Requisite, Inc.
Makers of RequisitePro
Founder/CEO
RELA, Inc.
Colorado MEDtech
Founder and CEO
ProQuo, Inc., Internet identity
Senior VP
Rational Software
Responsible for Rational Unified
Process (RUP) & Promulgation
of UML
Founder/CEO
Requisite, Inc.
Makers of RequisitePro
Founder/CEO
RELA, Inc.
Colorado MEDtech
5Leffingwell et al. © 2014
Scaled Agile, Inc.

7. Portfolio

10. Strategic Themes
• Connects enterprise business strategy to Portfolio Vision
• Influence ART budgets, Program Backlogs and Epics
Strategic Themes
• Connects enterprise business strategy to Portfolio Vision
• Influence ART budgets, Program Backlogs and Epics

11. Budgets
• Explains why we fund ARTs
• Go “Beyond Project Cost
Accounting”
Budgets
• Explains why we fund ARTs
• Go “Beyond Project Cost
Accounting”

12. Kanban system
• Used to clarify the flow and eliminate the
overloaded “backlog” state that often can
occur
Kanban system
• Used to clarify the flow and eliminate the
overloaded “backlog” state that often can
occur

13. Business Epic Kanban System
SPC Product Management Design Architects Development
Leffingwell et al. © 2014
Scaled Agile, Inc.

14. Value Streams
• Value Streams are the primary elements of Portfolio Vision
• Multiple Agile Release Trains (ARTs) can make up a Value Stream
• Portfolio Epics are typically cross-cutting ARTs
• Agile Release Trains are directly funded by Budgets
• Portfolio Epics flow left to right through the Kanban system to the
portfolio backlog, and then into implementation
Value Streams
• Value Streams are the primary elements of Portfolio Vision
• Multiple Agile Release Trains (ARTs) can make up a Value Stream
• Portfolio Epics are typically cross-cutting ARTs
• Agile Release Trains are directly funded by Budgets
• Portfolio Epics flow left to right through the Kanban system to the
portfolio backlog, and then into implementation

15. Portfolio Backlog NFRs
• NFRs may span across multiple
Value Streams and Release Trains
• Example: PCI Compliance
Portfolio Backlog NFRs
• NFRs may span across multiple
Value Streams and Release Trains
• Example: PCI Compliance

16. Coordination
• Required for Value Streams with multiple ARTs
• Often done at the Value Stream level
• Many large organization must “bundle” systems and
therefore cannot be evaluated at the Train level
Coordination
• Required for Value Streams with multiple ARTs
• Often done at the Value Stream level
• Many large organization must “bundle” systems and
therefore cannot be evaluated at the Train level

17. Lean-Agile Leaders
• Principles of Lean-Agile Leadership
• Role of Software Development Manager
described
Lean-Agile Leaders
• Principles of Lean-Agile Leadership
• Role of Software Development Manager
described

18. Metrics
• Split between Portfolio and ART
• New Portfolio Metrics for tracking
Epics
• ART metrics contain Program and
Team
Metrics
• Split between Portfolio and ART
• New Portfolio Metrics for tracking
Epics
• ART metrics contain Program and
Team

19. Program and Team
Agile Release Train
(ART)

20. Program / Team Level
• The Agile Release Train (ART) is a single layer allowing the agile program
and agile teams to work together
• The Program Increment (PI) is used to deliver value
• The release object fully decouples Development from Release
Program / Team Level
• The Agile Release Train (ART) is a single layer allowing the agile program
and agile teams to work together
• The Program Increment (PI) is used to deliver value
• The release object fully decouples Development from Release

21. Program Epics
• Some Epics originate locally
• Must be big enough to require
approval for spend
Program Epics
• Some Epics originate locally
• Must be big enough to require
approval for spend

22. Release Object
• Teams build Working Software
• “System Increment” allows us to measure
progress of the ART
• “Releasable solution” may require
additional work and artifacts
Release Object
• Teams build Working Software
• “System Increment” allows us to measure
progress of the ART
• “Releasable solution” may require
additional work and artifacts

23. IP Sprint
•Validation (was Hardening) activities
are moved to the new Release Object
•If decoupled from Releases, IP sprints
provide more time for sharpening the
tools
•If not, Validation can still happen there
IP Sprint
•Validation (was Hardening) activities
are moved to the new Release Object
•If decoupled from Releases, IP sprints
provide more time for sharpening the
tools
•If not, Validation can still happen there

24. Code Quality
• “Agile Architecture
• Continuous Integration at the system level
• Test-First starts introduces the four quadrant Agile testing matrix
Code Quality
• “Agile Architecture
• Continuous Integration at the system level
• Test-First starts introduces the four quadrant Agile testing matrix

25. How IBM Support
SAFe

26. 25
How IBM support SAFe?
IBM supports organizations looking to scale agile & lean principles to the
enterprise by providing out of the box capabilities to establish a SAFe-
based environment, with fit-for-purpose dashboards and reports, to drive
a project from vision to production at the team, program and portfolio levels
in hybrid cloud and heterogeneous environments
25
http://scaledagileframework.com
Leffingwell et al. © 2014
Scaled Agile, Inc.

27. 26
How does IBM support SAFe?
26
Process templates to simplify
project configuration aligned with
SAFe concepts, vocabulary and
best practices
Reports and dashboards aligned
with SAFe guidance for providing
insight into measured
improvements
Process mentoring at the click of
a button to keep teams on track
Integrations that supports agile
teams working in hybrid cloud or
third-party tooling environments
Support for both agile and
traditional IT as well as large
regulated IT and systems
environments
Leffingwell et al. © 2014
Scaled Agile, Inc.

28. 27
IBM DevOps built on SAFe
27
SAFe
Market-leading process framework for scaling lean and across the
enterprise,
IBM DevOps Framework & Tooling
Supports the continuous delivery model through an open-standards-based
tooling platform
Steer Dev & Test Deploy Operate
Apply Lean & Agile Principles across the end-to-end DevOps lifecycle

29. 28
IBM’s SAFe Support - RTC instances for SAFe
Portfolio, Programs and Teams
Program (RTC Project Area)
Rational Team Concert*
Programs (RTC Project Areas)
Rational Team Concert*
Portfolio and Program: Use Rational Team Concert, (or Rational CLM) solution to
address the needs for high quality and regulatory compliance
Rational Team Concert*
Rational Team Concert*
Agile Release Train (RTC Project Areas)

30. 29
Lesson Learned
1

31. 30
Establish SAFe environment
Plan the Release
Deliver the first Program Increment
JKE (Portfolio)
JKE Personal Banking (Program)
Mainframe, Mobile (Teams)
Use RTC to help Establish a SAFe Environment
30
Product Manager
Program Manager
Portfolio Backlog
Product Owner
Mobile Team using RTC to manage product
development
dependencies
Scrum Master
Scrum Master
Mainframe Team using RTC to manage
product development

32. 31
Organize Portfolio and Programs Epics using
RTC instances
Portfolio and Program:
Use combination of Rational Doors
Next Generation and Rational Team
Concert to address the needs at this
level
Agile Release Train:
Use Rational Team Concert (single or multiple project areas) to address the needs for high
quality and regulatory compliance

33. 32
Organize Portfolio and Programs Epics into a
multiple RTC instances
Program (RTC Project Area)
SAFe enabled
Rational Team Concert
Programs (RTC Project Areas)
Rational Team Concert*
Rational Team Concert*
Program Coordination using a
singe RTC Project area
Portfolio
Doors Next Generation (DNG)
Each ART uses a separate
RTC Project Area
Each ART uses a separate
RTC Project Area

34. 33
Smaller Organizations can start with a single
RTC and Team Areas
Program (RTC Project Area)
SAFe enabled
Rational Team Concert
Singe RTC Project
Area with multiple
Team Areas.
One for each Agile
Release Train
Portfolio
Doors Next Generation (DNG)
Team Area 1
Team Area 2
Team Area N
Singe RTC Project
Area with multiple
Team Areas.
One for each Agile
Release Train

35. 34
Lesson Learned
2

36. Right Size the ART
Product Management team is
responsible for managing the Vision,
Roadmap, and the Program Backlog
• SAFe provides a solid structure for implementing broad program
initiatives while maximizing flow for the majority of product development
happening locally
Organization that operate at
scale must have an
Enterprise Architect to
drive technology direction
across all programs / ART’s.
Leffingwell et al. © 2014
Scaled Agile, Inc.

37. Effective Agile Release Trains typically
consist of 50 - 125 people
• Dunbar’s number “…a suggested cognitive
limit to the number of people with whom one
can maintain stable social relationships”
• Empirical evidence. Beyond 125, logistics
and inter-team dependencies are more
difficult. Alignment is harder to achieve.
• Queue size and WIP. Larger numbers of
teams create more dependencies (per team),
longer delay queues, and more work in
process
Leffingwell et al. © 2014
Scaled Agile, Inc.

38. How big will your ARTs eventually become

39. How big will your ARTs eventually become
Fast customer feedback
Fixed, reliable cadence
Program Epics and Features are
used to implement the
Driven by Vision and Roadmap
Lean, economic prioritization
Frequent, quality deliveries

40. 39
Lesson Learned
3

41. Team (Product) Execution
Responsible for Product content Independent, Self-Governing
Program Planning
Responsible for Program
content required to execute
vision
Business Release Train “Engineer”
Ensures value is delivered to
the business and to
customers
Portfolio Planning (SPC)
Responsible for defining vision
and “what gets built”
“The Bank”
Establishes initial Business
Release content
Release Planning must be both top-down and
bottom-up
In charge of technical decisions

42. Strategic Themes Influence the Portfolio Vision
Strategic Themes are the primary inputs into the Portfolio vision and serve as an
economic decision making framework for the portfolio,
List of active
Strategic Streams
DNG provides ability to quickly see details for any
of the Strategic Streams, including Status

43. Create Business Needs
Use Kanban and WIP
limits to help evaluate
Business Needs

44. Identify initial set of Strategic Themes
Its often easier to first capture
and organize Business
Needs and later “reverse
engineer” the Strategic
Themes

45. Strategic Theme – Example from DNG

46. The Value Stream must be clearly defined
Ensure the PPM defines
a minimal number of
value streams
Ensure the PPM defines
a minimal number of
value streams

47. All SAFe Portfolio Epic Value Statements

48. Portfolio Epic Value Statements

49. Each Portfolio Epic must have a Value Statement
We use Rational Doors
Next Generation (DNG) to
support some of the
Portfolio level constructs

50. SAFe Portfolio level
SAFe Recommended Views
• All Features
• All Lifecycle Scenarios
• All Lifecycle Scenarios in
• Playback or Under Review
• All SAFe Portfolio Epic Value Statements
• All SAFe Strategic Themes
• All SAFe Value Streams
• All Stakeholder Requests
• All Supplementary Requirements
• All Terms
• PLE Act -> Scene -> Feature
• Satisfying Stakeholder Requests (Traceability
Tree)
• Scene Implementation Traceability
We use Rational Doors Next
Generation to support the
Portfolio level constructs

51. 50
Lesson Learned
4

52. Lesson 3 – Coordinate Reqts & Planning at
Multiple Levels
(Portfolio & Program Levels)
Product A – Story 1
Product B – Story 156
Product C – Task 132
Product A – Task 287
Product A – Task 343
Product D – Story 142
Product A – Story 463
Product B – Story 201
Product B – Story 300
Product C – Story 332
Product D – Story 245
Business
Tactic
Portfolio
Epic 2
Portfolio
Epic 1
Story
Story
Feature 1
Feature 5
Feature 4
Feature 3
Story
Products (Team Level)
Feature 2
tracks
tracks
tracks
tracks
tracks
child
child
child
child
child
child
51
Doors Next
Generation Artifacts
RTC (IBM Solution for
Scaled Agile Framework)
RTC (Agile Release
Train)
Program
Epic 101
Program
Epic 102
Program
Epic 231
Program
Epic 443

53. Guidelines for Epics, Feature and Stories
Description Responsibility Sizing Testable
Portfolio
Epic
Strategic Product
BIG, hairy, audacious,
initiatives providing competitive
advantage
Epic Owner
PPM Team
Span strategic planning
12‐18+ months.
Not sized, controlled by %
investment
No
Program
Epic
Bold, Impactful,
marketable
differentiators
Program / product
mgmt (PPM)
Business owners
Often require 6‐12 months to be
delivered
Sized for planning purposes
Maybe
Feature Short, descriptive, value delivery
and benefit oriented statement.
Customer and marketing
understandable
Product manager
Product owner
Sized to fit with in an internal
release
Often divided into stories
(Points)
Yes
Story Atomic. Sized for team and
detailed user understanding
Product Owner
and Team.
Fits in a single iteration.
(story points.)
Yes
http://scalingsoftwareagility.files.wordpress.com/2007/03/a-lean-and-scalable-requirements-information-model-for-agile-enterprises-pdf.pdf
SAFe builds on existing Agile team
practices in order to scale:
• Backlogs,
• Release and Sprint Planning
• Test Automation
• Deployment Automation
SAFe builds on existing Agile team
practices in order to scale:
• Backlogs,
• Release and Sprint Planning
• Test Automation
• Deployment Automation

54. Portfolio Kanban
Use RTC Kanban capabilites to identify
“approved” Business and Architecture
Epics for upcoming release planning

55. Establishing a Cadence for the ARTs
• Prior to kicking off the ART, the program calendar should be set for the
next year
RTC allows each ARTs
to define a multi-year
program calendar
RTC allows teams to define
plans and tasks to manage both
Program Level Calendar
• Release Planning Meetings
• PSI Demos
• Inspect & Adapt Workshops
Team Level Calendar
• Sprint Planning Meetings
• Sprint Demos
• Sprint Retrospectives

56. Roadmap Organized by Product (value stream)

57. Planning Features, Drilldown for Details

58. Dashboards Communicate status At-a-Glance
Program Epics and Features are
used to implement the
Driven by Vision and Roadmap
Lean, economic prioritization
Frequent, quality deliveries

59. Multi-Release Planning

60. 59
Lesson Learned
5

61. Use RTC to help prepare for Release Planning
Meeting
Input: Business and technology vision, milestones, and top ten features
Output: PSI Objectives and Program Board
Leffingwell et al. © 2014
Scaled Agile, Inc.

62. Prepare SAFe Portfolio Content
In preparation for release planning, leadership creates a series of
briefings to set context
Executive Briefing State of the
business and upcoming
objectives
Product Vision Briefing(s)
Vision and top 10 features
Architectural Vision Briefing
Vision for architecture, new
architectural epics, common
frameworks, etc.
Development Context Changes
to standard practices, new tools
and techniques,

63. Planning: the Cadence for the ART
• Prior to kicking off the ART, the calendars should be set
RTC allows teams to define
plans and tasks to manage
both
Program Level Calendar
• Release Planning Meetings
• PSI Demos
• Inspect & Adapt Workshops
Team Level Calendar
• Sprint Planning Meetings
• Sprint Demos
• Sprint Retrospectives
RTC allows teams to define
plans and tasks to manage
both
Program Level Calendar
• Release Planning Meetings
• PSI Demos
• Inspect & Adapt Workshops
Team Level Calendar
• Sprint Planning Meetings
• Sprint Demos
• Sprint Retrospectives

64. Summary
1. Establish a SAFe environment using RTC
• Right size the ART
• Release Planning must be both top-down and
bottom-up.
• Coordinate team activities across multiple levels
• Use RTC to help prepare for
conducting an effective
Release Planning

65. Questions?

66. Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee
Portal to complete your session
surveys from your smartphone,
laptop or conference kiosk.