Stefan Wolpers recently reposted his survey “Would you recommend SAFe®?” on LinkedIn and it prompted some excellent discussion. One comment I liked by Maxwell Lamers summarized a common view of SAFe® succinctly as “The framework itself is built on solid ideas, and there is nothing inherently evil about the framework. The trouble comes in the implementation.” Maxwell described problems when SAFe® is not fully implemented, but I think taking on too much process and training is a problem in its own right.
Process Has Weight, but Knowledge Is Weightless
Ceremonies and processes have weight and take time to undertake. This is okay if the process adds sufficient value to warrant the expenditure. However, often they do not add enough value, or the processes continue to be used beyond the point where they are still valuable and become a net drain on a team’s efficiency.
Knowledge, on the other hand, is weightless. There is no penalty for collecting knowledge. Understanding a wide variety of topics and techniques allows us to use only the most efficient and appropriate for our current circumstances.
We can visualize process as the baggage and tools we carry on our project journey. Like going on a hike, some small undertakings may require no additional support. We can just turn up and do them. As projects get longer and more complicated, just like a longer hike, we might be glad of a raincoat and some food and water for the trip.
Complex and hazardous endeavors may require sophisticated tools (and knowing how to use them). The goal is to take just what we need, understanding that the more we elect to bring, the better prepared we are, but the slower we will go. The more energy you use carrying a heavy backpack of tools, the less energy you have available to move toward the project goals. So, we need to balance responsible process with goal focus and progress.
Problems with Agile Frameworks
The agile community is abuzz with discussions of and promotions for scaling frameworks that claim to help organizations apply agile approaches to large, complex scenarios. These frameworks include SAFe, LeSS, and Nexus and offer reasonable solutions for common scaling problems. They are generally well researched and supported by a wealth of training courses, credentials, and certified consultants. However, they come with some fundamental problems as well.
- Agile Myopia - Agile scaling frameworks suggest agile approaches as the only solution. When you have only a hammer in your toolbox, all problems look like nails. However, sometimes the best way to deal with that traditional stakeholder who wants a WBS is to give them a WBS. Likewise, maybe some aspect of your project is defined and repeatable, so why not use a traditional plan-driven approach for it? It is both arrogant and ignorant to believe agile is always the best solution.
- Software Focused – The agile approaches, scaling frameworks, and tool kits grew out of the software development space. Unfortunately, they have not shed their software-focused roots and still contain concepts based on software architecture. That might be okay for consultants who can filter out these elements and convert the ideas to other industries, but it is an impediment to sharing ideas and getting a broad spectrum of stakeholders on board.
- Buffet Syndrome - When faced with a buffet of tasty-looking food, there is a tendency to take more than we need. With so much information available in these tool kits, most organizations and teams try to adopt too much process leaving too little energy for the actual project goals. It is fine to understand the theory (knowledge is weightless), but when you start using these rich frameworks, the process weight overwhelms most organizations.
Often, speed of delivery and the ability to quickly react to changes (key agile benefits) are lost by organizations now using overly heavy frameworks. As focus shifts to training, learning new terminology, and roles like Release Train Engineer, less effort is directed to project goals, with predictable results.
Agile approaches are not always the best tools for the job. Like any good tool, agile tools are great for their intended purpose but are no panacea or silver bullet. Also, the size and depth of scaling frameworks create distractions of focus and dilute team effort from project goals. So, avoid framework consultants, training, and certification programs; we cannot afford distractions from the fundamental goal of completing a project.
Beyond Agile Avoids Agile Myopia and Buffet Syndrome
Unlike the large scaling frameworks, such as SAFe®, Beyond Agile avoids Agile Myopia and Buffet Syndrome by being simultaneously broader and more selective in its recommendations.
Beyond Agile recognizes that processes carry implementation weight, yet knowledge is weightless. So, it recommends learning much and implementing little—just the most relevant to retain maximum team effort toward the project goal.
The dynamic model changes based on project and organizational characteristics, recommending the highest-value-added approaches for the situation at hand. Some key concepts:
- There is no single, simple model for complex projects.
- Process carries weight, but knowledge is weightless.
- Guidance needs to be dynamic based on project and organizational characteristics.
Chasing “Done” Drift
For most modern projects, the destination is a moving target, and it is usually moving away from us. The longer we take to deliver a project, the more likely the endpoint will move further away to keep up with new competitor products, industry expectations, sponsor requests, etc. I call this phenomenon “Done” Drift because what constitutes “Done” will likely evolve during a project or product life cycle. So, we want to get to the destination as fast as possible without diverting energy on nonessential work.
We need to analyze all activities and processes that do not contribute directly toward the project goal. In the figure below, 100 squares represent 100 percent of the team’s effort toward the team goal. If 5 percent of their time and energy is spent on non-value-adding process, such as excessive agile ceremony focus, they can only direct 95 percent net toward the project goal.
The more process we add, whether it is necessary corporate process or cool new team activities, the more delivery capacity we remove from the net vector of progress toward the end goal (that is always moving away from us). The final image above shows an additional 10 percent of corporate process, and the net vector of progress is reduced further.
These images illustrate the double whammy dilemma. First, the end goal is always moving away from us—the longer we take to get there, the more we will have to do to declare success. Second, every call on the team’s time takes away from their ability to make progress toward the goal.
The numbers in these examples are conservative. Think about how long you spend on your projects in value-adding activities versus non-value-adding company process, meetings, or producing three sets of time reporting, etc. All the time and focus not directed toward the end goal are distractions. Plus, when you give people enough distractions, they lose energy and start making mistakes because of the interruptions of constantly switching tasks.
Laser Focus
A 40-watt light bulb will barely light a room, while a 40-watt laser can cut through aluminum, leather, and wood. It is the same light energy, just focused instead of diffused.
So, while it is great to be aware of many different approaches, we must always be alert to the costs. Every interruption and call on your team’s time that is not directed at the project’s end goal is reducing their capacity.
While it is extremely valuable to look beyond agile for guidance, we need to maintain a strict filter on what and how much we use from any approach. So, expand your toolbox, hone your skills, become domain and tool agnostic, and then direct maximum effort toward the project goal.
This expands the familiar DevOps model:
With a further dimension or loop as shown below:
The challenge (and skill of being a good leader) comes in using the minimum amount of the most appropriate approach for the situation to get the job done.
The Stage and the Spotlight
So far, we have explored two core ideas of the Beyond Agile Model (BAM). The first is that the project characteristics define the size and scope of the recommended approaches, training, and artifacts to consider for that project type. This is akin to setting or defining the stage we are working on.
The second idea is to be careful and deliberate about what to focus our attention and our team’s attention on since we can easily lose focus on the project end goals. To extend our stage metaphor, this is the spotlight that suggests what we should focus on.
These two ideas are used together in the model to define the recommendations scope—the dotted red line representing the stage encompassing everything in scope for us to call upon. Then the goal focus would be a spotlight shining on that stage, illuminating what we are to focus on.
The aperture of the Beyond Agile recommended-approaches scope is elastic: it is always trying to shrink, returning to a state where less is included. Project and organizational factors stretch it larger but also create tension. As soon as the approaches no longer justify their expenditure, they should be eliminated or pared back.
The spotlight is controlled by our economic view of decision-making. This means we ask, “Where is the next best dollar spent for the project?” Should we be building features, responding to issues, or answering a stakeholder request?
As project lead, we continually evaluate priorities and readjust the focus to optimize value delivery and stakeholder satisfaction. It is no use ignoring stakeholders to focus on building features or diverting the whole team to explore every new question or request. Instead, we dynamically readjust the team focus of effort to bring the most valuable outcomes.
Expansive scaling frameworks may look appealing since they appear to hold all the guidance we need. Yet this masks two silent killers of performance Agile Myopia (the tool you might best benefit from using next lies outside of the agile toolkit) and Buffet Syndrome (trying to use so much stuff and train so many people in it all will kill off any ability to deliver meaningful value.)
The solution is simple to describe but requires discipline to implement.
- Start with agile but also look beyond it for your tools.
- Ruthlessly refactor and keep removing process to focus team effort on the goal
Essentialism
It’s the same core idea as described in the book Essentialism, just applied to teams and value delivery. The book summary site Reading Graphics has an excellent visual summary.
(Image Credit: Reading Graphics)
The Beyond Agile Model recognizes Agile Myopia and Buffet-Syndrome as real threats to performance and provides an alternative.
It is not a one size fits all solution. It cannot be boiled down and printed on a pamphlet for memorization or easy access. Instead, it is more like a map you consult on your team journey multiple times to make local decisions towards your goal.
See more in the Beyond Agile book.