Dark logo

After graduating college, one of my first jobs was with Northwestern University’s Academic Computer Lab. Early each morning, on my way to work, I’d pass by a house with a small wood fence. Behind the fence was a dog that would scratch, claw, and bark at me. It was our daily routine - something the dog and I shared. Some days, I’d even see its glossy brown head pop up above the top of the fence.

One morning, the dog was unusually motivated, so much so that the gray fence planks rumbled like a concert speaker with the dog struggling to get over. This time it actually managed to get one of its front legs over the fence, and then it flipped over to the other side. We looked at each other with mutual shock and neither of us really knew what was next?

I think about this experience when I see organizations trying to improve their enterprise agility. Many organizations scratch and claw at the fence in an attempt to get to the other side. They adopt agile practices, such as small teams, standup meetings, and planning poker. They think that if they can claw their way through these key practices, then they’re sure to become a more agile enterprise. However, achieving enterprise agility takes more than adopting agile practices. Organizations must make the leap; they need to adopt an agile mindset.

According to a Gartner study most organizations are using one of the top enterprise agile frameworks to help them with their agile transformation. These top frameworks include the Scaled Agile Framework or SAFe®, Large-Scale Scrum or LeSS, Disciplined Agile or DA, Spotify’s approach and Kanban. While writing my book Enterprise Agility for Dummies I discovered that there was a lot of overlap between these top frameworks. They have different names for many of the practices and some of the emphasis is different, but there is a common theme that they all share.

Not everyone has time to compare the top frameworks and so I immediately started looking for ways to simplify these common themes. I wanted to create a simple set of concepts that they all share. So I present to you the Simple Lean-Agile Mindset (SLAM). My hope is that can help your organization adopt the shared understanding of enterprise agility that will help you get over the fence.

Introducing the Simple Lean-Agile Mindset (SLAM)

The Simple Lean-Agile Mindset is a conceptual construct for understanding how agile enterprises function. Think of SLAM as a simple overview of what it means to have an enterprise agile mindset. SLAM is a high level view of what the different enterprise agile frameworks and practices are trying to accomplish.

SLAM breaks down agility into four areas:

Starting at the Bottom with System Level Optimization

System level optimization involves improving the way people work alone and together to execute the organization’s strategic vision. Every enterprise agile framework includes methods for achieving system level optimization in the following eight ways:

  1. Shortening the cycle time
  2. Clearing communication channels
  3. Budgeting for the value stream
  4. Encouraging transparency
  5. Timeboxing
  6. Working in cross-functional teams
  7. Respecting people
  8. Removing fear of failure

Shortening the cycle time

All enterprise agile frameworks put a lot of emphasis on shortening product development cycles to optimize workflow, improve transparency, and ensure continuous incremental improvement. However, each framework uses a different approach. Here are a few examples:

Clearing communication channels

One key area that all the frameworks touch on is open and honest communication among everyone involved in product development, including team members, customers, management, and the organization’s leaders. All frameworks have different ways to encourage and facilitate communications:

In addition, all enterprise agile frameworks involve small teams that work closely together, often within chair turning distance of one another to promote close communication and collaboration among team members. All frameworks also encourage and facilitate communication between customers and the product development team to ensure that the people delivering the solution have an intimate understanding of the customers’ needs.

Budgeting for value streams

The third value of the Agile Manifesto is “Customer collaboration over contract negotiation.” In the past, customers would contract with an organization to provide a product with a detailed list of features. With enterprise agile, customers collaborate with the organization, instead, so budgets need to be more flexible. Instead of budgeting for projects, you budget for value streams, and your teams integrate functionality into the product incrementally based on the customer’s priorities. The customer receives as much value as he’s willing to pay for, and he can decide at any point in time that the product is good enough.

Most enterprise agile frameworks create a budget around customer value; for example:

Encouraging transparency

