Journey toagile published


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Journey toagile published

  1. 1. 1 THE JOURNEY FROM WATERFALL TO AGILE Beth Beck Director of Product, Syncada
  2. 2. 2
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 17 Reading Maps
  18. 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. 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. 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. 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. 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. 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. 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. 25 References •  Living in an Agile World- Pragmatic Marketing article/deck • •  Ten Year Agile Perspective • •  eBook: Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams by Greg Cohen •  Silicon Valley Product Group Newsletter • •  Scaled Framework visuals • •  Product Ownership blog •
  26. 26. 26
  27. 27. 27 QUESTIONS?