Overview

Creating business value that has a software component is a complex, somewhat unpredictable process. While it would be nice if leadership could just get what they demand, reality has shown otherwise. It is not possible to predict perfectly the results of taking actions and releasing product. Plans are often more fragile than we would like.

Many organizations are adopting Agile since it has demonstrated effectiveness at the teams. But Agile is a team-level approach that can create effective teams and not necessarily effective organizations.

There can be no one-size-fits-all framework. A framework must give enough structure must be given so that people know what to do while also giving guidance on how to adapt it to the organization’s dynamics. FLEX is designed to provide both.

FLEX is not a normal framework detailing a set of practices. Instead, it is designed to help you make better decisions and to coordinate all aspects of creating value for clients, both internal and external to the organization. The goal is to help an organization achieve business agility, the quick realization of value predictably, sustainably, and with high quality. 

FLEX is based on Lean principles, Agile values, a set of agreements on how people in different roles should work together. It offers a process for making decisions when conflicts arise. It gives guidance on how to start an adoption and to continue forward with it.

FLEX is designed to reduce risk, lower the impact of mistakes while catching them more quickly. it gets everyone on the same page, not by following a set of predefined practices but by getting people aligned to the task at hand: achieving business agility.

What is missing for most organizations, even those with just a few teams

Many companies have found that achieving Agile teams has not demonstrably improved their ability to deliver working software that adds value to their clients or internal service provides. Here are some of the issues they encounter.

• It takes too long to complete even relatively simple things.
• There is not a proper sequence of work to be done.
• Requirements are not clear.
• Too many things are being worked on.
• There is insufficient collaboration across teams.
• There are integration errors and challenges in Ops.

The inherent problem

Before trying to fix a problem, it is important to understand what is causing it. In most modern organizations there is a disconnect between the way we manage work and the way work takes place.

Compare Figures 1 and 2. Figure 1 represents a typical company hierarchy. People report to managers who are responsible for the work done by their teams. Figure 2 illustrates the  value stream, the flow of work across the organization (the up and down arrows represent management approvals).

This sets up a challenge shown in Figure 3: we manage people with management hierarchies while work goes across the organization.

This is not effective for two main reasons. First, it has us manage people instead of supporting them to make good decisions. Second, it tends to have us try to get people to be working hard all of the time. This takes our focus off the main goal, quickly realizing business value. Figure 3 asks, “Who is managing the value?” In most companies, it is a combination of people with this responsibility.

Figure 4 shows the work that must be done as flowing through an organization. Attending to the value stream, the flow of value is critical. In addition, there are other factors that require attention, as shown in the upper right of Figure 4.

Notice the five “phases” of work: Strategic planning, Lean-Agile Product Management, Planning, Implementation & Integration, and Release. This diagram is illustrative only. Feedback loops are present everywhere but are not shown for clarity of showing how the work flows.

If you are familiar with SAFe®, this may seem familiar. There is an important difference. In Figure 4, the flow of work is not superimposed upon the hierarchy of the business. There are no levels being shown. All of the elements shown are present in all organizations regardless of size. Challenges occur when the roles or backlogs get coupled to a level in the organization because all levels contain some needed concepts at any scale but a Full Level adoption of SAFe is not needed for any company with a technology group of 1000 people or less.

What needs to be done for Lean-Agile at scale

It is neither simple nor easy to get different roles in an organization working together cohesively. The principles of software development apply universally. It helps to study the patterns of successful adoption seen in many other organizations. At the same time, it helps to remember that each organization has aspects of it that are unique and must be attended to. These include culture, who is leading the Lean-Agile adoption, and the particular challenges the organization is having.

FLEX details what organizations must do, provides options for each step, and gives guidance on the proper order in which to implement changes. FLEX is neither a top-down nor a bottom-up approach. It recognizes that work needs to be aligned with the strategy of the organization and that teams need to be able to self-organize. This requires a different kind of management, one where middle management attends to the direction set by leadership and sets up an ecosystem where development can manifest the value desired. This is called Middle-Up-Down management (see Toward Middle-Up-Down Management: Accelerating Information Creation).

Assuming the goal is business agility, let’s look at what is needed for Lean-Agile at scale by looking at the order in which work takes place.