A key part of continuous improvement is making sure that your teams are transparent about what’s working and what’s not. Transparency can be a real challenge in many organizations. Strong control cultures favor certainty and focus on accountability (for more information check out this course on Changing your Organization's Culture). These organizations want their managers and leaders to minimize risk and make accurate predictions.

The top enterprise agile frameworks emphasize the importance of transparency in driving continuous improvement:

All these frameworks have different roles and practices in place to encourage and facilitate transparency. Most involve some form of iterative product delivery (small and frequent releases) that provide teams, customers, management, and other stakeholders with greater visibility into the product development process and make it easier to spot problems.

Timeboxing

Timeboxing involves allocating a fixed amount of time to any given activity. All enterprise agile frameworks and certain agile practices rely on timeboxing to ensure predictability and eliminate waste. For example, stand-up meetings are limited to 15 minutes, and sprints are often limited to two to four weeks. You can’t break the box to get more to fit, such as by letting a meeting run over or extending a deadline.

All the top enterprise agile frameworks have some form of timeboxing:

Even though these names are different, they all limit the amount of time or work allocated. Teams deliver whatever they can within that constraint.

Working in cross-functional teams

Many organizations are structured according to functional areas, such as marketing, engineering, operations, software development, quality assurance, and business analysis. Each area focuses on its own slice of the project. The business analysts work closely with the customer and then communicate what they learn to software developers. Then software developers create the product and hand off their work to a quality assurance team. Each handoff adds a wait time to the project and requires functional areas to coordinate their work.

To eliminate handoffs, agile organizations use cross-functional teams. (Cross-functional means the team has all the expertise required to deliver the product. To see more, check out this course on Working on a Cross-Functional Team) But cross-functional teams are not just about bringing people together from different functional areas. Instead, team members work collaboratively on the product and often develop skills that cross the traditional functional boundaries; for example, a software developer may do some work related to business analysis or testing.

Each enterprise agile framework has a version of the cross-functional team; for example:

Respecting people

A core principle of the lean-agile mindset is respect for people. In practice, respect for people involves the following:

Removing fear of failure

To drive innovation and continuous improvement, organizations must promote a fearless culture. Here are a few ways you can reduce the element of fear in your organization:

The top enterprise agile frameworks approach fear in different ways:

Starting with a Strategic Vision

Because enterprise agile involves scaling up agile team practices to work on enterprise-level products, it requires strategic vision - top-down guidance regarding what the organization will be and will do in the foreseeable future. As you can see in the SLAM graphic, strategic vision comes from the organization’s business leaders, who have a high-level understanding of the following three factors that contribute to an organization’s strategic vision:

An organization’s strategic vision specifies the organization’s unifying goal and its overall strategy for achieving that goal. For example, you could say that Spotify’s strategic vision is to help people listen to whatever music they want, whenever they want, and wherever they want by creating an online music platform that allows them to easily listen to and share music that’s free, accessible, and legal.

The organization then turns that strategic vision into tactical work through a three-step process:

  1. Break it down. The teams work with the customer, management and the teams to break down the work required.
  2. Prioritize. Work is prioritized to deliver the most essential and highest value items first.
  3. Pull the work into teams. Teams can then pull work from the system to complete it.

Each enterprise agile framework has its own approach to setting and executing the strategic vision; for example:

Breaking it down

After your organization’s leaders establish a strategic vision, the rest of the organization breaks it down into something that can be delivered. For example, suppose an organization’s strategic vision is to create a version of its product that runs on smartphones. This vision doesn’t specify any of the particulars for implementation. Does it mean all smartphones or only Android and iOS smartphones? Should it be an app or just a mobile version of the website? These are questions that the executives may not know the answers to and that the teams should answer in collaboration with customers and other stakeholders.

To implement the strategic vision, the organization must transform it into something more tactical. This transformation is a higher level version of Scrum’s divide between the “what” and the “how.” The strategic vision is the “what.” Breaking it down provides the “how,” which is up to the product development teams to decide. The teams work closely with the customer to figure out what the customer would find most useful - a mobile app, a web-based version of the product, or something else entirely.

Each enterprise agile framework has its own approach to breaking down the work:

Prioritizing the work

Prioritizing the work is a key aspect of enterprise agility because it ensures that the most essential and high-value work is completed first, providing the organization and its customers with the most value as early as possible. Teams strive to “stop starting and start finishing,” so they can produce potentially shippable product increments.

Each of the top enterprise agile frameworks has its own approach to prioritizing the work:

Pulling work into the teams

Unlike traditional product development, in which management pushes work onto teams, lean-agility has teams pulling the highest priority work items from a product backlog or similar list to complete the work at a pace within their capacity for completing the work.

The pull method also supports several system-level optimizations:

Each of the top enterprise agile frameworks has its own way of pulling work through the system; for example:

Taking an Empirical Approach to Products, Operations, and Innovation

Heavily influenced by Scrum, enterprise agile encourages an empirical approach to products, operations, and innovation — experiment, learn, and adapt. This approach is in response to the traditional method of speculating or assuming what will work best and investing considerable time planning a solution only to discover (upon delivery or implementation) that the solution doesn’t work or the product doesn’t deliver what the customer wants or needs. With an empirical approach, a team has an idea, tries it out, and gathers feedback before investing a lot of time and effort. The empirical approach is consistent with Agile Manifesto’s fourth value: “Responding to change over following a plan.”

Enterprise agile frameworks break the empirical process into two stages:

  1. Pulling in ideas, features, and tasks.
  2. Delivering small batches to gather and analyze frequent feedback.

All the top enterprise agile frameworks support the empirical process:

Pulling in ideas, features, and tasks

Notice in SLAM diagram that “Pulling work into the teams” is broken down into three types of work - ideas (innovation), features (product), and tasks (operations). The type of work dictates how it’s pulled into the system:

All of the enterprise agile frameworks have ways to pull features into the teams:

Getting real-time feedback by delivering in small batches

The success of empirical process control hinges on delivering work in small batches, collecting and analyzing feedback frequently, and making adjustments. With small batches, teams learn from their successes and failures and can apply that learning to improve the product and the process for creating it.

All the top enterprise agile frameworks have practices that drive small batch delivery and tight feedback loops. Here are a couple examples:

Think of the small batch delivery and feedback loops as the engine of your empirical process. This engine enables your teams to frequently experiment with the product and the process and zero in on the best solutions, resulting in both a better product and a better process. It also encourages a culture of continuous improvement, which is a key factor to improving your overall enterprise agility.

Moving Toward Better Business Agility

While enterprise agility focuses on product delivery, business agility applies to the entire organization. SLAM focuses products, innovations and operations, but over time, your organization may want to expand the scope of its agility - to change every area in your organization. As shown in the SLAM diagram, empirical process control can be applied to innovations and operations, just as enterprise agility applies it to product.

Disciplined Agile (DA) offers explicit options for scaling the framework to business agility. Specifically, DA offers the Disciplined Agile Enterprise (DAE) “process blade,” which operates according to the following four principles:

However, the other enterprise agile frameworks, including disciplined agile delivery (DAD), have enterprise-level decision-makers playing a key role in product delivery:

As each of these high level groups of people works to align products with the organization’s strategic vision, it contributes to the organization’s business agility. To extend their efforts to business agility, the organization must extend agile beyond products, innovations and operations.

I hope that SLAM can help you with your enterprise agile transformation. Please feel free to share or add your comments below. I will do my best to add improvements or make changes based on any feedback. Thank you.

9450 SW Gemini Drive #32865
Beaverton, Oregon, 97008-7105
Dark logo
© 2022 Doug Enterprises, LLC All Rights Reserved
linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram