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? [email protected]
27
Top Related