• Strategic planning
• Lean-Agile Product Development
• Implementation and integration
• Release and realization
• Other factors

Strategic planning

 Please read Create Clarity on What Represents Value for the Business and Its Customers. 

Lean-Agile Product Management

Lean-Agile Product Management is a key part of Business Agility. 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.

Lean-Agile Product Management works at all scales. It is especially important at smaller scale because small organizations can’t afford to be over-burdened with complex solutions.

 For more information, please read the Lean-Agile Product Management white paper. 

Using Minimum Business Increments (MBIs)

There are many overloaded terms these days: solutions, capabilities, MVPs, MMFs, epics and more to identify the smallest batch of value to work on. Unfortunately, nowhere is this named. MVPs by Eric Ries are intended to guide teams in the development of new products for early adopters – not for adding functionality to an existing system or even replacing systems.  In any event, not everyone builds any kind of product and the use of the term “product” is confusing for many.

We have found the term Minimum Business Increment (MBI) to be more useful and more intention-revealing. ​An MBI is the smallest piece of functionality that can be delivered that has value to the business.

 For more information, please read the article about the Minimum Business Increment.

Here are some of the aspects that define the MBI.

• Adds value for the customers of the business
• Provides valuable feedback that the right functionality is being built
• Provides valuable feedback that the functionality is being built the right way
• Provides functionality that can be verified as an increment that can be delivered
• Enhances the ability of the organization to deliver value in the future

MBIs must contain the value proposition for the client. But since they are about realization of value, not merely about deployment, they must also contain what is needed for full-value delivery. This includes what would be required for ops, marketing, support and anything else needed. In addition, any adverse affect an MBI may have on existing functionality must be incorporated into the MBI about to be built and not thrown over the fence to those who built the affected code.

The importance of MBIs cannot be overstated. The most effective way to lower cost of delay is to manifest value in small chunks. This also increases the efficiency of the development group. Consider the case where a team has three enhancements, each taking the same amount of time and each having the same importance. The quickest way to achieve value is if they work on one enhancement at a time, complete it, and then go on to the next. But they will very often be forced to start on all three. Figure 5 compares two scenarios of when work is done and when value is realized.

The interesting thing is that even if the Product Owners for A, B and C know that A is more important than C, it is likely they won’t have the team do them in the optimal order. But let’s say A, B and C can be sub-divided into MBIs. This enables the team to work on smaller enhancements and increase value manifestation even more. It also makes it easier to get the Product Owners to agree to the work being done serially. This is shown in Figure 6.

These results are even better than before. Of course, the decomposition into MBIs is insufficient. They need to be built by taking vertical, end-to-end slices in order to achieve quick feedback. This is illustrated in Figure 7.

Figure 8 illustrates how MBIs fit into the value stream from strategies to stories.

What happened to Epics, MVPs, and MMFs?

Notice that business increments and MBIs have taken the place of epics. The notion of an MVP is a poor fit for when building enhancement to new products. If you have trains that are creating new products for early adopters, then by all means use MVPs.

But perhaps more importantly, the use of MBIs allow for avoiding the redefinition and overloading of terms. What we can now do is have a refinement of our initiatives into business increments and then into MBIs and then into features and so on.

Sequencing the work

Work must be sequenced, not prioritized. Everything can be important but to resolve disagreements on importance when the work hits the teams and there is a conflict people at all levels need to understand which MBI is more important than the other.

Don Reinertsen suggests, “If you quantify one thing quantify cost of delay.” His weighted shortest job first (WSJF) can be used to sequence work in a manner that will maximize the return. While WSJF can be used before MBIs are well-formed, the portfolio backlog should be on MBIs. Doing WSJF on epics means you’ll be sequencing based on epics that contain some work that is not essential to more important work. You don’t want the most important part of an epic for which value can be realize early to hold up for lesser important aspects of the epic.

The best way to achieve this is to use Acceptance Test-Driven Development using Behavioral-Driven Development. This does not require full automation of the tests but can achieve great value when only the discovery and specification stages of it are done.

 For more information, please see the page about Acceptance Test-Driven Development using Behavioral-Driven Development

New roles

