Agile mindsets, tools, methods and frameworks do not scale – Core Capabilities do

Considering the amount of training, coaching, money, time and effort organizations spend on “becoming Agile” it continuously surprises us how little time is spent aligning people on what that means. Several years into an “Agile Transition” people within the same organization might refer to Agile using very different wording. Some will argue it is “a mindset of continuous adaption”, some will state it is about “Sprints, Scrum Masters and Product Owners”, others that it is defined by “High performance Teams” or “Release Trains” while others again will make a case for it being about “Story Points”, “User Stories” or the ability to measure “Velocity”.

It is not surprising that people can get into heated debates in terms of what “Good looks like” and what is “right or wrong” when your perception of Agile varies as much as the statements above suggest. While pointless debates about right or wrong (especially if both are wrong) are not the best use of our time much bigger problems hide beneath the surface:

• If you do not understand the underlying value drivers or first principles behind frameworks, tools, roles and practices it is very unlikely that you will be able to deal effectively with real world problems and the complex dynamics of the VUCA (volatility, uncertainty, complexity, and ambiguity) world most of us find ourselves in. You will most likely keep focusing on getting practices “right” but fail to identify or solve the root cause of your problems.
• If you do not agree on the underlying value drivers and first principles all solutions are equally valid: heavy upfront specification to eliminate uncertainty is as valid as handling uncertainty through fast feedback loops. Centralizing decisions mandates to ensure “first time right solutions” are as valid as running product discovery activities to cheaply validate both the problem and solution domain.
• If you align on the use of specific artifacts, roles, practices and events you are very likely to miss the bigger picture. You might find yourself running 2-week sprints but failing to gather continuous feedback from real customers and end users. You might find yourself using modern product discovery tools but ending in analysis paralysis to get everything “right” or having 25 proxy product owners for your feature factory teams
• Very few senior managers, CxO’s and staff functions invest the time and effort to understand the detailed mechanics of an Agile setup. Since neither specific tools, frameworks or practices nor a high-level mindset are closely connected to the business outcome of our Agile transition it is very difficult to have a constructive conversation with them about what is going on. As a result, even a small crisis or change of leadership position can drastically impact the whole setup. Also, if we e.g., need to talk to finance about changing the budgeting cycle or sales to closer align sales effort with new product development, it is very difficult to do that effectively if their understanding of “Agile” is centered on specific roles, events and artifacts.

But why don’t you just use the “Agile Manifesto” and the 12 principles behind - you might argue? Do they not embody exactly the gap between an undefinable mindset and context dependent practices? Though it is hard to underestimate the impact of the Agile Manifesto and the principles behind during the past 20+ years they have proven somewhat difficult to use as a “North Star” for organizational development. We believe it is due to at least a couple of factors:

• They sound foreign and misplaced when used outside the world of IT
• They are “old”. The technical advances made in the last 20+ years have opened possibilities that no one thought possible back in 2001. Many teams we have worked with would consider it downright slow if they were to follow the suggested iteration cycle length of “a couple of weeks”.
• They were written from the perspective of “fighting traditional approaches” but many organizations nowdays find themselves improving Business Agility rather than fighting Waterfall.
• They are a mix of very specific practices: “Business people and developers must work together daily throughout the project” and great intentions “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”
• They do not cater for modern product discovery principles but focus narrowly on working software as the primary way to buy information and validate risk early. But, in today’s world building quality products to scale can prove a very expensive exercise if uncertainty is high and you have not considered if there are cheaper ways to validate both problem and solution domain before “building stuff”
• There are many of them: 4 main statements + 12 principles and thus few people know them by heart.

So, while the Manifesto and the 12 principles behind deserve a huge degree of respect and have helped revolutionize how we approach new product and service development we have found that most organizations benefit from translating them into a clearer “North Star” fitting their local context. The naming differs a bit according to the local context. Some call them Guiding Principles, some “First Principles”, others “Key Value drivers”. Our default wording is “Core Capabilities” but choose whatever resonates best within your organization.

During the past 7 years we have helped several organizations through the exercise of defining their Core Capabilities. We typically start with a generic set which is then adapted to the local context. Experience shows that around 70-80 % is generic across organizations and most versions include elements of structure, governance, leadership, and process. Our current generic starting point is:

1. Strategic alignment – Enables a highly aligned but loosely coupled organization, local clarity of purpose and enabling guardrails for innovation.
2. Cross functional business development units– acknowledges Conway’s law and drives focused market, costumer and end-user innovation.
3. Stable-, empowered- and self-organizing teams – enable continuous improvement, fast iterations and pushes authority to information.
4. Small batches, outside-in – Early product discovery methods, MVPs and MVFs focus the organization on buying information as cheaply as possible and enables business Agility by keeping options open?
5. Early and continuous market, customer and end-user validation – feedback loops based on quantitative and qualitative data are the very core of Agile and part of both portfolio level processes as well as local innovation.
6. End-to-end pull system – enables flow, predictability and effectiveness at all levels by ensuring that the system is not loaded beyond proven capacity.
7. Operational and technical excellence – ensures DORA principles drive a mature technical setup and fast flow.
8. Modern leadership – is essential for all other principles to succeed by focusing on proactive and frequent sharing of intent and dialogue across organizational layers over clear mandates and narrowly defined “roles and responsibilities”.

Each headline is fleshed out in 3-5 observable bullets ensuring that we do not just subscribe to a list of high-level buzzwords carrying different meanings to different people. The observable bullets concerning Capability “End-to-end pull system”? e.g. reads:

