Since we must concede that agile frameworks won’t save you, that raises the question: What to use instead? What is an agile organization, and how do you become one?

What is an Agile Organization

I’ve recently started reading Atomic Habits (I can only recommend it) and the first chapters are enlightening: We are habit machines, our habits shape our identity, and our identity shapes our habits.

It is a very strong feedback loop and one we can use to acquire new habits: We need to decide who we want to be, and make sure to act accordingly. This will make us who we want to be (eventually), and make those habits stick.

On the other side, trying to change habits by doing something once (not smoking, starting a new sport, etc) and hoping it just sticks this time, does not tap into this motivational aspect that is associated with identity (being a non-smoker, being an active person).

There is plenty more in those chapters that you should probably read if you haven’t, but this got me thinking: This is true for groups just as much, and also for organizations. Organizations that hope to become agile by putting an agile framework on top of the existing structures/behaviors/identity are the same as a person hoping that this time the morning run will stick.

What this organization needs is very similar to a person wanting change: Decide who you want to be, and then act accordingly time and time again – in with the good habits and out with the bad. And never stop reflecting on your habits and your (intended) identity.

I think it would thus be fair to conclude: An agile organization is one that behaves like one. As simple as that: An organization that shows day-by-day more agile habits than not.

Agile Habits

But what are agile habits? Sprints, plannings and retrospectives, doing estimations. Those are ceremonies, not habits. It’s like going to the gym every week with your friends, but sipping smoothies together instead of working out. Forcing everyone to attend a retrospective meeting for 2h is a ceremony – a team member raising: “I would like to talk about this motion we are always going through and how it is helping us deliver value (faster).” – that is a habit.

Framework/Process	Habit
Holding dailies	Syncing daily to create a shared plan
Estimating story points	Discussing on how a story could be cut to become smaller an more predictable
Every team must have a responsible Scrum Master	Everyone in the team feels responsible (for the delivery of value)

Thankfully the authors of the agile manifesto gave us 12 principles to go by. They stand exactly at this line between habit and identity, which allows us to determine if a habit fits the ideals of agile or not.

Discussing bugs using the ticket comment system? Breaks “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

The Bugtracker: Who hasn’t been summoned to one of those infamous bugtickets, with the sole comment: “Can you have a look?” Only to realize that you and your colleagues spent around 3 hours in total understanding the context of that issue, dissecting the comment history, guessing the priority of the issue, assuming what has already been checked, collecting questions, posting a carefully drafted response to the ticket, to be answered again a few hours later. Cue a week-long back-and-forth between customer - service department - expert group. Then somebody has the audacity to pick up a phone and have a call and everything gets so much clearer very fast. And you realize it was never urgent after all.

And another thing becomes obvious: An organization (that is/was not agile) can only become agile, if it is embracing the principles of agile in the first place. All actions and behaviors in the organization must be made with the question: “Is this action in agreement to what we intend to be? Is this something an agile organization would do?”

This not only requires the present leadership to support the agile transformation (on paper), they need to be role-models, showing agile behavior every day and being ahead of all their teams and reports and they need to make clear which behavior they expect from their reports and peers (and which habits they would like to go away).

Leadership builds the scaffolding of an organization. And this scaffolding must support the new ways, must enforce the new identity.

The Consequences for Agile Frameworks

This basically means that agile frameworks are doomed. An “agile organization” certainly does not need a framework or its keyroles, which leaves them as “blueprints” for organizations wanting to become agile. So: doomed.

For one, forcing agile processes on top of an existing organization will not lead to an identity change, and the bad habits of the actual identity will creep back in.

But isn’t the framework intended to explain the principles by ensuring practices? Yes, of course it is. But will the present leadership take part in the practices? Attend the ceremonies? Even be aware of the cadence? Or are they sitting in their office, none the wiser and repeating: “We’re agile now, things should be better now!” Followed up with a more silent: “But can someone explain to me, what the agile part of our organization is actually doing and how that is supposed to work?”

Ask yourself: How many times would the leadership put all-hands meetings or reporting requests in times that are completely screwing with the cadence of the “agile organization”? Pick out individuals from the team to put them on super-important strategic side-quests (without even informing the team)? Would they bring issues to the teams, or solutions?

That many individuals and groups fail to differentiate between behavior that “breaks” agile and when a (new) habit is welcome, is a natural consequence: Not knowing what agile behavior is, they cannot know when they are showing or (re)-introducing a bad habit, and ask in all seriousness: “Well, doesn’t agile mean we are allowed to change things? Just do it?”.

So, no framework, no processes – habits and mindset.

Consequence 1

Adding agile roles to you existing organization will not help you. Identity comes from within and is carried along by the system (or its remnants). So as long as you don’t intend to exchange the complete scaffolding of your organization, you must make this scaffolding carrying the new habits (and the motivation to become agile).

It won’t help to have agile coaches or amazing scrum masters, if there are contradicting signals (“bad” habits) coming from the existing leadership.

Consequence 2

If your organization is not truly convinced of the principles of agile software engineering, it is maybe wise to not attempt an agile transformation. And this is fine: Nobody is claiming that agile is “better” for you. (But we’re all free to state we believe in better ways of writing software.)

What to do instead?

But if agile frameworks are not helping the transformation, how should one make the agile transformation instead? I think we need to consult the Atomic Habits again: Identity and Motivation.

Step 1: Soul-searching

Does the organization truly want to become agile?

Only if the answer is an honest and clear “100%”, and if the organization understands what “being agile” means (compared to what they have been doing until then, only then should a transformation be attempted.

This question should probably be coupled with a more general “Who are we and who do we want to be?”. Being “agile” is most certainly only part of an organizations DNA (and not necessarily the most important one – most organizations don’t even bother to mention that: it’s a given).

Clearly such an exercise must be led and driven from the very top of an organization.

Step 2: Embed

The next step is to embed agile habits into the daily operations as much as possible. The goal is not to be perfect, but to show more “good” habits, and fewer “bad” habits, and seek ways to improve this ratio constantly.

From the top down, the leadership should seek to understand how their current mode of operation is either helping or hurting, showing good habits or bad habits. This is deeply tied to embedding intent based leadership into daily operations and removing aspects of the command and control mindset. Thinking this part would be “easy and fast” would be presumptuous, especially since it requires deep understanding of the agile principles and how to apply them.

In parallel, habits all over the organization must change: Since you cannot take down the existing scaffolding in a running system, take existing meetings and “infect” them with (at least) one “agile habit”. Have your responsible IC demo a new feature to the customer, instead of just having the product management showing the changelog. Or draft an implementation plan together with developers, considering how they would implement a feature, instead of presenting your plan. Let agile habits and their benefits speak for themselves and “contaminate” one meeting, one product, one department at a time.

Step 3: Reflect

Reflect on your current state: what is good, what is bad; what works, what hurts. Reiterate on who you want to be.

Then apply those learnings to draft your next small action. Your next experiment. Make reflection and experimentation, seeking better ways, the norm for all parts of the organization.

Present the results. Yes, also the fuck-ups.

This step is also a great opportunity to “live” another agile habit: Are you going to do this reflection on your own, or are you going to invite different perspectives? Different ideas for improvement opportunities?

Summary

After all, an agile transformation is and will remain an incredible feat. Assuming that you can change the identity and habits of an organization, that has been working for quite some time in non-agile ways, with a leadership that has (mostly) had limited exposure to agile principles and habits is nothing short of illusory. And no (large) agile framework will (probably) be able to change that fact.

Nevertheless, you should never say never, and it might be possible. I would argue though that if you want to avoid an agile facade, it must go over the self-enforcing feedback loop of identity and habit formation.