Agile India 2016 Keynote - The Lean-Agile Enterprise Awakens- Scalable and Modular is the future!
•
10 j'aime•2,263 vues
New competitive threats often require organizations to build increasingly complex, interconnected and sophisticated software and systems, faster, better and cheaper. Most organizations are not equipped to meet this new challenge! Meanwhile small, nimble competitors, like Airbnb and Uber are taking a big bite on the profits of the giants. So what’s the answer? What have we learned in the past decade from our adventures in agile and our attempts at scaling? What does the future hold? In this talk, Richard Knaster, Principal Consultant and SAFe Fellow, discusses a more scalable and modular lean-agile approach that enables even the largest enterprises to compete with smaller and nimbler competitors that are disrupting companies in all industries. Richard is a Principal Contributor to the Scaled Agile Framework and previously worked at IBM where his roles included Chief Agile Methodologist. World Wide Agile Practice Manager and various product management roles in the Rational Brand.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (19)
Similaire à Agile India 2016 Keynote - The Lean-Agile Enterprise Awakens- Scalable and Modular is the future!
Similaire à Agile India 2016 Keynote - The Lean-Agile Enterprise Awakens- Scalable and Modular is the future! (20)
Dernier
Dernier (20)
Agile India 2016 Keynote - The Lean-Agile Enterprise Awakens- Scalable and Modular is the future!
- 1. 1© 2016 Scaled Agile, Inc. All Rights Reserved. 1.V4.0.0 V4.0.2© 2016 Scaled Agile, Inc. All Rights Reserved. The Lean-Agile Enterprise Awakens: Scalable and Modular is the Future! Richard Knaster Principal Consultant, SAFe Fellow Scaled Agile, Inc. @richardknaster
- 2. 2© 2016 Scaled Agile, Inc. All Rights Reserved. 1. About me • Husband, Dad • Two sons, Jason and Cole • Married for 28 years • Principal Consultant, SAFe Fellow, Scaled Agile Inc. Past: IBM Chief Agile Methodologist, IBM WW Agile Practice Manager Other roles: Director, Development, Divisional CIO, CTO, Product Manager, Project Manager, Business Analyst, Developer
- 3. 3© 2016 Scaled Agile, Inc. All Rights Reserved. 1. The New Reality “The world is now changing at a rate at which the basic systems, structures, and cultures built over the past century cannot keep up with the demands being placed on them. Incremental adjustments to how you manage and strategize, no matter how clever, are not up to the job. - John P. Kotter – John P. Kotter
- 4. 4© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Enterprises can’t keep pace Our methods must keep pace with an increasingly complex world. Business innovation is increasingly being delivered via software and systems, and companies must respond quickly to challenges and opportunities Agile has produced better business outcomes—however, it was developed for small, collocated teams Agile methods alone don’t address the top-down concerns of business strategy, as Agile teams work bottom- up.
- 5. 5© 2016 Scaled Agile, Inc. All Rights Reserved. 1. A more scalable and modular approach is needed SAFe synchronizes alignment, collaboration, and delivery for large numbers of teams 1. Built-In Quality 2. Program execution 3. Alignment 4. Transparency Core Values
- 6. 6© 2016 Scaled Agile, Inc. All Rights Reserved. 1. 6 What makes a Framework scalable and modular?
- 7. 7© 2016 Scaled Agile, Inc. All Rights Reserved. 1. A scalable and modular pattern 1. Start simple and expand for large software & systems 2. Scale work across different levels of the enterprise 3. Adapt to different sized enterprises 4. Organize around value, not silos 5. Use a scalable requirements model & content authority 6. Use principles and values to make it work in your context 7. Foster informal learning networks 8. Empower teams to chose their ways of working
- 8. 8© 2016 Scaled Agile, Inc. All Rights Reserved. 1. You can start simple and lightweight… Well suited for small to medium size, independent programs
- 9. 9© 2016 Scaled Agile, Inc. All Rights Reserved. 1. And expand to large value streams Well suited for the largest, most complex programs
- 10. 10© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Scale work across different levels of the enterprise Portfolio Value Streams Progra m Team Communities of Practice Systems Thinking informs us that the entire system must be agile
- 11. 11© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Overview of SAFe 4.0 Levels Portfolio – Guidance for strategy formulation and portfolio communication, organizing and funding Value Streams, managing the flow of larger initiatives, governance and cross Value Stream coordination Value Stream – For those building the world’s largest software and systems, SAFe includes Solution Intent, Solution Management, Engineering and Architecture, Agile Customer and Supplier relationships, and ART Coordination Program – Describes Agile Release Trains, teams of Agile Teams that build features, solutions and subsystems. ARTs align teams to a common mission, provide architectural and UX governance, facilitate flow, and provide objective evidence of progress and fitness for purpose. Team –SAFe teams can apply Scrum, Kanban or a hybrid of their choosing
- 12. 12© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Single-ART Value Streams, Value Stream Level not needed (3-Level SAFe) Smaller business Multiple Value Streams, some with multiple ARTs; full Solution context needed (4-Level SAFe) Larger business Multiple SAFe portfolios, some larger, some smaller (multiple instances of 3- and 4-Level SAFe) Largest business Adapt the framework to different size enterprises
- 13. 13© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Legacy and Agile organizational structures don’t match The organizational structure we use today is over 100 years old. It was not built to be fast and agile.– John P. Kotter Source: Adapted from Accelerate John P. Kotter
- 14. 14© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Optimized for vertical communication Most organizations are organized in silos Friction across the silos Location via function Political boundaries between functions Communication across silos does not happen with sufficient speed and effectiveness.
- 15. 15© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Agile Release Train
- 16. 16© 2016 Scaled Agile, Inc. All Rights Reserved. 1. The ART “takes a systems view” Business Product Mgmt Hardware Software Testing A G I L E R E L E A S E T R A I N Agile Teams PMO DeploymentSys Eng. Cross-functional Train Cross-functional Teams
- 17. 17© 2016 Scaled Agile, Inc. All Rights Reserved. 1. ART roles that support scaling teams Release Train Engineer acts as the Chief Scrum Master for the train Business Owners are the key stakeholders on the Agile Release Train Product Management owns, defines, and prioritizes the program backlog System Architect-Engineering provides architectural guidance and technical enablement to the teams on the train The System Team provides process and tools to integrate and evaluate assets early and often
- 18. 18© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Use a scalable requirements model & content authority Epics are large initiatives and replace the need for Projects Capabilities describe the higher level behaviors of a Solution Features are services that fulfill user needs User stories are statements of intent PPM Mgmt VS Mgmt Product Mgmt Product Owner
- 19. 19© 2016 Scaled Agile, Inc. All Rights Reserved. 1. The business and IT must steer the train together At scale, a single person cannot handle product and market strategy while also being dedicated to an Agile team 2..4 1 1..21 Product Manager owns Program Backlog Product Owner owns Team Backlog Team implements value
- 20. 20© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Scalable flow of value through enterprise Kanban Epics Capabilities Features
- 21. 21© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Program Kanban for flow and feature readiness BacklogAnalysisFunnel Implementing AnalysisReviewFunnel WIP limit Program Epics Features Breakdown of epics Done WIP limit WIP limit ✓ ✓ ✓ ✓ ✓ Individual Features
- 22. 22© 2016 Scaled Agile, Inc. All Rights Reserved. 1. SAFe teams have a choice of methods Most teams use Scrum, but Scrum is not exclusive Some teams—especially maintenance teams, DevOps, and System Teams—often apply Kanban as their base practice Scrum teams can apply Kanban to visualize work, establish WIP limits, and illustrate bottlenecks Scrum
- 23. 23© 2016 Scaled Agile, Inc. All Rights Reserved. 1. New Foundation layer enables adoption in your context Lean-Agile Leaders Communities of Practice Core Values, Lean-Agile Mindset, and SAFe Principles Implementing 1,2,3
- 24. 24© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Foster Informal Learning Networks (CoP) An informal group of individual collaborators and other experts, acting within the context of a portfolio, that has a mission of sharing and advancing practical knowledge in one or more relevant domains Team A Team B Team M Team N Community of Practice (CoP)
- 25. 25© 2016 Scaled Agile, Inc. All Rights Reserved. 1. SAFe is a principles based, adaptable framework #1 Take an economic view #2 Apply systems thinking #3 Assume variability; preserve options #4 Build incrementally with fast, integrated learning cycles #5 Base milestones on objective evaluation of working systems #6 Visualize and limit WIP, reduce batch sizes, and manage queue lengths #7 Apply cadence, synchronize with cross-domain planning #8 Unlock the intrinsic motivation of knowledge workers #9 Decentralize decision-making
- 26. 26© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Embrace Lean-Agile Mindset LEADERSHIP Respectfor peopleandculture Flow Innovation Relentless improvement VALUE House of Lean Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Agile Manifesto
- 27. 27© 2016 Scaled Agile, Inc. All Rights Reserved. 1. More ways to adapt the framework to your enterprise needs
- 28. 28© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Empowerment/governance with Lean-Agile Budgeting Traditional: ► Project cost accounting; projects are the basic unit of work ► People are “brought to the work” ► Measure peoples “compliance” to inherently uncertain work Result: - Friction and high overhead - Us vs. them - Low throughput, productivity - Low morale Fund Value Streams, not projects Empower Value Stream content authority Approve Epic Level initiatives Exercise fiscal governance with dynamic budgeting Lean-Agile: Beyond project cost accounting with SAFe Provide objective evidence of fitness for purpose 3 4 5 1 2 GOVERNANCE EMPOW ERMENT Result: - Full control of total spend - No budget surprises - Higher throughput - Higher morale
- 29. 29© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Use what you need from the Value Stream
- 30. 30© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Spanning palette increases flexibility Most often applied at the Value Stream and/or Program Levels Some can apply to the Portfolio or Team Levels (e.g., Metrics, Vision, Roadmap, etc.) Use only what is needed for each SAFe® level in your Enterprise This is a floating surface for roles and artifacts that can apply to multiple levels of SAFe. It is an essential part of the configurability and modularity of the framework. Spanning Palette
- 31. 31© 2016 Scaled Agile, Inc. All Rights Reserved. 1. All Agile teams are on the train PO PO PO S M Dolphins (Ride control) Iguanas (Feature team) Bears (Player portal) Eagles (Feature team) PO Plan together Integrate and demo together Learn together Synchronize ProgramIncrementPIPlanning ProgramIncrementPIPlanning S M
- 32. 32© 2016 Scaled Agile, Inc. All Rights Reserved. 1. All teams participate in PI Planning, and commit to Team PI Objectives and plan delivery of dependencies to other teams Teams publish Iteration Goals every Iteration Teams participate in Scrum of Scrums and PO Sync meetings (or the combined ART Sync) Teams continuously integrate with all other teams. The teams participate in the fortnightly System Demo, PI System Demo and Solution Demo (large Value Streams) to prove successful solution integration. Teams are part of the Inspect and Adapt workshop, improving the train as a whole Teams help forecast by estimating Epics, Capabilities and Features in story points Scale from team to train
- 33. 33© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Primary aspects of Coordination Cadence and synchronization Injection of new Portfolio Level Epics, and Enablers Program/content management and enterprise architecture Portfolio Roadmap Deployment and Release
- 34. 34© 2016 Scaled Agile, Inc. All Rights Reserved. 1. Public SAFe SPC4 Training, Bengaluru April 19-22 Implementing SAFe 4.0 with SPC4 Certification Take advantage of early registration discount Location: Cisco Facility - Bangalore, Karnataka SAI Instructor – Joe Vallone Registration and additional details here: http://spcbangaloreapril.doattend.com
- 35. 35© 2016 Scaled Agile, Inc. All Rights Reserved. 1.351. Is it SAFe to adopt? Proven by over 21 Case Studies
- 36. 36© 2016 Scaled Agile, Inc. All Rights Reserved. 1.361. Gain the Knowledge Explore the SAFe® knowledge base and find free resources at: ScaledAgileFramework.com Leading SAFe® with SA Certification Implementing SAFe® with SPC4 Certification Find SAFe® training worldwide at: ScaledAgile.com
- 37. 37© 2016 Scaled Agile, Inc. All Rights Reserved. 1.371. Questions?
Notes de l'éditeur
- Welcome/intros Housekeeping “Our job is to help you help other organizations” To paraphrase Deming, “Our problems might be different, but the solutions can be universal” We’re working together to solve problems Why are we here? Better software makes the world a better place. (Bring up an example)… Thus we’re motivated for same purposes.
- Business innovation is increasingly being delivered via software and systems. New competitive threats and opportunities are emerging faster than most companies can reasonably respond. Adopting agile has produced better business outcomes, however, it was developed for small, co-located teams. Agile methods alone do not address the top-down concerns of business strategy, as agile teams work bottoms-up. Kotter is the author of 19 books, 12 of which have been business bestsellers and two of which are overall New York Times bestsellers
- EXAMPLE NARRATION: Our modern world runs on software. In order to keep pace, we must build increasingly complex and sophisticated software systems. Doing so requires larger teams and continuously rethinking the methods and practices – part art, science, engineering, mathematics, social science – that we use to organize and manage these important activities. Our traditional methods of waterfall development and iterative and incremental development are not keeping pace with these increasing demands. The increasing use of agile development is helping the industry address some of these challenges. However, team level agility does not provide the global alignment needed to optimize outcomes and extend the benefits of agile to the largest enterprises. For that, we need more advanced thinking. The Scaled Agile Framework represents one such set of advances. It is offered in a public facing form, so that every practitioner, team, program, and enterprise can enjoy the benefits of delivering ever better software at an ever faster pace. Your users will surely appreciate the benefits, too, because better software makes the world a better place. Lean and Agile are the best way we know to build enterprise software systems. When we find another way, we'll be developing that. We exist to improve the way we develop enterprise software systems.
- Framework scales to accommodate organizations with thousands of people. Some large adopters may have as many 400 teams and 40-50 trains. This states the Core Values that we treasure and base the framework on. The Framework creates good code/components quality, which is important, because “You can’t scale crappy code.” Lean is extremely keen on trust and transparency. The framework depends on transparency. Lean won’t work if organization hides behind its politics.
- 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 enablers. Enablers are the exploration, architecture, and infrastructure needed to support the functionality. Backlog items are elaborated at a level of detail appropriate to the phase of development. They are not commitments. Rather, they represent opportunities.
- Some large adopters may have as many 400 teams and 40-50 trains.
- OVERVIEW: Introduce the Portfolio, Value Stream, Program, and Team levels. The Enterprise icon is highlighted to represent the connection between the enterprise business strategy and a SAFe Portfolio SAMPLE SPEAKER NOTES: Here we see the four levels of SAFe: Portfolio, Value Stream, Program, and Team. In the small to midsize enterprise, one SAFe portfolio can typically be used to govern the entire technical solution set. In the larger enterprise (those with more than 500 – 1,000 technical practitioners), there can be multiple SAFe portfolios, one for each line of business. Each SAFe portfolio contains a set of Value Streams and the additional elements necessary to provide funding and governance for the products, services, and Solutions that the Enterprise needs to fulfill some element of the business strategy. The Value Stream Level is intended for builders of large and complex solutions that typically require multiple ARTs, as well as the contribution of Suppliers. It is intended for enterprises that face the largest systems challenges, building multidisciplinary and cyber-physical systems that contain software, hardware, electrical and electronic, optics, mechanics, fluidics, and more. Not all organizations will need the Value Stream Level. (NOTE: If you are able to access the Scaled Agile Framework website, this would be a good time to demo the expand/collapse button) The Team and Program Levels make up the long-lived, self-organizing virtual organization known as the Agile Release Train (ART). Without teams, there can be no program. The ART plans, commits, and executes together. The “Agile Release Train” metaphor is used to communicate several key concepts: The train departs the station and arrives at the next destination on a reliable schedule, which provides for fixed cadence, standard ART velocity, and predictable planning (and in many cases, cadence-based releases). All “cargo,” including prototypes, models, software, hardware, documentation, etc., goes on the train. You’ll notice at the bottom the SAFe Core Values, Lean-Agile Mindset (represented by the House of Lean), and SAFe Principles. These articulate the time-proven principles upon which SAFe is based. Also on the bottom is “Implementing 1-2-3.” Based on the learning from hundreds of SAFe implementations, this simple model is a proven success model. Train implementers and Lean-Agile change agents Train all executives, managers, and leaders Train teams and launch Agile Release Trains In training all executives, managers, and leaders, you create your Lean-Agile Leaders, whom you’ll see on the left.
- “The world is now changing at a rate at which the basic systems, structures, and cultures built over the past century cannot keep up with the demands being placed on them. Incremental adjustments to how you manage and strategize, no matter how clever, are not up to the job. – John P. Kotter
- RTE- 5x more difficult than the Scrum Master. It’s much a harder than the Scrum Master role. With the Scrum Master role, there’s “some things I can change, some I can’t”. But the RTE must bring all the problems up to the stakeholders. PM – Typically (don’t have to) are the first level that interfaces with the customer. They own business vision and need customer exposure to support this. SA- Technical authority, collaborate with product management. ST – Assist the teams and team in testing and integration. They need to care about the release, otherwise they just “produce stuff”. They are more of a program improvement productivity team. BO- They are the stakeholders to the train. They say what they like and don’t like. They are the key decisions makers. They are other stakeholder to Product Management.
- Scalable Requirements model provides a way to express system behaviors: Epics, Capabilities, Features, Stories, Nonfunctional Requirements (NFRs), and more. These artifacts largely replace traditional system and requirements specifications with new paradigms based on lean-agile development. These newer paradigms are intended to help systems builders avoid focusing too early on a “point solution”, based on picking specific requirements and designs far too early in the learning process, but, rather, leave room for an emerging understanding based on intent, not specificity. In addition, in support of the nonnegotiable quality requirements imposed on the world’s most important systems, patterns and relationships for attributes, acceptance criteria, and testing are also included.
- ASK: Why these ratios? It’s not a formal process. Also, face-to-face is the key to making the process work. Thus, it can’t be managed effectively then with too many people. Point out the importance of having a PO dedicated to 1 or 2 teams PO must know all the "many languages" to gather different backlog items from all stakeholders
- Notice that the Kanban system has two sections: Program epic section The purpose of the program epic section of the program Kanban is to analyze and approve program epics and split them into features that will be further explored and implemented in the “downstream” feature section of the program. This section is not always present in the program Kanban; it depends on how frequently program epics occur in the local context of the program. Feature section The feature section facilitates readiness, prioritization, and implementation of features. Features may originate locally (either from program epics or introduced as individual features that don’t have a parent program epic). Or they can come from upstream Kanbans (Portfolio or Value Stream). In either case, features enter the Feature Funnel to be elaborated before commitment to a PI goal.
- The team may or may not need all the practices of, say, Scrum — which we fully support — though that is the general default for Agile Teams. But they might choose Kanban as their base practice. Or perhaps they have good experience with XP. In other words, in SAFe it’s the case that Scrum, Kanban, and XP are all “first-class citizens.” It’s all good. Teams can choose how they want to approach their Agile work. These methods ALL have value for just about any team. What’s truly important is that teams focus on doing a couple of things well: Integrate at every increment (worst case) Make sure every increment delivers system-level value Plan together, demo together, and improve together
- The “floating” spanning palette is a simple mechanism to increase the flexibility of the framework. It lets you apply the important constructs you need, at whatever level you need them. This increases framework configurability — that’s part of its value. So, for instance, the program always has a Vision, but so does the Value Stream Level. And in some cases, it’s even an important construct at the Team Level. Another example is the System Team. Who you need and where you need them depends on the architecture of the Solution. Build them where you need them, and don’t build them where you don’t.