Agile Wake Up #1 du 01/12/2015 : L'agilité à grande échelle
•Als PPTX, PDF herunterladen•
3 gefällt mir•1,394 views
DAD, Spotify, Nexus, LeSS et SAFe
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Agile Wake Up #1 du 01/12/2015 : L'agilité à grande échelle
Ähnlich wie Agile Wake Up #1 du 01/12/2015 : L'agilité à grande échelle (20)
Mehr von Zenika
Mehr von Zenika (20)
Agile Wake Up #1 du 01/12/2015 : L'agilité à grande échelle
- 1. L’agilité à grande échelle Des méthodes mais surtout des HOMMES …
- 2. Agilité à grande échelle ? • Tout le monde ou presque sait faire du Scrum avec une équipe, n’est- ce pas ? • Qui gère des projets ou des programmes où il y a plusieurs équipes en //, en concurrence ? • L’agilité à grande échelle, c’est l’art de gérer TOUTES ces équipes en tenant compte ou pas des budgets, des besoins, des plannings, …
- 3. Quelles sont les méthodes ?
- 4. Laquelle choisir ? • Aucune méthode n’est la panacée ! • Il faut choisir en fonction de contexte (organisation, maturité agile, culture d’entreprise, …) • Notre objectif : vous présenter succinctement : • DAD • Spotify • LeSS • SAFe
- 5. Discipline Agile Delivery (DAD) « The Disciplined Agile Delivery (DAD) process decision framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable. » • C’est un framework basé sur XP, UP, Kanban, … qui permet d’étendre Scrum.
- 6. Discipline Agile Delivery (DAD) : les rôles
- 7. Discipline Agile Delivery (DAD) : cycle de vie DAD peut se baser sur 4 types de cycles : 1. Une extension de Scrum à partir de RUP; 2. Un cycle lean adapté; 3. Du lean mettant l’accent sur la livraison en continu; 4. Une approche lean startup expérimentale.
- 8. Modèle Spotify • C’est un modèle d’agilité à l’échelle mis en œuvre chez Spotify. • Il se base sur une coopération d’une multitude d’équipes autonomes pérennes et stables (squads) afin de délivrer les produits au plus vite. Il existe des regroupements de squads : les tribus • Une collaboration entre les équipes est favorisée par la mise en place d’ensembles transverses : les chapitres et les guildes
- 9. Modèle Spotify : les rôles
- 10. Large Scale Scrum : More with less
- 11. Des principes
- 13. LeSS Framework
- 14. LeSS Huge
- 15. Scaled Agile Framework : SAFe • C’est un framework bien marketé. • Passons à la présentation « officielle », presque ...
- 16. SAFe® in 8 Pictures A Walkthrough of the Scaled Agile Framework® www.scaledAgile.com V3.0.4
- 17. Important Notice: Please Read Usage Restrictions This material is the property of Scaled Agile, Inc. and is protected by U.S. and International copyright laws. It is provided solely to promote adoption and use of the Scaled Agile Framework® (SAFe®) for the benefit of the enterprises and individuals who apply it. You may reproduce, distribute, and use this material for informational purposes only, and always free of charge. You may not modify any slides, or use anything from the slides to create derivative works, or remove any trademark or copyright notice. You may add slides unique to your specific context, but such content shall not change the meaning, purpose, or intent of the original material.
- 18. PROVEN
- 20. THE LEVELS
- 22. THE PEOPLE
- 24. THE BACKLOGS
- 26. THE CADENCE
- 28. CODE QUALITY
- 35. QUESTIONS?
Hinweis der Redaktion
- OVERVIEW: You can begin by setting the context for your audience. SAMPLE SPEAKER NOTES: Welcome to SAFe in 8 Pictures. My name is ______ and I represent _______. We’re here for an introduction to the Scaled Agile Framework. We want to create a shared understanding of the overarching approaches and principles at play in SAFe and understand how it allows large organizations to achieve enterprise agility
- OVERVIEW: With this slide, you can talk in general about the speed at which SAFe has been adopted, or adapt your voice-over to highlight its adoption in a specific market. See the case studies on the Scaled Agile Framework website. SAMPLE SPEAKER NOTES: SAFe is an online, freely revealed knowledge base of proven, integrated success patterns for implementing Lean-Agile development at enterprise scale. Companies like John Deere, Intel and Telstra have published case studies citing the business benefits. The list is growing every day. You can find those by navigating to ScaledAgileFramework.com and clicking on the “Case Studies” menu. To find certified members of the SAFe community, navigate to ScaledAgileAcademy.com, click on the Community menu, and select Member Directory.
- OVERVIEW: In this slide, you can explain that, at first glance, the Framework may appear complicated. However, you can provide assurance that you will take them through it in a logical manner. SAMPLE SPEAKER NOTES: This is what is referred to as the “SAFe Big Picture”. At first, it may look complicated, but as we will see, it is actually a very straight-forward and logical representation. We will see that roles, artifacts, and activities are clearly defined based on proven principles and practices. Decomposing the SAFe Big Picture into it’s constituent parts, we’ll discover that it’s a simple, powerful and easily understood framework for managing complex software and systems development.
- OVERVIEW: Introduce the levels of the Framework. Based on your audience, you could introduce Reinertson’s principle of Product Development Flow #9: Achieving Decentralized Control. SAMPLE SPEAKER NOTES: The levels in SAFe are not structured for control; rather, they are for centralizing strategy and decentralizing execution based on the principles of Product Development Flow
- OVERVIEW: Introduce the Portfolio, Program, and Team levels. Explain that without teams, there are no programs. The people at the Team and Program Levels make up the virtual organization known as the Agile Release Train. It is based on time-proven principles, as represented by the House of Lean. SAMPLE SPEAKER NOTES: Here we see the three levels of SAFe: Portfolio, Program, and Team. The people at the Team and Program Levels make up the virtual organization known as the Agile Release Train. Without teams, there can be no program. You’ll notice the House of Lean in the upper left. It represents the time-proven principles which include respect for people and culture, flow, innovation, and relentless improvement. The goal is value and the foundation is leadership.
- OVERVIEW: Here, you can discuss the concept of the knowledge worker. SAMPLE SPEAKER NOTES: In knowledge-based work the people are truly the assets of the organization. It is the people who have the knowledge and skills to define and build a quality system which executes the business strategy.
- OVERVIEW: Consider starting first with Lean-Agile Leaders. From there, you can tailor the discussion based on your audience. For example, if you’re speaking to an executive audience not familiar with Agile, you may want to continue with Program Portfolio Management and work your way down. If your audience is familiar with Agile, you could start with the teams and work your way up. SAMPLE SPEAKER NOTES: You’ll see Lean-Agile Leaders next to the House of Lean. These are not specific people filling a specific role. Rather, they represents the leadership required across the organization, as guided by the House of Lean, to support a Lean-Agile enterprise. Let’s now move to the Team level where we have small cross-functional teams that are empowered to make localized decisions to get work done. Each team has a Scrum Master, Product Owner, Developers, Testers, and other needed team roles. The System Team supports the Agile teams by building and maintaining tools for continuous integration, automated testing, and other infrastructure to support development and quality. They also conduct the testing which cannot be done by the individual teams. Business Owners set priorities and negotiate trade-offs. A User Experience engineer and a System Architect at the Program level provide guidance for the teams. The Release Train Engineer facilitates the activities of the Agile Release Train, much like the Scrum Master facilitates the activities of the team. Moving up to the Portfolio level, we have the Program Portfolio Management team responsible for strategy and investment funding, program execution, and governance. They have the highest level fiduciary responsibility in the Framework. An Enterprise Architect provides strategy and architectural guidance for the portfolio. Are there any other roles of interest I didn’t mention?
- OVERVIEW: If your audience is not familiar with the concept of a backlog, you can explain it now. SAMPLE SPEAKER NOTES: In Agile, requirements are managed in a construct known as a backlog which is comprised of prioritized functionality and other work to be done, such as architecture, spikes, refactors, and maintenance. Backlog items are elaborated at a level of detail appropriate to the phase of development. They are not commitments. Rather, they represent opportunities.
- OVERVIEW: Here, you can introduce the Enterprise Backlog Model consisting of the Portfolio, Program, Team, and Sprint backlogs. You can also elaborate on the artifacts and roles which influence the creation and prioritization of the backlog items, such as Strategic Themes, the Program Vision, and Program Roadmap. SAMPLE SPEAKER NOTES: There are three levels of backlogs which comprise the Enterprise Backlog Model: the Portfolio Backlog which contains Epics, the Program Backlog which contains Features, and the Team Backlog which contains Stories The backlog items that the teams work on align the enterprise strategy and the program vision. Epics are identified, either business or architectural, and are progressively elaborated as they flow through the Portfolio Kanban System. The Kanban System makes the strategic business initiatives visible and brings a structured analysis process driven by economics. Epics are broken down into Features. Prioritization is guided by the Program Vision and Roadmap. We’ll take about prioritization later. Features are then broken down into Stories which are executed by the Agile teams. However, this isn’t a strict hierarchy. A Feature may emerge within the context of the Program and not have a parent Epic. Likewise, a Story may emerge within the content of the Team.
- OVERVIEW: If your audience is not familiar with the concept of cadence, you can explain it now. SAMPLE SPEAKER NOTES: The cadence is the division of time (or timebox) that provides a “heartbeat.” Cadence is critical for synchronizing teams on the Agile Release Train. All teams work on the same cadence (2 week sprints) to synchronize and align.
- OVERVIEW: Here, you can discuss the Sprint at the Team Level and the Program Increment, or PI, and Program Level SAMPLE SPEAKER NOTES: At the Team Level, the teams work in two week increments called Sprints. They begin each Sprint with detailed planning and end with a demo and a retrospective At the Program Level, the teams on the Agile Release Train works in 8 – 12 week increments, called Programs Increments, or PIs. A PI, begins with a higher level planning event, called Release Planning, and ends with a demo and retrospective known as “Inspect and Adapt.” The teams on the Agile Release Train develop on cadence, but can release on demand based on business needs. Are there any other questions about cadence and synchronization for alignment?
- OVERVIEW: Here, you can explain the importance of code quality. SAMPLE SPEAKER NOTES: Poor quality doesn’t scale. This speaks to the heart of agility. Many teams give the illusion of “going fast” but if they don’t build in quality, then speed and the ability to adapt to change degrades over time. The result: Agile teams that don’t apply code quality practices end up creating “technical debt” that, sooner or later, will prevent them from completing work. Lack of automation, lack of a testable design, poor attention to design patterns create tangled code. They cease being “agile.”
- OVERVIEW: Here, you can explain code quality in the level of detail required by your audience: The practices (Agile Architecture, continuous integration, and test-first development) Architecture as a first-class citizen, with architecture at the highest level in the form of Architectural Epics Demonstrations of tested code at the Team and Program Levels (Team Demo, System Demo, and PI Demo) Key roles (the Enterprise Architect and System Architect, as well as Release Management, DevOps, and the System Team) The construction of the Architectural Runway by teams under the guidance of the System Architect SAMPLE SPEAKER NOTES: Ron Jeffries, one of the original signatories of the Agile Manifesto has this to say about what he’s learned over the years: “looking back over all of my successful (and not so successful) projects, I’d apply XP (Extreme Programming) techniques to all of them, if I had them to do over”. That’s a strong statement but an important one. However, Extreme Programming isn’t that extreme. It has influenced the code quality practices emphasized in the Framework. SAFe focuses on three Code Quality practices: Agile Architecture, continuous integration, and test-first development. Agile Architecture brings together architectural guidance provided by the Enterprise and System Architects which is then validated by the teams with short feedback loops as they build the Architectural Runway. Architectural Runway is the code needed to support near-term functionality. We rely heavily on continuous integration. This gives the teams fast feedback if code is broken, as well as reduces risk when code is integrated. Teams use test-first approaches, such as test-driven development, acceptance test-driven development, and automated testing, to test early and often. These techniques help us “build the right software” while “building it right,” advocated by Andrew Dassing. Do you have any further questions about code quality in SAFe?
- OVERVIEW: Here, you can explain why the Framework uses the term “relentless improvement” rather than “continuous improvement.” SAMPLE SPEAKER NOTES: There is a Japanese word in Lean called “kaizen” which means the art of practicing continuous improvement with a sense of urgency and danger. This term is often translated into “continuous improvement.” SAFe takes this a step further by calling it “relentless improvement” to create a sense of urgency. Events are built into SAFe to ensure this happens.
- OVERVIEW: Here, you can reference the House of Lean’s pillar of relentless improvement and explain how the Framework supports it. SAMPLE SPEAKER NOTES: One of the pillars of the House of Lean is relentless improvement. An enterprise is never agile; it is always becoming more agile. There are multiple events which serve as forcing functions for relentless improvement. Each cross-functional team conducts a retrospective at the end of every sprint. In this retrospective, the team reflects on the good and the bad and collaborates on ways to improve. Collectively, the entire Agile Release Train has a retrospective at the end of every Program Increment called the Inspect and Adapt Workshop. During this workshop, root cause analysis is used to identify Program Level problems and ways to improve. Though everyone is responsible for relentless improvement, there are several key roles: the Release Train Engineer and the Business Owners. The Release Train Engineer facilitates the processes. The Business Owners and other Lean-Agile Leaders remove impediments which the teams themselves cannot remove. During the Innovation and Planning (IP) sprint, teams may have continuing education opportunities and “hackathons” where new approaches, tools, techniques, and prototypes are explored and demonstrated. Fact-based metrics are used as feedback loops to measure the rapid progress towards working, high quality software which satisfies the needs of the business.
- OVERVIEW: Here, you can give an overview of economic prioritization. SAMPLE SPEAKER NOTES: As a SAFe principle, we want to make sound economic decisions at all time. An economic decision-making framework is in place to facilitate this. As Donald Reinertsen in his seminal work “The Principles of Product Development Flow” says, “You can ignore economics, but they won’t ignore you”. It is critical that we understand and apply principles, like ignoring sunk costs, understanding the cost of delay, and decentralizing decision-making, in order to prioritize by economics.
- OVERVIEW: Here, you may or may not go into detail based on your audience. At the Portfolio Level, you might describe Strategic Themes, the Portfolio Kanban System, and Lean-Agile budgeting. At the Program Level, you might discuss the guidance provided by the Program Vision, Roadmap, and WSJF in prioritizing the Program Backlog. You can also explain how PI Objectives are used to measure value delivery. Finally, you might mention how releasing on demand is driven by business needs and should be done frequently. SAMPLE SPEAKER NOTES: The connection between the enterprise business strategy and the Portfolio is through Strategic Themes. This brief list guides budgeting and prioritization, and facilitates decision-making. Epics are progressively analyzed as they move through the Portfolio Kanban System to determine the most important initiatives to do at that given point in time, knowing market conditions may change. It also assures capacity matching. Budgets are also allocated to Agile Release Trains in order to decentralize decisions which can be made quickly and efficiently at the Program Level. Would you like to hear more about Lean-Agile Budgeting? Sequencing of Epics and Features is driven by a Lean approach called Weighted Shortest Job First (WSJF) which looks at the cost of delaying one item in order to do another. It looks at both the cost of delay and the effort to complete it. Would you like to hear more about WSJF? The business value delivered at the end of each Program Increment is assessed by the Business Owners to measure planned vs. actual. The business is responsible for prioritizing and the teams are responsible for delivering. Finally, the business determines when a working increment of software needs to be released, rather than the more rigid waterfall approach of delivering everything at the end.
- OVERVIEW: You can use this slide to bring thing “full circle” and summarize what your audience has learned. You can also pause here to take questions, or use the final slide which simply says “Questions?” SAMPLE SPEAKER NOTES: We’re back where we started. We saw that roles, artifacts, and activities are clearly defined based on proven principles and practices. After decomposing the SAFe Big Picture into it’s constituent parts, I hope we’ve learned that it’s a simple, powerful and easily understood framework for managing complex software and systems development.
- Questions?