This document discusses the journey of a company transitioning from a waterfall development process to an agile development process. Some key points: - The company initially tried introducing agile in 2012 but did not make much progress until hiring an agile coach in late 2012 and forming an agile champions team in early 2013. - The transition involved reorganizing teams, training staff in agile practices, and shifting roles like business analysts becoming product owners. It took time for people to adapt to their new roles and responsibilities. - Challenges included staff adjusting to writing user stories instead of long requirements documents, estimating story points consistently across teams, planning releases, and managing expectations around faster delivery from management.

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

2. 2

3. 3
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.

4. 4
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
Robust electronic processing and audit engines maximize opportunities for efficiency and
straight-through-processing (STP).
Electronic
Processing
Collaborative
Interface
Exception
Resolution
Electronic
Settlement
Analytics
Supply Chain
Efficiency

5. 5
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

6. 6
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

7. 7
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

8. 8
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

9. 9
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

10. 10
Collaboration
Points
Product/Market
Directors
Group
Product
Owner
Activities
and
Responsibilities
Market/Program
Research
&
Planning
Strategic
Partnership
Management
User
Experience
Design
Product
Dependency
Management
Backlog
Management
Enterprise
Product
Roadmap
Release
Planning
Stakeholder/
Customer
Map
Alignment
Story
Identification
and
Elaboration
Release
Map
Group
/
Portfolio
Backlog
Story
Map
Backlog
Grooming
Sprint
Planning
Team
Product
Owner
Story
Writing
Agile
Testing
Agile
Development
Team
Backlogs
Acceptance
Criteria
Detailed
Requirement
Clarfication
Logical
Data
Modeling
Data
Mapping
Systems
Analyst
System
Analysis
System-­‐to-­‐system
Integration
&
Interfaces
State
Management
and
Modeling
System
Process
Workflow
Enterprise
Technical
Architecture

11. 11
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

12. 12
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

13. 13
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

14. 14
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.

15. 15
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

16. 16
Agile Requirement Lifecycle
Business Initiatives
Ideation
In Progress
Complete
Stages
Business Epics
Ideation
Elaboration
• Company strategy
• Early development of
product ideas. Product
definition docs, Customer
SOWs, Risk memos, etc
Ceremonies
• Set Mkt Oppty Qtr and
assign relative size
Planning
• Decompose the initiative into
a Story Map and Business
Epics
• Business Epic definition:
• Product Area
• Delivery Qtr
• Initial sizing
Development
• Translate Business Epics
into development Epics in
Urban Turtle
• Coding/testing via sprints
• Build release notes
• Acceptance testing
• Client communication
• Update documentation
• Warranty work
Stakeholder
Checkpoint
(Story Sign off)
Agile
Process
• May be combined with
Customer Release
Stakeholder
Checkpoint
(UAT Sign Off)
Create
Initiative
Define
Release
Plan
Release
• Add idea to the Initiative list
in SharePoint
• Business Epics entered into
SharePoint
• Prioritize epics/stories into
the backlog
• Meets requirements
• Confirm Mkt Oppty Qtr and
initial sizing
• Go/No Go
• Coordinate work between
and among components
• Go/No Go!
• Attach supporting docs
• Complete 2 qts prior to dev
• Next 2 qtrs of tgt release
date on Business Epic level
• Complete 1 qtr prior to dev
Release to
Production
Release to
Customers
• Complete release checklist
• Fully tested
• Monitor progress toward
roadmap/commitments
Company Strategy and Product Roadmap
Artifacts
Product Initiatives and Supporting Documentation
Story Maps (visual view of decomposition of an initiative into Business Epics and User Stories)
Gates are managed via
the bi-weekly Prod
Mgmt/Dev Summit
Business Epics
Development Epics
Themes
Customer Release
• Final pre-release testing
• Create detailed stories
• Revise level of effort
Software Release
User Stories
- Stored/managed via SharePoint lists and libraries
- Stored/managed via Urban Turtle/TFS

17. 17
Reading Maps

18. 18
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

19. 19
Agile Governance Framework
Product
Strategy
Technology
Infrastructure
O&T
Efficiency
Initiatives
Platform
Architecture
Initiative to Epic
Elaboration
Epic to User
Story Planning
Team Backlogs
Story / Mind Maps
Team
Program
Investment
Themes
Company
Roadmap
Product
Development
Steering
Q1 Q2 Q3 Q4
Program Backlog
Portfolio Backlog
Portfolio
Prioritization
Level
Oversight
Product
Development
Summit
Bus Epics
Customer
Release
Planning
Software
Release
Development
User Stories
Testing
Agile Teams

20. 20
Portfolio Level
§ 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

21. 21
Program Level
§ “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

22. 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

23. 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

24. 24
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 Daily scrum
meetings
At the moment answers
Over the wall
Daily visibility
No more vague progress updates
Verbal
Visual
Use of story maps

25. 25
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-anutshell

26. 26

27. 27
QUESTIONS?
sage.eabeck@gmail.com