• Work is pulled when free capacity is available not pushed based on schedules, milestones, or deadlines.
• Product deadlines are kept to an absolute minimum (but represent high-trust commitments), only used when a real economic consequence apply, and never to try to speed up work or gain unfair priority advances??
• WIP is recognized as a primary risk to flow and efficiency and lowering WIP is recognized as a key improvement driver across the entire development cycle (from initial analysis to operation)
• WIP is clearly visible at both team and portfolio level, and a sustainable pace maintained by allowing the people doing the work to decide when they have capacity to start new work.

Often people will not immediately agree to all aspects and the whole point is to surface disagreements early on. We also make a point of stressing that all capabilities come with tradeoffs and there is no such thing as a free lunch. We might e.g. observe the following tradeoffs regarding the “End-to-end pull system”:

Benefits

• Stop starting, start finishing – work is not done until value is realized or deemed unsuccessful.
• Sustainable pace – only the people doing the work can decide when capacity is available to start new work.
• Focus on the flow of value rather than capacity utilization increases effectiveness and productivity.
• Minimizing WIP is one of the most effective improvement drivers in complex workflows.
• The predictability of a pull system is much greater than a push system.
• Treating only real deadlines as deadlines vastly increases the chance of reaching them.
• 0 - 20% work items with deadlines ensures that the system can operate without seriously impacting flow and effectiveness.

Challenging aspects

• Conflicts arise when the system is not always open to start new work.
• Can be perceived as a rigid and inflexible system.
• It is not an intuitive principle – starting new work now rather than later feels better.
• Recognizing that most deadlines are not actual deadlines can be very difficult to accept.
• Schedule based push systems are still the default mode of operation and what people are taught in school and most project management literature.
• Focus on the flow of value rather than capacity utilization increases effectiveness and productivity.

Once settled the core capabilities serve as a North Star guiding decisions and improvement work in the organization like a compass. This helps us focus on the underlying value drivers rather than who is wrong or right in terms of specific implementation details. One team might, e.g., decide to invite specific users or key stakeholders on-demand to get their feedback, while another team might choose a more Scrum-like Sprint-Review session on a fixed bi-weekly cadence. One is not better than the other and teams are free to experiment with the solutions they consider the best way to gather feedback continuously and proactively align with their stakeholder landscape.

Beliefs or proven scientific facts?

Though the DevOps survey and other studies have shown a correlation between capabilities and organizational success it is important to accept that studies are inherently biased and much like Toyota’s “Limit WIP” principle Core Capabilities should also be considered “beliefs”. We want to turn the conversation from “is it a good idea to follow them” to “what might we do to get one step closer”. ?You might argue that we should constantly challenge and update them but imagine the delay and cost of constantly having to argue if this project or initiative should be done “Agile” or “Waterfall”, if this time we should rather move people to the work and not work to the people or if for this special crisis we need to centralize all decision authority. Not only will we waste a huge amount of time, but people will also quickly lose trust in the system, and we will create a highly fragile organizational setup where neither customers nor employees know what to expect and how to approach work.

Why are they not generic across organizations?

There are many reasons why organizations end up with their specific set of Core Capabilities and why some might choose to call them “Guiding Principles” or something else instead. Words are important and if an organization has previously had a massive failure trying to install Lean principles - using words like “Pull System” might immediately create resistance. You might also find that if you are building wind turbines or developing new enzymes the concept of feedback and MVPs look considerably different from a classical software context. But also, it is a simple matter of ownership. When adjusting content and specific phrases to fit the organizational context Core Capability ownership is transferred to the people and organization and conversation shifts from “what do other people consider to be true/right” to “what do we believe in and why”.

Are Core Capabilities similar to a Target Operating Model (TOM)?

No, they are related but not the same. When developing a TOM you would normally use the Core Capabilities to validate the specific details:

• Does our TOM support business development teams and not IT feature factories?
• Have we done enough to simplify coordination across teams and layers?
• Are decisions mandates close enough to the information?
• Does the suggested portfolio process compromise business development teams and their outcome-based roadmaps?

Another key difference is that while a Target Operating Model typically represents a “snapshot” of our shared decisions and will dynamically change, as new experiments prove successful or unsuccessful, the Core Capabilities it is built from should remain relatively stable over time. A TOM might represent a short-term target state while we can keep improving forever in the direction of our Core Capabilities.

Starter-kit vs. end-goal

While Core Capabilities are great to provide a clear direction and continuously improve how we want to structure organizations and collaborate internally and externally within that structure, they do not provide concrete guidance in terms of specific implementation details. That is great if you want to ensure future continuous improvement in a shared direction but not ideal if you are a team of beginners just starting on a totally different way of working. Throwing people in the deep water and hoping they will learn to swim before they drown is rarely a good strategy, but the key is to consider the needed starter-kits a temporary scaffolding and not a lasting framework.

Scrum might e.g. be a good temporary scaffolding as the Scrum guide provides us with guidance for specific roles, events and even artifacts that will help us get startet in the new way of working. We might even include even more specific elements like user stories, techniques for estimation or a default Jira setup in our starter-kit, but 2-6 month down the line those elements might start to prove disabling constraints and teams and individuals want to explore other approaches. As long as those new approaches are aligned with our Core Capabilities, we are fine because that is the level of long-term alignment we are looking for.

Conclusion: standards are great, but they need to be at the right level

?Many organizations obsess with alignment and standards. That is not a problem but historically it has just been at the wrong level. Standardizing a vague “mindset” is just too high-level to provide a shared direction and mode of collaboration (all solutions are equally valid) but on the other hand telling everybody to work according to SAFe, Scrum or an even narrower definition of “correct” leaves too little room for continuous improvement and adaptation to individual’s needs and the local contexts. Core Capabilities bridge that gap in much the same way as the “limit WIP” principle has done for the Toyota production system in the past 70 years. In that way we can use our future energy to explore optimal solutions for our teams and organizations rather than pointless discussions about what is right or wrong according to an outdated textbook or the latest popular framework.