The role of the Product Manager has been around for over a decade. It is not always needed, however. Product managers are usually needed when multiple stakeholders are present and most have to use multiple teams driven by different Product Owners.

 For more information, please read the case study Product Manager and Product Owner (Case Study).

The role of the Business Architect is virtually missing in Agile. But even at small-scale the role is critical. 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. In FLEX the business architect has the critical role of determining if one MBI will affect existing capabilities.

Have a well-defined intake process and Planning Events

Having a well defined intake process is essential. Otherwise people will be interrupted by requests for work that was not evaluated compared to other work, but mostly on the whim of management. A well-defined intake process also requires a method for starting new work. This can be done via a pull mechanism as teams are available. This would be similar to Scrum but having the team of teams that is needed to get the work done pulling from the product backlog. Most often, however, it is more effective (at least at the beginning of the adoption) to have a planning event where work is pulled and planned as a group.

This is not unlike planning a sprint, but at a larger scale. And it has somewhat the same effect – it limits WIP at a high-level but can be improved by attending to lower levels as well. A way to manage WIP at the team level is to attend to dependencies and how teams collaborate. Focus on managing how many MBIs, Features and stories are active at the team level.

Planning events can be useful for this because they are really about collaboration and dependency management more than creating the plan itself. There are three common patterns we’ve seen. They are correlated more with how the talent is organized than the size of the organization.

Regularly scheduled Planning Events.  At the end or a program increment have a planning event with all the trains involved. At small to mid-scale, however, these may not be necessary. This is especially true when most of the work is contained within a team or within groups of two or three teams.

Planning Event to kick things off and then manage dependencies at the synchronization points. When teams are mostly independent this can work pretty well. Have an initial planning event to get all dependencies mapped and an agreement on how to collaboration. But moving forward, just manage dependencies with a flow model. This approach can work up to 30-50 teams even when some of the teams create platforms for the others.

No Planning Event. At small-scale Planning events may not be needed. Instead, it may be sufficient to use shared backlogs across two to ten teams as long as there are agreements on how they need to work together.

For more information, please read Aligning Multiple Teams with Lean-Agile Thinking.

 For more information, please read Running Effective Planning Events.

Implementation and integration

Teams must work together on a common cadence – starting and stopping at the same time. This enables teams to integrate, if not continuously, at least at the end of each iteration or cadence. DevOps must also be used to ensure smooth delivery.

Organizing the talent

There are many ways to organize your talent. Cross-functional teams are best, but often can’t or are too costly to be achieved. It is important to understand why cross-functional teams are so effective even if you can’t achieve them.

For more information, please read Cross-functional teams: Improving communication between people who work together.

DevOps

• DevOps is a special case of two different responsibilities working together. In some ways it is no different from the communications between business-Product Managers, Product Managers-Product Owners, and Product Owners to development teams.
• There are two challenges in the communications between development and operations. The first is that the intense focus of Agile on teams sometimes has developers think that when the code is built (including testing) it is done. While it is not the intent of the Agile Manifesto to do this, its seventh principle, “Working software is the primary measure of progress,” sometimes has teams forget that real value comes from when the customer realizes the value.
• One of the first and most effective steps in DevOps is for the development teams to merely make what they are doing and what they will need ops to do visible.

Release and realization

Delays waiting for software to be deployed and or realized are just as bad as delays anywhere else. It is important to not have missing pieces for realization to be discovered at the end. While DevOps attends to this, one of the uses of MBIs is that they include anything needed in order to actually realize value (e.g., marketing, support).

Other Factors

The role of leadership, management and systems thinking

Leadership and management play an important role at all scales.  While being a servant leader is important, it is also important to hold the big view of the organization. In essence the purpose of leadership is to create the direction the organization is moving in  The purpose of management is create an organization in which the development/IT organization can autonomously implement this vision.  This respects the ability of workers to self-direct and self-organize while creating an effective eco-system within which they can work.  This is called Middle-Up-Down Management.

 For more information, please see the page Leadership and Management.

Watch a recording of Al Shalloway’s Agile 2018 presentation Lean Leadership and Systems Thinking.

Improving your company’s culture

Organizational culture eats strategy for breakfast and dinner. Peter Drucker Agile and culture 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.

