SLAM System-Level Optimizations
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:
- Shortening the cycle time
- Clearing communication channels
- Budgeting for the value stream
- Encouraging transparency
- Working in cross-functional teams
- Respecting people
- Removing the 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. For example, SAFe® uses a concept called value streams — the steps between “concept and cash.” You want to optimize the stream to deliver working product increments in the shortest possible time. LeSS emphasizes queuing theory to reduce the cycle time by putting the smallest batches of work through the system. And Kanban breaks work into smaller work items and encourages teams to complete work items in small batches and reduce work in progress to optimize workflow.
Clearing communication channels
One key area all frameworks touch upon 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 communication.
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 meetings, product backlog refinement, daily team scrums, sprint reviews, retrospectives, and overall retrospectives. SAFe has engineers that act as servant leaders for each of their areas of responsibility, including a solution train engineer, who communicates the solution to several teams, and a release train engineer who focuses on the release.
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 agility, customers collaborate with the organization instead, so budgets need to be more flexible. Instead of budgeting for projects, an organization budgets for value streams, and the teams integrate functionality into the product incrementally based on the customer’s priorities.
Most enterprise agile frameworks create a budget around customer value. For example, SAFe provides strategies for lean budgets. Budgets are created for a value stream and then that value stream is assigned to an agile release train. Disciplined Agile Development (DAD) recommends rolling-wave budgeting. Instead of funding projects, funds are allocated in waves of product development.
A key part of continuous improvement is making sure team members are transparent about what’s working and what’s not. SAFe lists transparency as one of its four core values. LeSS includes 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. And Kanban has “visualize the workflow” as the very first of its core practices.
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.
Working in cross-functional teams
Many organizations are structured according to functional areas, such as marketing, 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 work.
To eliminate handoffs, agile organizations use cross-functional teams. 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 includes a version of the cross-functional team, such as the agile release trains in SAFe, feature teams in LeSS, and squads in the Spotify Engineering Culture.
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.
- Letting people do their jobs instead of micromanaging.
- Encouraging people to achieve their full potential through cross-training and continuing education.
- Encouraging experimentation without the threat of punishment for failures.
Removing the fear of failure
To drive innovation and continuous improvement, organizations must promote a fearless culture. 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.