The Simple Lean-Agile Mindset (SLAM)

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:

• System level optimization: A collection of eight methods for improving the way people work alone and together in an organization to achieve any given objective and to engage in continuous improvement.
• Strategic vision and execution: The organization’s unifying vision, along with the three-step process for executing that vision: 1) Break it down, 2) Prioritize, and 3) Pull work into the teams.
• Empirical process control: The system for ensuring continuous improvement: 1) Deliver in small batches and 2) Gather and respond to feedback.
• Business agility: The extension of agility throughout an organization. While enterprise agility focuses on product delivery, business agility makes every part of the organization more lean and agile, including human resources, accounting, marketing, sales, purchasing, and production. Small teams, autonomous but aligned, work toward delivering the highest value to the customer and to the organization.

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:

• The Scaled Agile Framework (SAFe) uses a concept called value streams — the steps between “concept and cash.” You want to optimize the stream to deliver working product increments (PI) in the shortest possible time.
• LeSS puts a lot of emphasis on queue theory to reduce the cycle time by putting the smallest batches of work through the system (for more about Large-Scale Scrum check out this course on Growing Scrum).
• Kanban breaks work into smaller work items and encourages teams to complete work items in small batches and reduce work in progress (WIP) to optimize workflow.

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:

• With Kanban, teams use a Kanban board that anyone in the organization can look at to determine product development status, find out what the teams are working on, and even gain insight into workflow issues.
• LeSS calls for numerous meetings, including sprint planning 1 and 2, product backlog refinement, daily team scrums (15 minutes max), sprint reviews, retrospectives, and overall retrospectives. (A sprint is a two-to-four-week product development cycle that ends with a working version of the product - a product increment.)
• SAFe has engineers that act as servant leaders for each of their areas of responsibility, including a solution train engineer (STE), who communicates the solution to several teams, and a release train engineer (RTE) who focuses on the release.

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:

• SAFe provides strategies for lean budgets. You create a budget for a value stream and then assign that value stream to an agile release train (ART). A lean budget ensures that each ART works only on what delivers value to the customer.
• Disciplined Agile Development (DAD) recommends rolling wave budgeting. Instead of funding projects, you allocate funds in waves of product development.

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:

• SAFe lists transparency as one of its four core values. Prior to each sprint, teams set and communicate their sprint goal, and at the end of each sprint, they evaluate whether they achieved their goals.
• LeSS has transparency as one of its ten principles.
• DAD has as its fourth principle for effective agile delivery governance, “Transparency into teams provides better insight than status reports.”
• The Spotify Engineering Culture uses retrospectives, captured learning, and improvement boards to identify and address issues in the product and the process for creating it.
• Kanban has “visualize the workflow” as the very first of its core practices. A Kanban board provides real-time insight into work in progress (WIP).

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:

• SAFe has program increments (PIs).
• LeSS has sprints.
• Kanban has WIP limits.

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:

• SAFe uses Agile Release Trains (ARTs) - long-lived cross-functional teams that focus on delivering the value stream.
• LeSS uses feature teams - cross-functional teams that have all the expertise required to deliver a given feature. Instead of one person working on a slice of the product (such as database, coding, or user interface), the whole team focuses on a feature that combines all these different slices.
• The Spotify Engineering Culture uses squads that can work together in tribes to develop specific feature sets.

Respecting people

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

• Listening and giving due consideration to everyone’s opinion. While some people may have a higher level of expertise in some areas, innovative ideas often spring from conversations among people with expertise in different areas.
• Letting people do their jobs instead of micromanaging. All enterprise agile frameworks are built on the foundation of autonomous but aligned teams. Management may provide direction on what to do, but teams decide how to do it.
• Encouraging people to achieve their full potential through cross training and continuing education.
• Rewarding people for innovation and for revealing and correcting weaknesses in the organization. Encouraging experimentation without the threat of punishment for failures.

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:

