Using RUP As A Scaling Framework For Scrum

6,882 views

Published on

This talk was presented for the first time at Agile 2008 in Toronto

Published in: Technology, Business

Using RUP As A Scaling Framework For Scrum

  1. 1. Using the Unified Process as a Scaling Framework for Scrum
  2. 2. Where to go for the presentation <ul><li>Mike’s blog: http://www.leadingagile.com </li></ul><ul><li>Brian’s blog: http://blog.softwarearchitecture.com </li></ul>
  3. 3. Who is Mike Cottmeyer? <ul><li>Have been on the VersionOne service team for about 8 months </li></ul><ul><li>Prior to joining VersionOne I was a Senior Project Manager for CheckFree Corporation in Atlanta, GA </li></ul><ul><li>Certified Scrum Master, PMP, DSDM Agile Project Leader </li></ul>
  4. 4. Who is Brian Sondergaard? <ul><li>Director of Architecture at CheckFree (now a part of Fiserv) </li></ul><ul><li>Instrumental in bringing agile to Fiserv </li></ul>
  5. 5. Overview of the next 90 minutes <ul><li>Not a questioning agile talk </li></ul><ul><li>This is a scaling agile talk </li></ul><ul><li>It is a talk about applying agile from “concept to cash” </li></ul><ul><li>It is a talk about making agile work in real organizations </li></ul><ul><li>Lot’s of stuff to cover </li></ul><ul><li>Links to resources at the end </li></ul>
  6. 6. Our Agenda <ul><li>15 minutes setting up the problem </li></ul><ul><li>15 minutes talking about core UP and Agile principles </li></ul><ul><li>45 minutes explaining how it all works </li></ul><ul><li>15 minutes for questions </li></ul>
  7. 7. If you are part of a small team running agile on whiteboards…
  8. 8. Methodology pragmatist <ul><li>We are passionate about the values and principles of Agile </li></ul><ul><li>We love stories about wholesale agile transformation </li></ul><ul><li>But… we’re going to do what it takes to get the job done </li></ul>
  9. 9. Most teams are not there… <ul><li>Many are doing agile under less than agile circumstances </li></ul><ul><li>As an agile community we need to help people where they are </li></ul><ul><li>… but get them where they need to be </li></ul>
  10. 10. Most teams are looking for advice that resonates
  11. 11. Our story… <ul><li>Started with a small colocated team </li></ul><ul><li>Product took off </li></ul><ul><li>Team grew, 70 plus including offshore </li></ul><ul><li>Our product was beginning to leveraged as a shared service across the organization </li></ul>
  12. 12. … a little more story <ul><li>We were beginning to depend on other enterprise services for our product </li></ul><ul><li>Our product became a product of products </li></ul>
  13. 13. What is a product of products? Payments Services Risk Services Business Intelligence Corporate Financials Online Banking X X X X Phone Banking X X X Payment Processing X X Remittance Processing X X
  14. 14. Complex product architecture Partner Communication Payments Risk Bus Intel/ Reporting Business Intelligence Corporate Financials
  15. 15. Small team agile doesn’t resonate <ul><li>Shared code ownership </li></ul><ul><li>Teams responsible for entire architecture </li></ul><ul><li>Legacy systems with little automation </li></ul><ul><li>Tightly coupled architectures </li></ul>
  16. 16. Big company overhead <ul><li>Document based tollgates </li></ul><ul><li>Corporate governance and decision making </li></ul><ul><li>Traditional Project Management Offices </li></ul>
  17. 17. Agile offers only partial coverage Mike Griffiths, Leading Answers http://www.leadinganswers.com
  18. 18. Teams are trying to find a way to get the value of agile …
  19. 19. … but don’t fit the agile profile
  20. 20. Scrum is really simple <ul><li>Scrum is a simple framework </li></ul><ul><li>Deliver in short cycles, inspect outcomes, and adapt process or requirements </li></ul><ul><li>Some role definition, daily stand up meetings, planning process, etc. </li></ul>
  21. 21. Devise and execute the best processes possible based on their skills, experience , and the situation in which they find themselves
  22. 22. Scrum is not enough <ul><li>Business case </li></ul><ul><li>Vision </li></ul><ul><li>Backlog (where does it come from?) </li></ul><ul><li>Architecture </li></ul><ul><li>Documentation </li></ul><ul><li>Release plans and roadmaps </li></ul>
  23. 23. Other Challenges <ul><li>Interfaces with external organizations </li></ul><ul><li>When there are lots of team members </li></ul><ul><li>Geographically distributed </li></ul><ul><li>Offshore team members </li></ul><ul><li>Closed workspaces </li></ul><ul><li>Large systems architectures </li></ul><ul><li>External dependencies </li></ul>
  24. 24. Is this even agile? <ul><li>Maybe not </li></ul><ul><li>Lots of smells </li></ul><ul><li>Agile thinking and agile practice can still be valuable </li></ul>
  25. 25. What do we build around <ul><li>Iterative and incremental delivery of working software </li></ul><ul><li>Short cycle planning with an integrated customer </li></ul><ul><li>Small, independent stories </li></ul><ul><li>Empowered teams </li></ul><ul><li>Autonomy and self organization </li></ul><ul><li>Ownership and Accountability </li></ul>
  26. 26. Scrum-but introduces risk <ul><li>Deviating from agile practice introduces risk </li></ul><ul><li>We need to be intentional about how we mitigate that risk </li></ul>
  27. 27. Mitigating process Risk <ul><li>As we scale, we often need to have more things written down </li></ul><ul><li>We need to be more intentional about architecture </li></ul><ul><li>We need to be more intentional about requirements </li></ul>
  28. 28. Why bother talking about UP <ul><li>Provides an iterative and incremental delivery structure </li></ul><ul><li>Guidance for writing and breaking down requirements </li></ul><ul><li>Patterns for dealing with software architecture </li></ul>
  29. 29. Why bother talking about UP <ul><li>Structure for necessary documentation </li></ul><ul><li>Provides process guidance for all aspects of the SDLC, not just development </li></ul>
  30. 30. Most teams are making tradeoffs, lets be intentional about managing those tradeoffs and understanding the risks
  31. 31. Common myths about UP <ul><li>Adopting UP means adopting Rational Tools </li></ul><ul><li>UP is too big </li></ul><ul><li>UP is too document focused </li></ul><ul><li>UP is not configurable </li></ul>People in the agile community really HATE the Unified Process, especially the RUP
  32. 32. Process gone bad <ul><li>UP is designed to be configurable </li></ul><ul><li>In practice people do UP poorly </li></ul><ul><li>UP with a waterfall, predictive focus </li></ul><ul><li>Agile with an undisciplined ad-hoc focus </li></ul>
  33. 33. Bad process is bad process no matter what methodology you are using
  34. 34. How do we make all this work? <ul><li>Take what is good about agile, what scales, and leverage it </li></ul><ul><li>Replace what doesn’t work with certain components of the UP </li></ul><ul><li>Keep things as simple as possible </li></ul>
  35. 35. How do we do this right? <ul><li>We want to be as agile as possible </li></ul><ul><li>We want to implement as little structure as possible to scale </li></ul><ul><li>Give people across all the teams a common language, minimal standardization, and some degree of coordination </li></ul><ul><li>Stay risk focused ! </li></ul>
  36. 36. Do the simplest thing that could possibly work
  37. 37. What agile should I keep? <ul><li>Small teams, teams of teams if necessary </li></ul><ul><li>Short planning cycles </li></ul><ul><li>Visibility, inspection, adaptation </li></ul><ul><li>Retrospectives </li></ul><ul><li>Integrated onsite customer </li></ul>
  38. 38. What agile should I keep? <ul><li>Progressive elaboration of plans </li></ul><ul><li>Small independent stories </li></ul><ul><li>Autonomy and self organization </li></ul><ul><li>Ownership and accountability </li></ul>
  39. 39. What UP stuff should I keep? <ul><li>Sprit of RUP </li></ul><ul><li>Phases </li></ul><ul><li>Iterations </li></ul><ul><li>Use Cases </li></ul><ul><li>Deliberate Architecture </li></ul><ul><li>Some artifacts </li></ul>
  40. 40. What agile stuff might go away? <ul><li>No documentation </li></ul><ul><li>No planning </li></ul><ul><li>Emerging architecture </li></ul><ul><li>Universal shared code ownership </li></ul>
  41. 41. What UP stuff might go away? <ul><li>Role definitions </li></ul><ul><li>Process guidance unless something has value in our context </li></ul><ul><li>Most artifacts </li></ul>
  42. 42. What UP stuff will definitely go away?
  43. 43. Introduce elements of UP that reduce risk
  44. 44. Spirit of UP <ul><li>Attack major risks early and continuously, or they will attack you </li></ul><ul><li>Ensure that you deliver value to your customer </li></ul><ul><li>Stay focused on executable software and the “product” </li></ul><ul><li>Accommodate change early in the project </li></ul>
  45. 45. Spirit of UP <ul><li>Baseline an executable architecture early </li></ul><ul><li>Build your system with components </li></ul><ul><li>Work together as one team </li></ul><ul><li>Make quality a way of life, not an afterthought </li></ul>
  46. 46. UP phases explained Construction Elaboration Inception Transition Lifecycle Objective Milestone Lifecycle Architecture Milestone Initial Operational Capability Milestone Product Release Milestone Are the technical risks mitigated? Are the logistical risks mitigated? Are the business risks mitigated? Are we really ready to ship a complete robust product to market?
  47. 47. Effort and duration by phase Inception Elaboration Construction Transition Inception Elaboration Construction Transition Effort 5% 20% 65% 10% Schedule 10% 30% 50% 10%
  48. 48. A more Agile representation? Internal Release* Iteration Zero Iteration H Iteration 1 Iteration 2 Iteration 3
  49. 49. Phases are time boxes for dealing with risk
  50. 50. With phases as the key concept… <ul><li>Outcomes </li></ul><ul><li>Activities </li></ul><ul><li>Artifacts </li></ul>
  51. 51. Inception Outcomes <ul><li>Clarify the Vision </li></ul><ul><li>Initial Backlog </li></ul><ul><li>Preliminary estimates </li></ul><ul><li>One possible solution </li></ul><ul><li>Validation of the business case </li></ul><ul><li>Business risk mitigated </li></ul><ul><li>Stakeholder agreement </li></ul>
  52. 52. Inception Activities <ul><li>Meetings between product owner, architect, and analyst to evolve the product backlog and the candidate solution </li></ul><ul><li>Balance the needs of the business with the capability of the team and feasibility of the solution </li></ul><ul><li>Review the outcome with the business, manage expectations, go/no-go decision </li></ul>
  53. 53. Collaborative Model Project Manager
  54. 54. Inception Artifacts <ul><li>Business case </li></ul><ul><li>Vision </li></ul><ul><li>Use Case Inventory </li></ul><ul><li>Risk Assessment </li></ul><ul><li>Candidate architecture </li></ul>
  55. 55. Elaboration Outcomes <ul><li>Architectural spikes completed </li></ul><ul><li>Architecturally significant backlog done </li></ul><ul><li>Validated systems architecture </li></ul><ul><li>Walking skeleton </li></ul><ul><li>Product backlog “fully” defined </li></ul><ul><li>Technical risk mitigated </li></ul><ul><li>Backlog re-estimated </li></ul><ul><li>Business decision to move forward </li></ul>
  56. 56. Elaboration Activities <ul><li>Validate systems architecture by building out backlog items that will “prove” the architecture </li></ul><ul><li>Performance testing </li></ul><ul><li>Security testing </li></ul><ul><li>Backlog creation </li></ul><ul><li>Arch/Tech Spikes </li></ul>
  57. 57. <ul><li>Consensus on major “forces” </li></ul><ul><li>Clarity of boundaries </li></ul><ul><li>Agreement on where we’re going </li></ul><ul><li>“ Stay between the lines” </li></ul>Establish architecture “guardrails”
  58. 58. Scrum of Scrums Epic/ System Perspective Feature/ Subsystem Perspective Story/ Component/ Design Perspective
  59. 59. Business Level Use Case
  60. 60. Solution Architecture
  61. 61. Primary and alternate flows
  62. 62. Interactions and contracts
  63. 63. Design level use case
  64. 64. Detailed interactions
  65. 65. Data
  66. 66. Scrum of Scrums <ul><li>Higher level scrums integrate the scenarios of the component teams </li></ul><ul><li>Breakdown application and zip it back up </li></ul><ul><li>Automation at each level of the breakdown/rollup </li></ul>
  67. 67. Elaboration Artifacts <ul><li>Updated Product backlog </li></ul><ul><li>Use case scenarios defined </li></ul><ul><li>Go forward architectural representation </li></ul><ul><li>Done backlog items </li></ul><ul><li>Test plan/test results </li></ul><ul><li>Fully integrated and working subset of the system </li></ul>
  68. 68. Construction Outcomes <ul><li>Product built </li></ul><ul><li>Product fully tested </li></ul><ul><li>Product documentation completed </li></ul><ul><li>Logistical risks mitigated </li></ul><ul><li>Business decision to release to market </li></ul>
  69. 69. Construction Activities <ul><li>Most ‘agile’ of all phases </li></ul><ul><li>Teams building features from the backlog </li></ul><ul><li>Testing </li></ul><ul><li>Documentation </li></ul><ul><li>Measure velocity </li></ul><ul><li>Project management </li></ul>
  70. 70. Construction Artifacts <ul><li>Evolving backlog </li></ul><ul><li>Design documentation </li></ul><ul><li>Code </li></ul><ul><li>User documentation </li></ul><ul><li>Test results </li></ul>
  71. 71. Transition Outcomes <ul><li>Product finalized and ready to be released </li></ul><ul><li>Any remaining issues resolved </li></ul><ul><li>Preparation for handoff </li></ul><ul><li>Transition to support or operations </li></ul><ul><li>Production deployment </li></ul>
  72. 72. Transition Activities <ul><li>Review </li></ul><ul><li>Documentation </li></ul><ul><li>Last minute bug fixes </li></ul><ul><li>Last minute backlog changes </li></ul>
  73. 73. Transition Artifacts <ul><li>Hand off docs </li></ul><ul><li>Final user documentation </li></ul><ul><li>Packaging </li></ul><ul><li>Website </li></ul><ul><li>Marketing </li></ul>
  74. 74. Role of documentation
  75. 75. Managing Complexity <ul><li>Product </li></ul><ul><li>Project </li></ul><ul><li>Management </li></ul><ul><li>Team </li></ul><ul><li>Architecture </li></ul><ul><li>Pick two </li></ul><ul><li>Align the rest </li></ul>
  76. 76. Complexity diagram
  77. 77. Keep it simple
  78. 78. Closing remarks <ul><li>Might not need to bother if you are a small collocated agile team </li></ul><ul><li>Be pragmatic about process and adopt things that make sense for the size and complexity of your organization </li></ul><ul><li>Be intentional about the tradeoffs you are making and mitigate process risks </li></ul><ul><li>Done right, there are some concepts from RUP you can use to help mitigate these risks </li></ul>
  79. 79. Valuable RUP concepts <ul><li>Sprit of RUP </li></ul><ul><li>Phases </li></ul><ul><li>Iterations </li></ul><ul><li>Use Cases </li></ul><ul><li>Deliberate Architecture </li></ul><ul><li>Some artifacts </li></ul>
  80. 80. Where to go for more info… <ul><li>Scaling Software Agility – Dean Leffingwall </li></ul><ul><li>Agile Project Management With Scrum – Ken Schwaber </li></ul><ul><li>Managing Iterative Software Development Projects – Kurt Bittner, Ian Spence </li></ul><ul><li>Scott Ambler http://www.ambysoft.com/unifiedprocess/agileUP.html </li></ul><ul><li>DSDM http://www.dsdm.org/products/atern.asp </li></ul>
  81. 81. Where to go for the presentation <ul><li>Mike’s blog: http://www.leadingagile.com </li></ul><ul><li>Brian’s blog: http://blog.softwarearchitecture.com </li></ul>
  82. 82. Simplifying Software Delivery

×