The good, the bad, and the ugly about (Agile) Frameworks

The good

You don’t need to reinvent the wheel

Other organizations are successful with the framework, so should we. We can easily upload experiences and knowledge by learning and using a framework. That’s why most frameworks come with an education plan and material. So we can skip all the hassle with trial and error. Nice!

Change for free

The market and the environment are changing ever faster. So companies, their teams, and employees need to change faster to keep up with their services and products. Frameworks promise significant changes for organizations in a short time. Therefore, using a framework is a competitive advantage. Not using it, when competitors are successful with it, is a risk. It would be like running your own server-farm while your competitors are using cloud-computing.

New culture

Culture: the ideas, customs, and social behavior of a particular people or society.

The culture of an organization becomes visible through the behavior of its employees or, better, through their habits. Every organization grows its culture, and that is a good thing. Scaling and growing into a market need standards followed by the employees without thinking too much.

However, we often experience the need to change such organizational habits as soon as we want or need to change our products and services. Frameworks bring new behaviors into an organization so that employees learn a new culture.

Scrum, for example, has a clear description of behavior, and people are told: just follow the book. You will understand later. So the Agile Mindset (a.k.a. Agile culture) comes through the back door. Scrum even has a measurement to stop old behavior and helps to unlearn things: The ScrumMaster. Craig Larman summarized this in his Law: Culture follows structure.

Culture follows Structure — How frameworks influence the system dynamic

The bad

Promising simplicity where there is none

Culture eats strategy for breakfast

Have you ever looked at a graphic showing Scrum or any other framework and thought: That looks simple? Well, it is simple in terms of the rules, structure, and elements (not all frameworks, though). But every practitioner knows it can take years to adopt it, even with a particularly simple frameworks like Scrum or Kanban.

As mentioned before, a framework like Scrum is changing the culture. That means habits. And it needs a lot of repeating and fallbacks to change them. Just imagine trying to stop smoking. It is actually a straightforward thing. Just stop it. You even know that it harms your health, but you believe lung cancer only affects others. Cutting off old behavior and following new is pretty difficult. E.g., put a chewing gum in your mouth instead of lighting a new cigarette. Especially in a stressed situation, your subconscious will choose the cigarette. Now, imagine that for a team or even for a whole organization.

It doesn’t solve anything yet

Framework:
(1) a supporting structure around which something can be built
(2) A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality
(3) A system of rules, ideas, or beliefs that is used to plan or decide something
(4) The ideas, information, and principles that form the structure of an organization or plan

A framework is just a basic structure and not a keyhole ready house you can live in. The same is for organizational frameworks. Some cornerstones, beams etc. are fixed. But you have to fill large spaces in between to run your business. A software team using Scrum needs knowledge, practices, and methods to develop software. But Software is not even mentioned once in the Scrum description, even if Scrum became popular in software development.

That has its benefits as described at the beginning. Yet, it leaves organizations with a lot of uncertainty. Employees are asking for more details. They want to be “SAFe” to do it right. The problem, though is, that the uncertainty comes from the nature of your business, not from the framework or methods you use. Framework can disguise this fact.

You may end up with something you probably don’t want.

A framework follows the idea that you can repeat what has been observed at one or many organizations. We believe by applying the framework, we get a certain effect within our organization. But was the success of the observed organizations because of the framework, or because they had some brilliant employees with the right product idea at the right time? Correlation is a bitch. Furthermore, the believed effect why a framework is used often vary or is hidden. For example, I have observed a driving, but hidden belief to apply SAFe in many organizations: Increase to amount of better paid management positions and consulting contracts.

The ugly (or the beautiful) way to choose and use Frameworks

How to choose

1. Make first the goal clear, then choose the framework. For example, if you find out, that you are operating in a complex domain and you want to increase the effectiveness of your work system (not efficiency), Scum or LeSS is maybe the right choice. If you would like to increase the yield in your production, you should consider Lean or Kanban. Before you define your goal, you should first analyze the status quo of your product, services, and organization and then derive your strategic goal. The Cynefin framework or Wardley Mapping offering help here.
2. Trust the long track record of frameworks, but don’t rely on them entirely. I fear many testimonials are written to please the authors, the organization or the frameworks themselves. And since we are dealing with complex social systems, correlation does not equal proof.
3. A good property for frameworks should therefore be a built-in inspection and adaptation measurement. This ensures that the spaces are filled and exchanged with additional practices and methods over time. Or that the abandonment or dissolution of the framework is recognized at an early stage. This inspection and adaptation mechanism should always be toward the goal, why we are using the framework in the first place. For example, the LeSS framework includes the Overall Retrospective and the community of ScrumMaster for this purpose. If a framework lacks elements like this, it should definitely be added.
4. Find the right balance between fixed structure and freedom to experiment. Some frameworks just define some principles and leave huge space for the organization to fill them. Many experiments need to happen to fill the spaces. This puts very high demands on the ability of employees to adapt. On the other hand, while a descriptive framework provides more stability, it may lack the flexibility to cater to individual needs. Companies then often circle around the framework and try to adapt to its structure and rules, thereby losing sight of their own business objectives. Perhaps Scrum rose to popularity because it struck the sweet spot of descriptiveness, which many technology-driven organizations require. In case of doubt, choose the simpler frame.

How to use

1. A good framework uncovers your organization’s weak spots. It’s up to you and your colleagues to leverage this insight for improvement. For example. If the Cynefin framework reveals that the essence of your product domain is complex, yet you persist in applying measures suited for the simpler domain, the responsibility to adapt rests with you.
2. It’s crucial to secure commitment in your organization to making the necessary adjustments as you begin working within the framework’s structure. Clear framework guidelines are essential in this respect. I often encounter skepticism when I mention that Scrum explicitly allows only three roles within a Scrum Team, despite individuals claiming years of Scrum experience. Ignoring this creates waste and makes using the framework pointless. It is then even better not to use the framework.
3. Divide and conquer. Begin by implementing a framework in smaller parts of your organization, ideally in areas where it can be applied without disrupting the rest of the company. This approach is essentially the only way to develop expertise effectively. It reduces the risk of undesired development. If the framework proves beneficial, you can then extend this expertise to other parts of the organization. Once your colleagues become experts, you may even craft your own framework based upon the initial one.
   Spotify exemplifies this strategy. They started with Scrum with a few teams and, leveraging that expertise, developed their own framework upon Scrum to scale their product and organization. However, this framework was tailored specifically for Spotify and was very descriptive and may not be directly applicable to other organizations, unless they are in the business of developing and maintaining a music streaming service.

Conclusion

Navigating the landscape of organizational frameworks requires a thoughtful approach, blending analytical rigor with practical experimentation. The allure of frameworks like Scrum, SAFe, LeSS, and other lies in their promise to usher in agility and a new culture within organizations. But Frameworks can achieve a lot more than agility. In a good and a bad way. Their successful implementation demands more than just blind adherence to principles or an uncritical adoption driven by trends. It requires a clear understanding of your organization’s goals, a willingness to adapt and iterate based on real-world feedback, and, perhaps most crucially, a commitment to fostering a culture that values continuous improvement over rigid conformity. By choosing and using frameworks wisely, organizations can harness their potential to drive meaningful change, unlock new levels of performance, and thrive in an even more complex and faster pacing world.