Scaling Lean Agile - mini iad 2014
- 2. Agenda • Agile Development • Extended Lean Agile Frameworks • Disciplined Agile Development (DAD) • Scaling Agile Framework (SAFe) • Agility Path + CIF • Large-‐scale Scrum • ConsideraEons • Conclusion 2
- 3. Agenda • Agile Development • Extended Lean Agile Frameworks • Disciplined Agile Development (DAD) • Scaling Agile Framework (SAFe) • Agility Path + CIF • Large-‐scale Scrum • ConsideraEons • Conclusion 3
- 4. What Agile is NOT !!
- 7. Accelerate Eme to market Managing changing prioriEes BeMer align IT/Business Increase producEvity Enhance soOware quality Project visibility Reduce risks
- 12. Improve things with Scrum Remove waste • Technical debt • Unnecessary documentaEon • Unnecessary requirements • Unused requirements • Architecture that must be reworked Improve producEvity • Collocated, self-‐organizing teams • Cross-‐funcEonal teams • FTF communicaEons • Improved decision making
- 13. Technical Prac6ces? Project Ini6a6on? Release into Produc6on? Operate in Produc6on? Enterprise Disciplines? Project Selec6on?
- 15. Does Agile Scale? YES Scaling: • The majority of agile teams are geographically distributed in some manner • OrganizaEons have reported successful agile programs of 500+ people • One third of agile teams are in regulatory situaEons • 75% of organizaEons doing agile are doing so on medium complexity or greater projects • 17% of organizaEons are successfully applying agile in outsourcing situaEons • 78% of teams are working with legacy systems • 32% of organizaEons report successful interacEon between enterprise architects and agile teams • 11% of organizaEons report that their governance strategy works well with agile teams (yikes) Source: • DDJ November 2009 State of the IT Union Survey, www.ambysoO.com/surveys/
- 23. Problems of Scaling § SoS – Scrum Of Scrums – Becomes more difficult aOer 6 or so Teams – Planning & Ceremonial Events conflict § Doesn’t really address a Porlolio & Program View – SEll thinks of smaller “projects” – Planning Roadmap horizons are sEll short § Fails to recognize that Waterfall sEll exists § Governance & Authority start to fail – No Clear Content Authority once you scale to a Program or Porlolio level – Who resolves prioriEes across dozens of teams? – Who then drives releases?
- 24. 24 Problems of Scaling § ReporEng & Metrics aren’t sufficient across large numbers of teams or programs § TradiEonal sources of informaEon (Scrum/Agile Alliance) aren’t mature to help this – Note: In Jan ‘2013 Ken Schwaber introduced CIF – ConEnuous Improvement Framework
- 25. Agenda • Agile Development • Extended Lean Agile Frameworks • Disciplined Agile Development (DAD) • Scaling Agile Framework (SAFe) • Agility Path + CIF • Large-‐scale Scrum • ConsideraEons • Conclusion 25
- 26. What Should a Scaled Framework Address? § Mul6ple Agile Teams – Should be able to handle dozens of teams (Scrum starts to break around 7) – IncorporaEon of XP Engineering pracEces § Waterfall Teams – They sEll exist. Not everything can be Agile § Program Level planning and views
- 27. What Should a Scaled Framework Address? § Governance and shared resources (like Enterprise/System Architects, UX, etc.) § Specialized teams for Release planning, system integra6on § Clear content authority § PorPolio Management and the management of WIP
- 29. DAD -‐ Disciplined Agile Delivery
- 30. The Disciplined Agile Lifecycle: An extension of Scrum
- 31. Concept: The Agile 3C Rhythm Incep6on Coordinate Construc6on Collaborate Transi6on Conclude Release rhythm Itera6on Planning Coordinate Development Collaborate Stabilize Conclude Iteration rhythm CoordinaEon MeeEng Coordinate Daily work Collaborate Stabilize Conclude Daily rhythm The Coordinate-Collaborate-Conclude rhythm occurs at several scales on a DAD project:
- 34. Typical day during construcEon
- 36. * Slide Courtesy of IBM Agile Scaling Factors
- 37. DAD -‐ Disciplined Agile Delivery • Decision oriented framework
- 39. SAFe -‐ Scaled Agile Framework
- 40. SAFe -‐ Scaled Agile Framework
- 41. Roots of the Scaled Agile Framework
- 42. Scaled Agile Framework – Big Picture
- 43. Agile Teams
- 44. Scale to Program Level
- 47. SAFe – Scaling Agile Framework • PrescripEve framework
- 48. DAD vs SAFe
- 54. Evidence-Based Management (“EBM”): • Roots in the medical practice. • The application of direct, objective evidence* by managers to make decisions. • For software development, EBM is employed to maximize the value of software to the entire organization. A Matter of Managerial Culture Evidence, broadly construed, is anything presented in support of an assertion: • Strongest type of evidence is that which provides direct proof of the validity of the assertion. • Weakest type of evidence is that which is merely consistent with the assertion, but doesn’t rule out contradictory assertions, as in circumstantial evidence. *Source: Wikipedia
- 55. Direct Evidence of an Organization’s Value
- 56. Outcome Is Measured for Direct Evidence Of Value Current Value Ability to Innovate Time to Market Release Frequency Release StabilizaEon Cycle Time Installed Version Index Usage Index InnovaEon Rate Defects Revenue per Employee Employee SaEsfacEon Customer SaEsfacEon Product Cost RaEo
- 57. Circumstantial evidence is evidence that relies on inference to connect it to a conclusion of fact, allowing more than one explanation to be possible: • Usually accumulates into a collection so the pieces become corroborating evidence. • Explanation involving circumstantial evidence becomes more valid as proof of a fact when the alternative explanations have been ruled. Entry points to collect circumstantial evidence
- 58. Diagnosing circumstantial evidence in organizational patterns Process Produc6vity Value Quality Enterprise • Scrum • Self-‐ organizaEon • Product Backlog • Sprint Planning • Daily Scrum • Sprint Review • Sprint RetrospecEve • Scaling Scrum • DefiniEon of Done • TesEng • Clean code • Test-‐Driven development • ConEnuous IntegraEon • Emergent Architecture • Accountability • Transparency • Product Backlog • Alignment • Release planning and orientaEon • Porlolio Management • Engineering standards • Architecture • QA • ALM • CommunicaEon • OrganizaEon • Culture • People PracEces • Sales • Lean
- 59. Relating value to organizational patterns Informs priority Measure Diagnose Improve Influences Outcomes More at http://evidencebasedmanagement.org
- 60. EBM measures the value of the organization. EBM
- 61. EBM diagnoses likely contributors, and discovers capabilities you can build on. EBM
- 62. EBM helps you improve by using evidence as a driver of change EBM
- 64. Agility Team • Enterprise Product Owner – Domain Product Owner – Product Owner • Enterprise Change Team – Domain Change Team – Change Team • Enterprise Scrum Master – Domain Scrum Master – Scrum Master
- 65. Agility Path Events • Sprint • Sprint Planning – Functional Change – Sprint Goal • Weekly Scrum • Evaluation – Sprint Review – Sprint Retrospective
- 66. Agility Path ArEfacts • Practice Backlog • Sprint Backlog • Evaluation Backlog • Increment of Change
- 67. Agility Path Metrics • Agility Index • Agility Acceleration
- 69. Scale Scrum Beyond Your Team • “We have worked with thousand of organizaEons that are aMempEng to become more effecEve and more agile. • They usually start by implemenEng Scrum. • Then they are faced with the issue of how to get the most out of their investment in Scrum. • They wonder how to manage its scaling throughout the organizaEon.”
- 71. CIF Overview • CIF consists of two interacEng processes: product development and con6nuous improvement.
- 72. Product Development Process • The CIF product development process lays out the flow of work through the major product development funcEons of product management, program management, and product development, based on Scrum. • These are then integrated into porlolio and product family management for mulEple products and systems. • The work flows into and out of the Product Backlog.
- 73. ConEnuous Improvement Process • The CIF con6nuous improvement process implements new agile pracEces into the product development process. It periodically captures metrics and pracEce usage. • PaMerns of metrics and pracEces are assessed for dysfuncEon and effecEveness. • Your overall agility is compared to that in other organizaEons. • Ways to increase the effecEveness for conEnuous improvement are devised and applied.
- 74. Process InteracEon • CIF is oriented around two databases: – Metrics -‐ are implanted in the product development process and a baseline is created. Processes are periodically sampled to measure change in producEvity, quality, value, agility, and key performance indicators. – Prac6ces -‐ that maximize value and eliminate waste are applied to change your current processes. They are organized by the business funcEons of product development, sales, markeEng, finance, human resources, and customer support. These pracEces are ordered and tracked in the pracEce backlog so their progressive adaptaEon and implementaEon conEnuously improve your organizaEon, as reported by the metrics. PracEce details are referenced from a pracEce database.
- 76. Scaling Lean & Agile Development
- 77. Scaling Lean & Agile Development • Large Scale Scrum is Scrum: change implicaEons • Fractal structure • Feature teams vs Components Teams • Lean Concepts and Principles • Complex Systems • Queues theory
- 82. Scaled Lean & Agile • Empirical oriented framework
- 83. Agenda • Agile Development • Extended Lean Agile Frameworks • Disciplined Agile Development (DAD) • Scaling Agile Framework (SAFe) • Agility Path + CIF • Large-‐scale Scrum • Considera6ons • Conclusion
- 85. Ken Schwaber
- 86. Ken Schwaber co-founder of Scrum
- 87. unSAFe at any speed Many organizaEons will open their checkbooks for SAFe and its partners. I suggest that they measure the improvement, as that is the job of management. Investments are supposed to have returns. Ken Schwaber
- 88. unSAFe at any speed • Measure: – Cycle Eme – quickest Eme to get one feature out – Release cycle – Eme to get a release out – Defects – change in defects – ProducEvity – normalized effort to get a unit of funcEonality “done” – StabilizaEon – aOer code complete, % of a release is spent stabilizing before release – Customer saEsfacEon – up or down – Employee saEsfacEon – up or down
- 89. unSAFe at any speed • A core premise of Agile is that the people doing the work are the people who can best figure out how to do it. • The job of management is to do anything to help them do so, not suffocate them with SAFe! Ken Schwaber
- 91. Abandoning a Process-‐Centric Approach to Improvement David J. Anderson
- 92. Kanban > anE-‐SAFe The Kanban Method will coexist with SAFe in the marketplace. People will choose between a modern 21st Century approach to complex situaEons or a familiar 20th Century approach to change and their soOware engineering processes. Choice is good in a marketplace! Kanban offers a counter-‐intuiEve innovaEve modern approach. SAFe offers something familiar. David J. Anderson
- 93. Kanban > anE-‐SAFe Coexistence of SAFe and Kanban is a good thing. Providing alternaEve approaches to large scale business agility is a good thing. Both approaches will carry the label "Agile." Both will be marketed as soluEons scaling Agile.
- 94. Kanban > anE-‐SAFe Coexistence of SAFe and Kanban is a good thing. Providing alternaEve approaches to large scale business agility is a good thing. Both approaches will carry the label "Agile." Both will be marketed as soluEons scaling Agile. I believe there is considerable irony in that. David J. Anderson
- 95. Dave Snowden father of Cynefin Framework
- 96. SAFe: the infan9lism of management Dave Snowden
- 97. SAFe : infanElism of … Put brutally SAFe seemed to be PRINCE II camouflaged in Agile language. SCRUM as an approach was emasculated in a small box to the boMom right of a hugely overcomplicated linear model. The grandiose name of a dependency map was applied to something which is no different from a PERT chart and in general what we had is an old stale wine forced into shiny new wineskins. Dave Snowden
- 98. SAFe : infanElism of … My strong and increasingly passionate argument was that SAFe is not only a betrayal of the promise offered by AGILE but is a massive retrograde step giving the managerial class an excuse to avoid any significant change. Dave Snowden
- 99. SAFe : infanElism of … … Such excuses abound and allowing these false linear models to perpetuate themselves is a form of infanElism, a failure to carry through on the need for change. In parEcular the failure to realize that soOware development needs to be seen as a service and as an ecology not as a manufacturing process. Dave Snowden
- 100. A possible way …
- 108. 100% predictability = 0% innova6on
- 110. Value & Impact > Velocity
- 114. Culture > Process • Shu-‐level Scrum can get you out a ditch, but won’t make you fly. – Learn the rules so you can break them. • Healthy Culture heals broken process. – Hack the culture, and process will follow. • Agile is Fragile. – It is only sustainable over the long term if all parts of the organizaEon are commiMed to it. • You are the culture. – Model the behavior you want to see.
- 115. Lean from the trenches
- 116. Lean Mindset
- 117. Agility AdopEon Rather Than Agile At Scale
- 120. Keep the values, keep the principles, think for yourself.
- 121. Keep the values, keep the principles, think for yourself.
- 122. Keep the values, keep the principles, think for yourself! Ken Schwaber
- 124. Agenda • Agile Development • Extended Lean Agile Frameworks • Disciplined Agile Development (DAD) • Scaling Agile Framework (SAFe) • Agility Path + CIF • Large-‐scale Scrum • ConsideraEons • Conclusion 124