Collaboration and alignment

Having agreements on how people throughout the organization is critical. In all too man organizations these agreements are tantamount to “let’s follow SAFe” (or substitute your favorite framework). This takes our eyes off the real target (the quick realization of value predictably, sustainably and with high quality) while increasing the occurrence of dogma.

Consider Figure 9. Imagine you were a developer (or any other role). If each sub-component in the hierarchy is tied back to its parent it is possible for everyone to see what MBI each sub-component is tied to. This provides critical information when a conflict of capacity occurs. This also creates alignment.

We have found an effective way to get alignment is to make some basic agreements. We call these the guardrails.

The Guardrails

We agree to:

• Work on items that will realize the greatest amount of Business value across the enterprise.
• Collaborate with each other in order to maximize the realization of Business value across the enterprise.
• Ensure that all work will be made.
• Take the necessary steps to sustain or increase predictability.
• Keep the work throughout the value stream within capacity.
• Encourage everyone to strive for continuous improvement.

The first one around focusing on business value is critical. We have found that the best way to align is around the purpose of the organization and focusing directly on the goal of achieving business agility

When one thinks about it, that is virtually the only thing on which you can align. People can be at a company for any number of reasons. It may be a short-time gig for experience, they need the money, their significant other is there, who knows. But if they aren’t working in alignment with the purpose of the company they shouldn’t be there. It really is as simple as that.

Collaboration and Dependency Management

How teams at small-scale collaborate depends upon what the teams are responsible for. There are several situations at small-scale that require different solutions. No matter how it is done, remember that shorter planning cycles are better than longer ones. Most Agile adoptions at small-scale do not need three-month planning cycles, or even planning events. There are many ways to accomplish planning at small-scale, but the following are the most common. Other than the “flow or iteration” variation, each option is presented in what usually achieves more effective/efficient deliveries.

There are several ways to accomplish this. They are presented on Dependency Management, Collaboration and Planning at Small-scale which you should read before continuing.

Starting a Lean-Agile Adoption at small to mid-scale

Starting an adoption of Lean-Agile should almost always start as early in the value stream as possible. The reason for this is that actions taken upstream have a direct impact on downstream activities. For example, having business stakeholders request smaller batches of work be done will make it easier to build things quickly and stay out of chaos. Eli Goldratt (the creator of Theory of Constraints, the concepts of which are embedded in most Agile methods) once remarked- “Often reducing batch size is all it takes to bring a system back into control. DevOps is another example – developers working with ops helps operations.

While no two approaches are exactly they same, most follow this general outline:

1. Leadership and management take a short workshop to learn the basics of Lean Software Development at small-scale.
2. Product Owners learn Agile Product Management.
3. Release Train Engineers (RTEs) get up to speed.
4. Teams learn a blend of Scrum and Kanban with ATDD embedded in it (with advanced training techniques this can be done for less than the cost of certification in Scrum or Kanban alone)

All of this can be accomplished with four days of small workshops for leadership, management, Product Owners, RTEs and Scrum Masters and Scrum/Kanban with Agile Requirements: Achieving Sustainable Agility. The later course should be attended by product owners, RTEs, Scrum Masters and the development team (including testers) and can accommodate up to 75 people. Learning together is the best way to start working together.

Acceptance Test-Driven Development should be taught up-front

Two of the ubiquitous challenges facing software development organizations (product or IT) are:

• unclear requirements
• keeping developers and testers working together

Acceptance Test-Driven Development (ATDD) is specifically designed to solve both of these challenges.  ATDD is the process of product owners, developers and testers discussing requirements together prior to writing any code. There are three phases to this: discovery, specification and automation. Learning the first two phases of ATDD only takes 2-3 days. It helps clarify requirements as well as improving the design of the code.

 For more information, please read Benefits of Acceptance Test-Driven Development using Behavior-Driven Development.

Conclusion

Absorb what is useful, reject what is useless, add what is specifically your own. – Bruce Lee

Building off of proven patterns of success and challenge enable your organization to use existing methods that are tailored to your needs. By using a “framework” that provides guidance on how to make decisions you can move more quickly than trying to follow a framework that was designed for everyone.