Innovate agl 1601-case-study-rtc-sa-fe

Case Study: Can Scaling Agile & RTC really be SAFe? Yes! Here’s how…

Kim Werner, Blue Mercury Consulting AGL-1601

© 2013 IBM Corporation

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

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!

[email protected] Twitter: @kwernerus

§  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

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

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

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

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

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

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

SAFe: Content Governance

11

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

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

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

RTC Customizations

15

SAFe Template RTC Customizations

§  New workitem types needed to be created: – Milestone

(for Releases)

– Feature

– Recursive Epic (for Themes)

– PlanRisk & Risk Action

16

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

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

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

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

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

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

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

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

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

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

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

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

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

Metrics

30

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

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

Reporting Metrics – Don’t Forget those Burndowns!

§  Burndowns are yet another holistic view at a Program Level and they scale as well

33

Results

§  150 RTC Eclipse clients deployed

§  Integration with RRC

§  Governance adherence

§  Predictive Agile planning out to 18 months

§  Unified Shared Vision driving Architecture

§  Agile engineering practices

§  RTC SCM

34

35

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

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.

38

Acknowledgements and disclaimers

© Copyright IBM Corporation 2013. All rights reserved. –  U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

IBM, the IBM logo, ibm.com, Rational, the Rational logo, Telelogic, the Telelogic logo, Green Hat, the Green Hat logo, and other IBM products and services are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml If you have mentioned trademarks that are not from IBM, please update and add the following lines: [Insert any special third-party trademark names/attributions here] Other company, product, or service names may be trademarks or service marks of others.

Availability: References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates.

The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are provided for informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to any participant. While efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is provided AS-IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this presentation or any other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.

All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing contained in these materials is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results.

39

© Copyright IBM Corporation 2013. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.