“Achieving Business Agility at Small to Mid-Scale: A Guide to Enterprise Wide Effectiveness With Lean-Agile Patterns” is a work in process. It is being shared so that interested readers can provide feedback to the authors. Please do so on the the True North Consortium LinkedIn discussion group. You may also be interested in the companion piece Lean-Agile at the Team: A Lean Approach to Scrum and Kanban Many of the articles pointed to need updating or are incomplete. They are provided to allow the interested reader to see what is being included. Also be aware that some articles require subscribing to this site (no fee for this but you will get monthly emails from us which you can opt out of). This page should be thought of as an extended table of contents. The book will be printed by taking the pages pointed to in this document and putting them together. When a separate page exists for the chapter, a link to the chapter is placed to the right of the chapter title. Note that several of the pages here require registration on either our university or our portal (registration is free).
IntroductionWho this book is forThe task is, not so much to see what no one has seen yet; but to think what nobody has thought yet, about what everybody sees. – Arthur Schopenhauer This book is written more for the attitude a person has than for the role they fill. If you are looking to know how to create more value for your organization or its customers this book is for you. This is not yet another ‘Agile’ book trying to provide a path for you to follow. It is a book that presents both experience and theory so that you can make decisions for yourself without having to reinvent the wheel. The gap between what is known and not used is much bigger than the gap between what is known and needed. This book focuses on what we know works, but has not been widely adopted. It is written from the perspective of internal change agents. However, regardless of your role, improvement has as much to do with conveying concepts to those you work with as they do your understanding them. Because this book takes an holistic view of the challenge of organizational improvement, it can be used by anyone to help influence any other role. If you are a small company (less than 100 in technology) who is looking to do SAFe and want to get a quick review of what’s in store, read these two chapters.
If you come across any terms you are not familiar with, just take the links present as needed. Why we need a new approachI am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Buckminster Fuller Those who cannot remember the past are condemned to repeat it. George Santayana Insanity – doing the same thing over and over and expecting a different result – Albert Einstein The software industry has come a long way in 20 years. However, the movement from waterfall to Agile is far from complete. The challenge is that while waterfall’s mindset of predictability and stage gates has been fairly acknowledged as being less than effective, the team-centric focus of Agile has limited its effectiveness as well. The lack of a focus on business agility, an unclear role for management, and how to coordinate multiple teams, has left many organizations with reasonably effective teams but still being unable to deliver value effectively. There has long been a belief by many promoting Agile that intelligent people in self-organizing teams will figure things out if given a few basic practices and principles. Evidence shows otherwise – not because of a lack of intelligence but because they are busy working and often don’t step back and take the time required to figure things out. This is not to say that self-organization isn’t important – it is. But it is best done when teams know what they want to do. This is why our current way of giving some intense training and leaving people alone or, alternatively, providing expensive coaching is expensive. The first is expensive in people’s time the second expensive to the company’s budget. People need both a way to start and a way to overcome challenges that present themselves. Taking advantage of people’s experience while providing them a support system while learning is a must. Many Agilists, and Scrum (the most common Agile framework)proponents in particular have long claimed the goal is to “be Agile.” I believe this is a mis-guided goal. Not surprisingly, it leads to executives and management not embracing Agile which has become a bad word in many organizations. There are several reasons for this. First of all, requiring people to change values is both more optimistic than evidence suggests and in some ways demeaning as it doesn’t respect where they are. Jerry Sternin’s observation that “it is easier to work your way into a new way of thinking than think your way into a new way of working” is consistent with Lean’s focus on eco-systems. But more than a shift from people to environment is needed. Our industry is overly focused on certifications and frameworks. Improvement is a journey and the goal is to get better, forever. The latest approaches to Agile at Scale, such as SAFe, LeSS, and DAD, but all are frameworks. Frameworks are useful to use as tools. However, they can cause challenges when used as solutions. We cannot solve our challenges based on set solutions, even those that contain options. What is needed is an approach that is an integration of business and development needs that can both guide us with principles and take advantage of existing patterns of success. Fortunately, one has existed for decades – Lean Thinking. The challenge is that the physical world is quite different from the software world and a good translation of principles and practices has not been, as yet, achieved. This is one intention of this book. This work is based on Lean-Agile. This means that the context for all the work is Lean Thinking. Lean Thinking provides an holistic view, focuses on the eco-system within which work takes place, Lean Thinking for the mid-scaleTheory without experience is worthless. Experience without theory is expensive. (paraphrase) – Edwards Deming Lean-Agile is not just Agile wrapped in Lean. And especially not Agile with Lean principles in it. It is a different mindset that incorporates the good in Agile.
Why Agile should be more predictable than waterfallMany executives have been led to believe that Agile is inherently less predictable than a waterfall approach. However, Agile, when wrapped in Lean Thinking, can be more predictable because it enables working directly on the true causes of unpredictability in software development. Waterfall’s large projects and stage gate approach cause delays in feedback, workflow, testing and integration. These delays inherently create a significant amount of rework (redoing requirements, reworking code that missed requirements, finding bugs, thrashing during integration). This work, of course, is never planned for, and therefore result in inherently bad estimation, not to mention that eliminating this extra work improves productivity.
The Business Case for AgilityBusiness agility is the ability to realize value quickly, predictably, sustainably and with high quality. This chapter explains why this is so important and provides some concepts which are useful to achieve it.
FLow for Enterprise TransformationIntroduction to FLEXFLEX is Net Objectives’ collection of Lean-Agile practices and principles that can be used to achieve business Agility. It is not a framework but rather a set of patterns that can be used on their own or applied to existing frameworks and methods.
Understand your value streamThe value stream is one of the most important concepts in Lean. The value stream can be thought of as the flow of work that takes an idea to the point of realization of value. Notice that what is most important is the realization of value because merely delivering product is of no value by itself. You must attend to the total time from start until your organization or your customers realize value from your efforts.
Why looking at time is so importantOne of the main tenets of Lean is to attend to the time between starting a project until its completion. The reason is that delays in workflow and/or feedback creates additional work to be done. By eliminating these delays, waste is eliminated.
Common challenges to flowBecause systems drive behavior and most companies are organized in similar ways, it should not be surprising that most organizations have similar challenges.
FLEX solutionsThe solutions to the common challenges are also similar. The order in which a plan is created has to be tailored to the organization doing the adoption, of course.
FLEX and the Value StreamLean solutions are based on the realization of value and attending to the value stream to enhance one’s ability to do it. This chapter represents FLEX as a value stream.
Lean PracticesLean Portfolio ManagementAlthough our Lean Portfolio Management webinar is part of our Simplifying SAFe webinar series., it is independent of SAFe itself as it presents our approach and not SAFe’s approach to Lean Portfolio Management.
Lean-Agile Product ManagementLean-Agile Product Management is a key part of Business Agility: the quick realization of value predictably, sustainably and with high quality. It is primarily focused on the agile Business Discovery of value to turn goals and objectives into appropriately defined and scoped requirements of those aspects of a system being built. These higher level, but well scoped and defined requirements feed business delivery by providing thinly sliced segments that can be quickly developed, providing quick feedback and the ability to pivot. Product management therefore holds business owners as its primary customers and guides business delivery to meet the expectations of its customers.
Acceptance Test-Driven Development (ATDD)Acceptance Test-Driven Development epitomizes Lean-Agile more than any other practice. It’s heart is collaboration between product owners, developers and testers to both understand what is needed by the customer as well as how to set up the development team to implement and validate it.
Planning EventsPlanning Events are almost always useful when kicking off a transition to Lean-Agile methods. For mid-scale to larger organizations they are also sometimes useful on an ongoing basis.
Development cadence and synchronizationCadence means to do work at a specified interval of time. One can think of cadence as a heatbeat. Scrum implements cadence at the team level with Sprints. At the end/beginning of a sprint a demo and retrospection are done as well as a refinement of what work will be done. Kanban merely has a timeframe within which these occur. The main difference is that in Kanban these can more easily be done on a continuous basis if desired. In any event, the cadence of all teams should be synchronized so that there is a time for teams to reflect on how they are working together. This also provides an opportunity to test the integration of the teams’ work. TeamsLean-Agile at the teamThere are many ways to achieve agility at the teams – Scrum, Kanban, a combination of the two or even a pure flow model.
Shared servicesShared services, such as business intelligence, need to be managed differently from the development teams in trains. There are a few reasons for this. First, they are pulled in different directions from multiple teams in multiple programs. Second, the requests made often occur due to discoveries made during a sprint so it is often difficult to plan for. Because of these challenges, shared services most usually are best run with Kanban.
DevOpsOrganization-wideBusiness ArchitectureBusiness Architecture is “a blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands.”ref It is an overlooked, but essential ingredient of Agile Product Management as it relates new offerings to existing capabilities and can inform how our work management should be done to improve our systems.
VisibilityBeing able to see the work, workflow, impediments and constraints are critical aspects of a collaborating, well run organization.
Dependency management, collaboration and planning at small to mid-scaleWhen development organizations are large and not able to deliver to delivering software on a frequent basis, a full two-day planning event that decides what to work on for the next 2-3 months may make sense. But at small scale, doing this is far from Agile. This article describes different ways of running planning events. The following methods are one’s that we’ve seen work really well in the situations discussed. They are given in approximate order of being more desirable. The key is to try what appears to be best and then adjust as you learn.
Reorganizing the talentTeams should be organized in such a way that the value stream that the train is involved in stays mostly within the team. Work should be able to be brought to the teams, not having the teams be reformed for every new chunk of work. While stability is a desired trait of trains, complete stabilty is neither achievable nor desirable. Growing organizations need to embed new team members as well as adjust to changes in strategy.
The relationship between visualization and reorganization.This chapter puts the concepts of visibility and reorganization into context with each other. An advantage of using Lean Thinking behind both Scrum and Kanban is that both tend to ignore one or the other in their own manner. Scrum prescribes reorganization into cross-functional teams while LKU Kanban says reorganization is “orthogonal to Kanban” most likely because LKU Kanban is based more on theory of constraints which does not focus on reorganization
New RolesBusiness ArchitectThe role of the business architect is to clarify the business A business architect is a practitioner of business architecture, a discipline concerned with developing and maintaining business capabilities of the enterprise in line with the corporate strategy as well as contributing to the business strategy and plans. This also includes design of capability models and related architectural solutions of business tasks, mapping capability functionality to the internal and external resources, developing business transformation plans jointly with senior business management, handling business solutions to the delivery and operational business functions of the company, developing and maintaining architectural governance and controls over implementation. For each step of the business transformation plan, business architects contribute in development of a blueprint of the enterprise in order to promote a common understanding of the organization and alignment of strategic objectives with tactical demands.[ref] Product ManagerThe Product Manager is the “face” of Business value to the development value stream as a whole. Product Owners go to the Product Manager for anything that requires beyond their level of customer/stakeholder understanding.
Technology Delivery Manager / RTEThe Technology Delivery Manager (TDM) is responsible for managing the delivery of the technology solution of a business increment and the flow and continual delivery of the program or value stream producing it. The Technology Delivery Manager is the person responsible for ensuring and managing the Business evolution of the system – that is, building the system oriented around quick delivery of Business value increments. The Technology Delivery Manager is responsible to maintain the functional integrity of the system throughout its development and deployment. The Technology Delivery Manager is responsible for risks associated with delivery. The TDM is a superset of responsibilities of SAFe’s RTE. If one is doing SAFe, it is best to just call it the RTE and expand the role a little.
Application Development Manager / Systems ArchitectThe Application Development Manager (ADM) is responsible for the holistic integrity and functionality of technical solutions and system products. This includes setting technology boundaries, policies, and engineering practices and standards for system evolution and integrity. Thus, the ADM role is about the content of the system. To do this, the Application Development Manager is responsible for creating “just-enough” architecture, plus identifying standards and processes that directly relate to successfully implementing the product itself. Counterbalancing this, the Application Development Manager also makes sure that no architectural, process, and standards constraints are placed on implementation and maintenance beyond the minimum needed to build the product correctly. In SAFe, the ADM role is played by the systems architect and solution architect.
Leadership and managementManagement, of course, is not a new role. However, in the Agile space it is just coming into its own, having not even been mentioned once in the Agile manifesto. Different approaches present management in different ways. Our view is that management’s role is to create the eco-system in which teams can work in a self-organizing manner towards their organization’s goals.
Technical AgilityEmergent ArchitectureA key tenet of Agile development is that architecture has to emerge. This is sometimes also called Agile Architecture.
Test-First at the teamTest-driven development is the practice of collaborating with all roles involved in a requirement and writing acceptance criteria for the behavior desired. It actually happens at all levels of Agile requirements but is best known at the product owner – development team boundary and with developers working with each other. The first is call Acceptance Test-Driven Development because we are looking for the acceptance criteria of the ask. At the team level, it is called Unit Test-Driven Development. There is some conofusion that TDD refers to Unit TDD but that is only because when TDD was first introduced with eXtreme Programming, it was being done primarily by developers.
Getting startedImproving your company’s cultureCulture eats strategy for lunch. Agile is intended to create a new culture. Many agilists talk about being Agile instead of doing Agile. The challenge is that it is difficult to change one’s being. While trust and respect is a key value of Agile, it should be a key value for every approach. The question isn’t if trust and respect is a good idea, it’s a question of how do you create it if the culture isn’t already demonstrating it. This chapter discusses how cultures are a result of management systems in an organization and how to change both the management system and thereby the culture of an organization.
Collaborate across the enterprise: The GuardrailsAgile frameworks tend to have people agree to work together by using the framework. This is one of their appeals – providing guidance on how to collaborate. But since no one-size fits all, this runs the risk of becoming dogmatic and following the framework instead of using it as the basis for what works. We believe an agreement on how to work together, regardless of approach, is critical. We call these “guardrails” because they act as guides wherein you they can be followed however appropriate by different roles as long as one stays consistent with their intent. The basic agreements. We agree to:
How people learnBefore beginning an adoption or transformation it is important to understand how people learn and how organizations change. While on one hand many people like to be told what to do, there is no one-size-fits-all approach. So transformation leaders find themselves in the dilemma of needing pseudo packaged solutions that may or may not fit their needs. Also, people have different learning styles and learn best over time. Much of the intensive training many undergo just before an adoption bounces off. In addition, much of this training is not real hands on, but either PowerPoint presentations or exercises that mostly convey concepts.
Scaled learningAgile has grown exponentially. This has created a demand for training that is also growing exponentially. It is unfortunate that most trainings provided, however, have not followed good training practices but have been intensive 2-4 days classes without doing any real work in the classroom. This has created a knowledge gap where people have supposedly learned something (even been certified in it) but don’t know how to apply it. This gap has often been addressed through onsite coaching. However, as more and more large companies are adopting Agile the approach of intense training and expensive coaching is no longer a viable alternative for most companies.
Roadmaps for discovery and the roll-outRoadmaps need to be adjusted for who is driving, who is involved, what the culture of the organization is and where they are. The following figure shows a starting roadmap before being tailored for these factors. This chapter discusses both roadmaps to discover what you need to do as well as how to roll it out.
ImprovementGauging your progressThere is much more to improvement than merely “inspecting and adapting.” It is important to understand different methods of improvement (such as Plan-Do-Study-Act, double-loop learning, OODA), learning styles, how people best learn, people’s biases against learning, how to measure your progress, the way complex systems react to change and if there’s a guide you can use to make hypothesis for improvement. Saying “just do it” just doesn’t do it.
Scorecards as roadmapsScorecards can be used as both an assessment of how an organization is doing and as a roadmap fro next steps.
Small to Large-Scale Support SystemComing soon. MiscellaneousA lightweight, Lean approach to Agile at mid-scale (100-1000 people in technology)This article is a synopsis of how to use FLEX at mid-scale.
Adopting SAFe at small to mid-scale overviewSAFe was designed for large organizations. Essential SAFe is intended to be used by programs within a large organization. This chapter discusses provides an overview how to adopt SAFe at small to mid- scale by using just what you need and adding some concepts from FLEX.
Adopting SAFe at small to mid-scale in depthSAFe was designed for large organizations. Essential SAFe is intended to be used by programs within a large organization. This chapter discusses provides an overview how to adopt SAFe at small to mid- scale by using just what you need and adding some concepts from FLEX.
Resources related to Business AgilityA Primer on Emergent Design (Article) |
For more information, please read the paper 
See a short video on 
For more information, please see the 