Agile India 2016 Keynote - The Lean-Agile Enterprise Awakens- Scalable and Modular is the future!

Editor's Notes

1. 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.
2. 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
3. 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.
4. 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.
5. 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.
6. Some large adopters may have as many 400 teams and 40-50 trains.
7. 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.    
8. “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 
9. 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.
10. 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.
11. 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
12. 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.
13. 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
14. 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.