THE JOURNEY FROM WATERFALL TO AGILE Beth Beck Director of Product, Syncada

1

2

When to Use •  Waterfall: The sequential approach

•  When to use •  When there is a clear picture of what the final product should be. •  When clients won’t have the ability to change the scope of the project once it

has begun. •  When definition, not speed, is key to success.

•  Agile : The incremental approach. •  When to use

•  When rapid production is more important than the quality of the product. •  When clients will be able to change the scope of the project. •  When there isn’t a clear picture of what the final product should look like. •  When you have skilled developers who are adaptable and able to think

independently. •  When the product is intended for an industry with rapidly changing

standards.

3

Company History • U.S. Bank PowerTrack – first transaction March 31,1998 • Syncada – formed as joint venture between U.S. Bank

and Visa on July 1, 2009 • U.S. Bank CPS – re-absorbed Syncada on September 1,

2013

4

Electronic Processing

Exception Resolution

Electronic Settlement

Analytics Supply Chain Efficiency

Collaborative Interface

Robust electronic processing and audit engines maximize opportunities for efficiency and straight-through-processing (STP).

Organization under Waterfall • Component based development teams

•  Development •  Business Analysts •  QA •  PMO

•  Technical Product Managers assigned to components • UX Team: New in August 2011 • Market Product Managers

5

Why Change • New management

•  New CIO joined August 2011 •  New Global Head of product joined Sept 2012

•  Large projects with long timeframes •  Frustration on actual deliverables and correlation of money spent to

value delivered

•  Large projects with too many requirements •  Anxiety around “stuffing” a lot of requirements into a project hoping

to get something done

• Delays •  Disappointment when the project delayed, and requirements are

dropped or changed mid-stream

6

Timeline to Agile •  Introduction to Agile: May 2012

•  Large group presentation intended to explain agile •  Agile Start: Post presentation two teams were to jump into agile

• Hiring an Agile Coach: December 2012 • Agile Application Lifecycle Management Assessment: Jan

2013 •  How far had we gotten between May and December (not very far)

• Agile Champions Team Formed: Jan 2013 •  Management and cross functional group to ensure agile adoption

moved forward • Agile Teams formed: Re-alignment within business: Feb

2013 •  Shifting the right people into the right jobs

7

Training •  December 2012: External Training

•  Scrum master training •  Product owner training

•  January 2013: Agile Coach •  Using TFS and Urban Turtle

•  February and March 2013: Agile Coach •  Scrum Ceremonies

•  Release planning •  Sprint planning •  Daily Scrum •  Sprint Review

•  Agile story writing •  Agile testing standards •  Working/grooming product backlog

8

Current Organization • Component based teams under U.S. Bank Development

organization •  Developers •  System Analysts •  QA •  PMO

• Product Owners under Operations • Product Managers and UX under Product

9

10

Market/Program  Research  &  Planning Enterprise  Product  

Roadmap

Collaboration  Points Map  AlignmentActivities  and  

Responsibilities

Release  Map

Story  Map

Enterprise    Technical  Architecture

Stakeholder/Customer

Agile  Testing

Agile  Development

Release  Planning

Backlog  Grooming

Story  Identification  and  Elaboration

Story  Writing

Acceptance  Criteria

Detailed  Requirement  Clarfication

Logical  Data  Modeling

Data  Mapping

System  Analysis

System-­‐to-­‐system  Integration  &  Interfaces

State  Management  and  Modeling

Strategic  Partnership  Management

System  Process  Workflow

Sprint  Planning

Product/Market  Directors

Group  Product  Owner

Team  Product  Owner

Systems  Analyst

User  Experience  Design

Product  Dependency  Management

Backlog  Management

Group  /  Portfolio  Backlog

Team  Backlogs

Challenges • No coach at onset

•  Initial two teams argued about how this should work based on perception or past experience elsewhere

• New Roadmap formats and approach •  Previous roadmap had mixed levels of requirements and market

needs • Staff moved to new roles

•  Business analysts became product owners or system analysts •  Technical product managers became product or product owners

