Agile: More than Just a Framework

In a past blog article, we learned how an Agile mindset can support you dealing and responding to complex challenges.

While the Agile Manifesto is still young, the foundations of Agile are not new. They are based on over 100 years of Management Science. You find a comprehensive overview on Niels Pfläging’s slide deck illustrating the “heroes of Leadership”. While those individuals are not the inventors of Agile, they are certainly the inspirations behind the Agile values and principles.

Nowadays, many companies believe, if they follow Agile techniques, frameworks, or processes (e.g., SAFe, LESS, Scrum@Scale, Scrum, etc.), they will become Agile. This is why many consultants and coaches specialize in training a certain way of working. But SAFe, for example, became such a monstrosity of a framework, that it needs an armada of consultants. The Agile principle on “Simplicity” is certainly not fulfilled. The idea was to become Agile, but most of the implementations are more about imposing certain ways of doing things.

Agile in the Marketing only

This might be controversial, but many companies using the word Agile in their marketing to attract customers or talent are often not really Agile. They use words like tribes, squads, or have Daily Stand-Ups for their teams. But their management methods (Pay by performance or MBOs) are antique. They use words such as “empower” or “motivate” their teams (or worse: individual team members), but then dictate them how they can be empowered or motivated.

Let’s look at some companies not following a particular framework, but living the Agile values:

• Dutch nursery company buurtzorg or the American tomato company Morning Star created decentralized structures and enabled every independent team or individual to make decisions themselves. While there is Management (as in organizing their way of working), they do not have Managers.
• Japanese automotive Manufacturer Toyota implemented Quality directly into the manufacturing process. Instead of outsourcing quality to another department, they give control to each line worker to inspect the work. Through so-called Andon Cords, everybody influences the quality sustainably.
• German drug store dm – drogeriemarkt or American Southwest Airlines empower their teams to focus on customer. They are famous for putting their employees first and trusting them to take care of the customers. Their passion for their job is visible publicly to the company.
• American tech giant Google is famous for using advanced Engineering practices. Through that, they enable quick turnaround of innovative ideas, which are still of high quality. They are also not afraid to kill an idea, even after substantial investments (Google Wave or Google plus).
• General Electric used short customer’s insights and short feedback cycles to develop Turbines. They are famous for using the Lean Startup ideas for their RnD projects.

None of those companies are famous for using the word “Agile”, but apply its values and principles daily.

OK, OK – Agile is not a framework, but what is it then?

One problem, we usually run into, when working with Non-IT Teams, is the wording in the Agile Manifesto itself. Coming from Software Engineers, they are using the words “software” or “architecture”. This alienates individuals not familiar with those words. Many people devalue the Agile Manifesto right there.

Therefore, in our workshops, we are investing to unlearn the software wording and help the participants to think about it organizationally. As mentioned already in this article in detail, the following 7 principles might be more appropriate towards Organizational Agile:

• Through cross-functional, self-organized and competent teams, we can use diversity and decentralize the decision-making.
• By delivering user value incrementally and iteratively, we can ensure that our users can benefit from our solutions or services as quick as possible. Then we can learn and improve the solution based on their real needs.
• With radical prioritization of our planned work according to customer value, we achieve easier return in investment.
• Teams can achieve the above only through transparency on the what and how they work.
• With a Continuous Improvement Cycle, teams can remove waste constantly and become more effective and efficient over time.
• Teams are not motivated by the outputs, but by the outcomes of the work towards the organizational vision. “If you want to build a ship, don’t drum up men to get wood, assign tasks and divide the work, but teach the men to long for the wide, endless sea.” – Antoine de Saint-Exupéry
• To achieve all of the above, the role of Managers needs to change. Instead of commanding and controlling, what people do, they need to facilitate the above principles,

Agile is not about doing something the right way, but about asking the right questions

The above principles do not tell you, what to do. But they enable each individual in an organization to ask questions for further improvement of the work environment, such as:

• How can we make teams make more competent? Note: Make teams more competent, not individuals.
• Is the work transparent enough? Note: It is about visible work, not about policies. Do not just make suddenly salaries transparent.
• Do we continuously improve, etc.? Note: Improvement is not only about fixing issues, but also about emphasizing learning

Our Scrum is pretty good – Isn’t it enough?

As a consultant, the answer to the question can only be: “It depends!”

In an in-house workshop of a pretty Scrum-competent organization, I asked participants, what words or terms they connect with the word “Agile”. One participant said: “Timebox, but it is unclear to us why we do it.”

And this is revealing. If you do Scrum and everybody complains about its terms, then they might not understand, why they do it. Then this team might follow an Agile intended framework by the book. But they might not be Agile and will not get all the benefits from it.

As I discussed with a Mentor many years ago: “If you are doing Scrum by the book, chances are high that in Sprint #2 you are not doing Scrum by the book anymore.” This is because you found a better way which fits the purpose and context of your team better. You enabled a Continuous Improvement Cycle. If you are still creating incremental value within your iterations, then you might be Agile – regardless if you are doing an agile Framework such as Scrum or not.

True Agile is rarely only visible in the process

Agile is not a framework, but rather a state of being. But for that, we need to look at it as an organization. As the examples above show, Agile is more about the way we make decisions, than just about following a framework. We need to invest into the values & principles. If you are doing Scrum, but the review is your User Acceptance Meeting, you might follow some guidelines on doing Scrum. But the real feedback comes from customers & users. And this is where the benefits of agility are.

By emphasizing the above mentioned principles, organizations equip themselves better to handle complex challenges successfully.

This is basically all you need to know about Agile. If you are wondering, how to get it started and what to do, when you are confronted with resistance, then stay tuned for our next article. If you want to start bringing Agile to your organization, then consider our Academy for Agile Coaches.