• Take a collaborative, problem-solving approach to dealing with performance issues. For example, instead of threatening or punishing a team for missing a deadline or milestone, work with the team to figure out ways to improve the process.
• Encourage and reward employees for speaking out and being honest about weaknesses in the organization.
• Encourage and reward employees for taking the initiative and experimenting, even when it leads to failure. Employees shouldn’t think that job security is simply a matter of not screwing up.
• Strive to improve employee retention. In organizations with high turnover due to firings and layoffs, employees often have a constant fear of losing their jobs, which discourages innovation and initiative.
• Discourage the common urge to blame others when something goes wrong.
• Nurture a creative workplace, where employees are having too much fun creating awesome products to be afraid of anything. 

The top enterprise agile frameworks approach fear in different ways:

• The eighth principle of SAFe encourages organizations to “unlock the intrinsic motivation of knowledge workers.”
• LeSS focuses on using engineering practices such as continuous integration to encourage developers to take risks. Lean leaders are responsible for giving employees autonomy and encouraging them to work without fear.
• The developers of DAD emphasize the importance of creating a culture of psychological safety in which employees can function without fear.
• The Spotify Engineering Culture values trust over control and recommends “limiting the blast area,” so teams can fail more safely.

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:

• The organization’s needs
• The customers’ needs
• Enterprise agile product development

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:

• SAFe recommends that executives create high-level strategic themes based on the organization’s budget and goals and on customers’ needs. These themes help the Lean Portfolio management group decide which of the initiatives (or value streams) gets funding from the organization. SAFe puts a lot of emphasis on organizational alignment.
• LeSS has a head of the product group, who creates a prioritized list of work items that a product owner distributes to different teams. The head of the product group may create the strategy for the entire organization and dozens of individual teams.
• DAD encourages teams to develop a common vision, where executives, managers, and stakeholders collaborate with the teams on high-priority goals.
• Spotify’s approach distributes the vision among different product owners. They can work together to find common goals, but it’s up to them to do what works for their teams (or squads).

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:

• SAFe breaks down strategic themes down into epics, which can be broken down further into user stories and delivered over multiple product increments (PIs).
• LeSS does something called an initial product backlog refinement (PBR), during which the product owner works closely with the team to refine the backlog into something that can be delivered. Together, they create a shared idea of what the customer wants and how the team can implement the vision
• Kanban breaks larger work down into work items recorded on Kanban cards. Work items may be written as user stories.

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:

• SAFe has several different levels of prioritization. At the top (portfolio) level, managers and executives prioritize their epics on a portfolio Kanban board. Then middle managers prioritize the work in program and solution backlogs. Finally, individual teams have their own product backlogs. Each of these steps is a way to zero in on the highest priority solution.
• LeSS relies on frequent product backlog refinement (PBR) meetings. The initial product backlog refinement breaks down the work. Then subsequent product backlog refinements prioritize the work based on customer feedback.
• DAD includes prioritizing the work as an agile best practice - a part of each of its different delivery lifecycles. Agile teams deliver the highest value product as a way to increase the customer’s return on investment (ROI). Customers get more of what they want early.

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:

• Shortens cycle times. Teams develop a better sense of the workflow and have an easier time spotting issues that are slowing workflow. Think of it in terms of rowing a boat; a team that’s too busy rowing may not notice or have the time to fix the leaks in the boat that are slowing it down.
• Encourages timeboxing. Teams develop a better sense of how much work they can complete within a given timebox, so they can deliver at a predictable pace. If a team’s pace is being set by another team pushing work onto the team, it may never have a clear idea of its own capacity for work.
• Supports respect for people. You’re not asking teams to work overtime or deal with undue stress. In fact, too much work often slows people down as opposed to motivating them to finish quickly.

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

• SAFe recommends using Kanban boards at every level of the organization. You pull portfolio epics based on the budget. Then you pull different parts of the product across a Kanban board and into an Agile Release Train (ART). Finally, each agile team has its own Kanban board to manage its capacity to complete the work.