• Challenges in new roles •  Project managers not suited to agile – remained project focused,

not team focused •  Loss of staff at conversion left knowledge holes

• Changeover or Transition Time

11

Changes to Requirements • Story Writing

•  Shifting from writing long document to writing stories took time to adapt

•  Balance between too much and too little detail •  Stories had to sometimes be broken into smaller stories

•  Tool •  Urban Turtle was selected as tool – learning curve •  Creating right level of visibility to group requirements and tie back

to roadmap

• Visibility •  Broader visibility to all team members – and out further than with

waterfall •  Technical debt and infrastructure work became much more visible

12

Changes to Planning • Sprints

•  Planning poker – the point system •  Teams had challenges learning how to assign points •  Teams did not assess points in similar fashion across teams

•  Success and failures in initial sprints – too much, too little, just right

• Release Planning •  Changes to current product release were minimal initially

13

Changes to Teams •  Less than Good Stuff

•  New roles and expectations of collaboration – not order taking •  How to complete stories within two week sprints •  Scrum masters and product owners were on multiple teams •  Cross team coordination – ensuring that needs between teams were included in sprint planning

at right times = Scrum of Scrums •  Small teams and time off create sprint delays

•  Good Stuff •  More visibility to Stories (enhancements) that are being developed by the team •  Stories are discussed with all team members so everyone is on the same page during the

development cycle •  Better predictability as to when Stories (enhancements) will be completed •  Better team interaction and more conducive to adjusting to new priorities •  All team members have visibility to Story prioritization •  Story completion goals are committed to by the team •  QA is testing earlier in the process •  Gaps get added to the back-log immediately by anyone on the team and addressed in the next

sprint •  The teams can be very efficient when focusing on only a few stories in a given sprint. With

smaller teams, the feedback loop can be shortened and changes can be made very quickly.

14

Management Expectations •  Less than Good

•  You should now be able to develop faster •  Learning curve not recognized •  Coding faster- not realistic

•  You should still be able to commit to an absolute date •  Release Planning meetings across the entire team needed to give

the team a better view of upcoming Product roadmap items.

• Good •  Greater confidence in reporting to management when enhancements will

be delivered to the market •  Better visibility to specific deliverables •  Better traceability to roadmap

15

Sta

ges

Cer

emon

ies

Arti

fact

s

Elaboration Planning Development Customer Release

Plan Release

Release to Customers

Product Initiatives and Supporting Documentation

Story Maps (visual view of decomposition of an initiative into Business Epics and User Stories)

• Decompose the initiative into a Story Map and Business Epics

• Business Epic definition: • Product Area • Delivery Qtr • Initial sizing

Define Release

• Business Epics entered into SharePoint

• Go/No Go

• Next 2 qtrs of tgt release date on Business Epic level

• Complete 1 qtr prior to dev

Company Strategy and Product Roadmap

User Stories Themes

Development Epics

- Stored/managed via SharePoint lists and libraries - Stored/managed via Urban Turtle/TFS

• Prioritize epics/stories into the backlog

• Coordinate work between and among components

• Monitor progress toward roadmap/commitments

Software Release

Release to Production

• Meets requirements

• Fully tested

• Go/No Go!

• Build release notes

• Update documentation

• Final pre-release testing

• May be combined with Customer Release

• Complete release checklist

• Client communication

• Warranty work

Stakeholder Checkpoint

(Story Sign off)

Gates are managed via the bi-weekly Prod Mgmt/Dev Summit

Ideation

Create Initiative

• Add idea to the Initiative list in SharePoint

• Confirm Mkt Oppty Qtr and initial sizing

• Attach supporting docs • Complete 2 qts prior to dev

• Company strategy

• Early development of product ideas. Product definition docs, Customer SOWs, Risk memos, etc

• Set Mkt Oppty Qtr and assign relative size

Agile Process

• Translate Business Epics into development Epics in Urban Turtle

• Create detailed stories

• Revise level of effort

• Coding/testing via sprints

• Acceptance testing

Stakeholder Checkpoint

(UAT Sign Off)

Business Epics

Ideation In Progress Complete Business Initiatives

Business Epics

Agile Requirement Lifecycle 16

Reading Maps

17

Using Product Maps • Pictures deleted due to proprietary information

•  Powerpoint of Roadmap to customers – high level column for each quarter

•  Sharepoint list of Initiatives and delivered units starts to break down the deliverables and which team is to deliver

•  Urban turtle view shows stories in a granular fashion – and while they can be viewed in a tree fashion it gets a bit overwhelming to understand the connections

•  Story map – a mind map of the stories in an organized fashion that allows for some visualization not only of scope but relatedness of the pieces

18

Customer Release Planning

Agile Governance Framework

19

Por

tfolio

Pro

gram

Team

Investment Themes P

ortfo

lio B

ackl

og

Initiatives

Q1 Q2 Q3 Q4

Company Roadmap

User Stories

Initiative to Epic Elaboration

Product Development

Steering

Epic to User Story Planning

Story / Mind Maps

Team

Bac

klog

s

Software Release

Platform Architecture

Development

Testing

Product Development

Summit

Agile Teams

Level Oversight

Technology Infrastructure

Product Strategy

O & T Efficiency

Prioritization

Pro

gram

Bac

klog

Bus Epics

Portfolio Level

20

§  Investment Themes - transparency as to current and forecasted Development capacity dedicated/available to: •  Roadmap driven development •  Custom work •  Break fix and maintenance activity

§  Single prioritized view of roadmap and product backlog •  Customer feedback, operational efficiencies, technology

infrastructure, strategic development •  Quarterly Steering Group

–  Validate Investment Themes –  Capacity forecasting (surplus or deficit) –  Prioritize Business Initiatives –  Refine Product Development Roadmap –  Roadmap escalations –  Initiative level Change Control

Program Level

21

§  “Conducting the release train” §  Product Development Summit

•  Group Product Owners, Team Product Owners, Scrum Masters

•  Frequency: Every other week •  Objectives:

–  Release pipeline checkpoint and review –  Review cross-team dependencies –  Business Epic prioritization – within Business Initiatives –  Business Epic level Change Control

Team Level §  Clearly defined roles for approval of software release into

Production environment §  Dashboard Review •  Attendees: Development Group Managers, Team Product

Owners, Scrum Masters •  Frequency: Every other week •  Objectives:

–  “Scrum of Scrums” – Software release checkpoints – Release/Team level change control

Next Steps • Continue to refine the governance framework

•  New changes moving back to U.S. Bank §  Appropriate collaboration and priority decision points §  Artifacts used and reviewed in decision making §  Balance between market agility and priority focus

• Continue to improve the level of visibility •  Product backlogs not yet visible to operations •  Improve the publishing of roadmaps, story maps and backlogs

through Sharepoint

• Continue to refine the interaction between group product managers and product owners •  Resources in product have changed considerably over the last 6 months

From Where to Where Waterfall Agile Result Level 1’s Product concept Simpler to understand

expectations Level 2’s Stories Requirements no longer buried

and missed Full Wireframes UI Framework with

simpler wireframes Repeatable UI widgets deployed to decrease UX and development time

Full project estimates

Story points Early examination of suspect areas

Level document review meetings

Sprint planning More focused on work than document

Follow on review meetings

Daily scrum At the moment answers

Over the wall Daily visibility No more vague progress updates Verbal Visual Use of story maps

24

References •  Living in an Agile World- Pragmatic Marketing article/deck

•  http://mediafiles.pragmaticmarketing.com/pdf/living_in_an_agile_world.pdf

•  Ten Year Agile Perspective •  http://msdn.microsoft.com/en-us/library/hh350860.aspx

•  eBook: Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams by Greg Cohen

•  Silicon Valley Product Group Newsletter •  http://www.svpg.com

•  Scaled Framework visuals •  http://scaledagileframework.com/

•  Product Ownership blog •  http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-

nutshell

25

26

QUESTIONS? sage.eabeck@gmail.com

27