scaling lean agile - mini iad 2014
DESCRIPTION
Perché parliamo di Scaling Lean Agile? Ci sono due aspetti primari inerenti lo scalare delle tecniche agili a livello di Enterprise che è necessario considerare. In primo luogo lo scalare delle tecniche agili a livello di progetto per affrontare le sfide peculiari che i team di progetto devono affrontare. In secondo luogo è lo scalare la vostra strategia agile attraverso l'intero reparto IT, in modo appropriato. E' abbastanza semplice applicare Lean Agile su una manciata di progetti, ma può essere molto difficile far evolvere la cultura e l’intera struttura organizzativa per adottare appieno il modo agile di lavorare. Lean e Agile (in particolar modo metodologie come Scrum e XP) hanno pienamente dimostrato il loro valore a livello di team. Cosa succede però nel momento in cui tentiamo di utilizzarle in contesti reali più complessi? Nelle reali organizzazioni che caratterizzano un’importante parte del panorama dell'IT in Italia? Muovendosi dal livello dei team verso il livello dell'organizzazione si incontrano una serie di problematiche più complesse e per un certo verso nuove. Ecco quindi l'importanza di conoscere valori e principi che sono alla base del tema del Lean Agile Scaling. Esistono parecchi modelli che negli ultimi anni si confrontano con le realtà delle organizzazioni. In questo talk tratteremo a livello olistico questo tema e confronteremo alcuni di tali modelli di Scaling Lean Agile, quali: Scrum standard (Ken Schwaber, Mike Cohn, ...) – il modello di Larmann & Vodde - SAFe – Disciplined Agile Delivery di Scott Ambler – Path to Agility (Ken Schwaber). Inoltre verranno affrontate e discusse le esperienze personali effettuate in diverse società in fase di adozione o utilizzo su larga scala di Lean Agile.TRANSCRIPT
Fabio Armani OpenWare
Agenda • Agile Development • Extended Lean Agile Frameworks
• Disciplined Agile Development (DAD) • Scaling Agile Framework (SAFe) • Agility Path + CIF • Large-‐scale Scrum
• ConsideraEons • Conclusion
2
Agenda • Agile Development • Extended Lean Agile Frameworks
• Disciplined Agile Development (DAD) • Scaling Agile Framework (SAFe) • Agility Path + CIF • Large-‐scale Scrum
• ConsideraEons • Conclusion
3
What Agile is NOT !!
Accelerate Eme to market Managing changing prioriEes BeMer align IT/Business Increase producEvity Enhance soOware quality Project visibility Reduce risks
Agile Overtakes Waterfall
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
Technical Prac6ces? Project
Ini6a6on? Release into Produc6on?
Operate in Produc6on? Enterprise
Disciplines?
Project Selec6on?
Lean Agile @Enterprise
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/
Small-‐scale vs Large-‐scale
Small-‐scale vs Large-‐scale
Small-‐scale vs Large-‐scale
Small-‐scale vs Large-‐scale
Small-‐scale vs Large-‐scale
Small-‐scale vs Large-‐scale
Small-‐scale vs Large-‐scale
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
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
Agenda • Agile Development • Extended Lean Agile Frameworks
• Disciplined Agile Development (DAD) • Scaling Agile Framework (SAFe) • Agility Path + CIF • Large-‐scale Scrum
• ConsideraEons • Conclusion
25
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
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
DAD -‐ Disciplined Agile Delivery
The Disciplined Agile Lifecycle: An extension of Scrum
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:
The IncepEon Phase
Typical ConstrucEon IteraEon
Typical day during construcEon
The TransiEon phase
* Slide Courtesy of IBM
Agile Scaling Factors
DAD -‐ Disciplined Agile Delivery • Decision oriented framework
SAFe -‐ Scaled Agile Framework
SAFe -‐ Scaled Agile Framework
Roots of the Scaled Agile Framework
Scaled Agile Framework – Big Picture
Agile Teams
Scale to Program Level
Scale to Porlolio
SAFe – Scaling Agile Framework • PrescripEve framework
DAD vs SAFe
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
Direct Evidence of an Organization’s Value
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
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
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
Relating value to organizational patterns
Informs priority Measure Diagnose
Improve Influences Outcomes
More at http://evidencebasedmanagement.org
EBM measures the value of the organization. EBM
EBM diagnoses likely contributors, and discovers capabilities you can build on.
EBM
EBM helps you improve by using evidence as a driver of change
EBM
Agility Path implements Evidence-Based Management
Repeat
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
Agility Path Events • Sprint • Sprint Planning
– Functional Change – Sprint Goal
• Weekly Scrum • Evaluation
– Sprint Review – Sprint Retrospective
Agility Path ArEfacts • Practice Backlog • Sprint Backlog • Evaluation Backlog • Increment of Change
Agility Path Metrics • Agility Index • Agility Acceleration
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.”
CIF Overview • CIF consists of two interacEng processes: product
development and con6nuous improvement.
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.
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.
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.
Scaling Lean & Agile Development
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
Scaled Lean & Agile • Empirical oriented framework
Agenda • Agile Development • Extended Lean Agile Frameworks
• Disciplined Agile Development (DAD) • Scaling Agile Framework (SAFe) • Agility Path + CIF • Large-‐scale Scrum
• Considera6ons • Conclusion
Ken Schwaber
Ken Schwaber co-founder of Scrum
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
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
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
Abandoning a Process-‐Centric Approach to Improvement
David J. Anderson
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
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.
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
Dave Snowden father of Cynefin Framework
SAFe: the infan9lism of management Dave Snowden
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
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
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
A possible way …
100% predictability = 0% innova6on
Value & Impact > Velocity
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.
Lean from the trenches
Lean Mindset
Agility AdopEon Rather Than Agile At Scale
Keep the values, keep the principles, think for yourself.
Keep the values, keep the principles, think for yourself.
Keep the values, keep the principles, think for yourself!
Ken Schwaber
Agenda • Agile Development • Extended Lean Agile Frameworks
• Disciplined Agile Development (DAD) • Scaling Agile Framework (SAFe) • Agility Path + CIF • Large-‐scale Scrum
• ConsideraEons • Conclusion
124