• LeSS focuses on pulling work through the teams by applying queue theory. Queue theory suggests that you can increase the flow of work through the system if you break things down into smaller batches.
• Kanban is the most straightforward. You create a simple swim lane diagram on the wall or on a board that shows the team’s capacity. Then, you pull work across the board as you complete it.

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:

• A key part of SAFe’s leadership training centers on encouraging teams to innovate, experiment, and even fail. Teams need to experiment as a way to innovate and continuously improve.
• LeSS is one of the most enthusiastic about running experiments. In fact, the LeSS books are packed with hundreds of different experiments you can try to improve enterprise agility.
• DA focuses on lifecycles, including a disciplined agile continuous delivery (or “Lean”) lifecycle that you can use for tasks, an agile lifecycle for adding features to products, and an exploratory Lean Startup lifecycle for testing ideas. All of these lifecycles encourage a more experimental mindset.
• While other enterprise agile frameworks, including SAFe and LeSS, have set roles, meetings, and practices, Kanban lets you tinker with the whole process. You can add roles, eliminate formal meetings, split teams, and make other changes to optimize workflow.

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:

• Ideas: Data-driven organizations may be interested primarily in mining new ideas by collecting and analyzing large volumes of data. For example, a pharmaceutical company may examine molecular and clinical data and leverage the power of predictive modeling to identify molecules that have a high probability of being developed into drugs that act on certain biological targets. For more on this topic check out Learning Data Science: Using Agile Methodology or Data Science: Create Teams That Ask the Right Questions and Deliver Real Value.
• Features: For teams focused on product development, most of the work being pulled into the system is in the form of features, epics, or user stories. Teams select the highest priority features and work toward integrating them into an enterprise-level product.
• Tasks: If you’re primarily focused on operations, such as a helpdesk or DevOps, work orders are in the form of tasks. Many helpdesks, for example, use something like a Kanban board to track workflow. They may have color-coded tickets, such as red, orange, and yellow to prioritize items. DevOps may use a similar approach to manage infrastructure - creating a prioritized list of tasks that must be completed to perform a major operation, such as installing a new server or creating a testing environment.

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

• SAFe starts with strategic themes at the enterprise level that are broken down into solutions by solution train engineers (STEs) and then broken down further into release trains by release train engineers (RTEs), which are then passed along to various agile teams.
• LeSS has one product owner who maintains an evolving product backlog from which the agile teams pull their work.
• DAD has a three-phase delivery lifecycle, during which the teams plan their work (inception), do the work (construction), and release their work to the rest of the organization (transition).
• The Spotify Engineering Culture follows a “think it, build it, ship it, tweak it” approach that leaves it up to the teams to pull work and complete it.
• Kanban relies on a Kanban board, which serves as a to-do list for teams. Many enterprise agile frameworks use Kanban boards to create a prioritized list of work items that teams use to manage their workflow and communicate work status to the rest of the organization.

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:

• In SAFe cross-functional teams on Agile Release Trains (ARTs), deliver in program increments (PIs) that can be further divided into product iterations. At the end of each increment or iteration, teams can gather customer feedback. After each program increment is a system demo, and after each iteration is an iteration review.
• LeSS conducts a multi-team sprint review after each sprint, during which the team collaborates with the customer to identify areas for improvement. Each sprint is timeboxed (typically two to four weeks), to ensure small batch delivery and frequent feedback.

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:

• People must be agile
• Optimize your value streams
• Don’t focus solely on practices
• Sense, respond, learn, and adapt

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

• LeSS has the head of the product group create the strategic vision. The product owner helps to break down that strategic vision into something that can be developed by the teams.
• SAFe has strategic themes created at the very top of the organization by directors and executives.
• DAD has a group of stakeholders that helps to establish strategy and good governance.

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.