What does it mean to be agile?

A few years back, I coined the phrase, "Creating understanding is more essential than offering solutions". It used to be my working motto. Then I realized that even understanding is nothing. 

Agile Knowledge

As trainers, in a classroom, we teach "Agile" - be it Scrum, Kanban, XP, SAFe, LeSS or whatever. From twenty people who walk out of the class, maybe one has really understood the "Why" behind the things we teach.  The others jump right into doing and sooner or later struggle, because no classroom training can ever be comprehensive. The reason why agility is so important: reality is more complex than any process, method, strategy or approach we could devise.

Agile understanding

As consultants, we have a boatload of knowledge and even practical experience when it comes to implementing agile methods, frameworks and structures. But we usually still fall short of bringing our clients to the level we are. Not because we don't understand, and maybe not even because we can't get our clients to understand, but because we're talking about things we can't do with our client. We bombard them with knowledge and then try to approach the minds, but fail to bring them into action.

Agile Practice

Many agile practitioners merely go through a series of motions with their client (or their company, respectively). They may have both knowledge and understanding of what they do - yet still don't make any impact nor generate fundamental breakthrough. Why? Because, for them, it's just a job: A role they take. It ends with the engagement. And outside, there are other practices, other behaviours. They aren't agile. They only use agile approaches.

Those who just are

And then there's people who are like Toyota. Toyota didn't devise "Agile", their goal wasn't to implement "Lean". They just did, they figured it out all by themselves. And maybe they couldn't even explain half as well as some Agile Trainers can what they did and why the things they did were "Agile". Indeed, they didn't care for such labels at all.
Did they ever bother to build sufficient upfront knowledge about "Agile"? How could they, there was no such knowledge basis!
Did they bother to analyze and understand in detail what "Agile" means? The concept didn't exist, and it never crossed their minds!
Did they bother to implement the "Agile" practices correctly? There was no such thing! They made it up as they went.

They didn't stick to a book, they didn't stick to a concept, they didn't stick to a specific practice.
And that's what made them agile.

Top 3 success factors for agile transitions

So... SAFe. Big picture, many elements. What's important and what's not? What's make or break for becoming an agile organization? In this article, I will examine - based on my personal, subjective view, the three most important elements determining whether you're going anywhere.

What's not important

Many organizations start by defining their future structure and ensuring that all important people have gotten an "agile" role. Let me be blunt: in many cases, the transformation has already failed at this point, because it will be the same people doing the same thing in the same way as before, just with a new label.

So then, what is important?

#1 Relentless improvement

Many organizations tailor the Emperor's new Clothes. They set up systems where transparent, honest criticism isn't welcome - only good news and affirmation of status quo are acceptable. Even when they do indeed set up ceremonial Inspect+Adapt events, these events will never result in fundamental change and are usually just affirmation sessions leading to cosmetic changes when invasive surgery would be required.

To become agile, the organization must be able to accurately identify where things are going wrong, then precisely locate what aspect of the system is the root cause, then mercilessly make effective changes. And then, they must acutely observe the outcome of that change. If this isn't happening on a frequent basis, tranformation just establishes a new status quo.

An organization without a culture of Relentless Improvement will be cargoistic - they will go through all the motions in a ritualistic way and never understand why they're not seeing the desired benefits!

A) Systemic Inspect and Adapt

Team Retrospectives are just a small part of the picture. Everyone should be encouraged to identify and highlight systemic dysfunctions. The organization must have a transparent process for addressing, analyzing and resolving systemic dysfunctions. This takes courage on everyone's side - and openness from leadership.

Agile coaches, respectively Scrum Masters, first and foremost, need to work on creating both this kind of culture and awareness.

When effective systemic Inspect and Adapt is in place, most of the other things will eventually fall into place.

B) Closed feedback cycles

Feedback occurs everywhere, anytime: Among individuals, during the work, in processes ... If feedback is accepted and acted upon, further feedback is encouraged. When feedback is routinely rejected, the cycle breaks. And when no mechanism for providing feedback exists, the door to improvement is closed.

Agile coaches need to keenly observe how feedback works and actively shape closed feedback cycles.

C) Radical Candor

When the Emperor has no clothes, people must be able to say so. A dysfunctional process must be fixed, a worthless requirment trashed and an undesirable feature axed. As long as there's a mindset that decision makers know why they want things and the system doesn't incentivize stopping the wrong things, the most significant improvements to performance and outcomes just won't happen.

Agile coaches need to lead by example in being candid: Questioning worthless work and dysfunctional structures are bare minimum requirements to effective change.

#2 - A strong product organization

Let me be clear, I don't mean that a lot of people should be involved in "Product Owner/Manager" roles. A product organization is strong when it has effective mechanisms of addressing the right things and setting developers to do the right thing. The product organization isn't as much about structure as it is about turning opportunities into value in a very short time. It's about setting up the mechanisms and instilling the knowledge for maximizing value.

A) Focus on Value

Product people need an appropriate, effective way of discovering where value lies, identifying which backlog items have how much value and extracting the primary value from larger topics. When product people aren't keen on maximizing the value delivered, all is lost. Any mechanisms or incentives within the organization which tint, bias or distort the understanding of value will multiply a hundredfold into ineffective outcomes, so they need to be addressed and removed.

Agile coaches need to establish a focus on value by helping product people and managers see what is value and what isn't.

B) Deferred Decision Making

Until it's clear whether a value hypothesis is even valid, product people should reserve the right to change direction. When items are scoped for implementation before it's clear that their delivery will generate any value, there's a lot of money at stake. Should exploratory work open up alternative routes, the product organization must be able to inspect and adapt to this!

#3 - Technical Excellence

Doing the right thing in the wrong way may make the outcome appear like it was the wrong thing to begin with. Shoddy workmanship costs money, wastes opportunities and causes further harm to outcomes in the future. Developers need to be able to take pride in a job well done and have the confidence that their results are of high quality.

A) Genuine Shift-Left

Developers can learn how to better build products which do what they're supposed to in a way that customers like. Having a separate Testing or Operations unit is counter to this learning taking place. Terminology like "DevOps Team" masks dysfunctions and fails to address the root cause.

Agile coaches need to spot where functional separation breaks feedback cycles and bring the right people together.

B) Lifelong learning

Knowledge workers need to have time free from delivery work to learn new things, experiment with new technologies and try out different ways of doing the same thing. The higher the utilization for delivering features and fixing problems, the less likely developers will keep their edge. While many developers are geeky enough to use their spare time to learn things, it's essential to make sure the organization enables structures and processes which routinely include learning.

The 5-minute Retrospective: Try Speedrospectives!

Agility depends on receiving timely feedback and turning it into effective change action. Relentless improvement requires closing feedback cycles wherever possible and whenever possible. 

Why Speedrospectives?

Many new Scrum Masters follow the boring, time-consuming and ineffective "What went well/what didn't go so well" template and can burn hours of precious team time without causing significant change - this model often degrades to a platform for self-adulation and/or ranting.

The Scrum Master -- or any agile coach, for that matter -- should create a self-perpetuating system of Kaizen, "Striving for the better", and do this in the most effective way.

Have you considered a Retrospective after every single meeting in your organization, to improve these meetings themselves and thereby increase the value of communication? How much time should that consume to be worthwhile?
A regular Retrospective is unfeasible in this context - but where, when and how do you address improvement potential then?

An important part of behavioural change is to address the situation as it occurs so that the memory is still fresh and set the stage for a future, more desirable condition.

The 5-minute Retrospective

When you know your audience and the situation is already stable, there's no need to go through the (definitely helpful) 5-stage Retrospective Process, you can just cut straight to the heart of the matter: What should be different next time in order to get more value?

And that's where my handy Speedrospective template comes into play:

The diagram itself is self-explanatory:
"If we do this again, the next time, we should ..."

• Try: Introduce a new element or modify an existing element. For example, in a Retrospective, it could be: "Try whiteboards instead of sketching on letter-sized paper"
• Stop: Elements which should not be repeated. For example: "Multiple people talking"
• More: Elements which are helpful and could use strengthening. For example: "Collaboration on issues"
• Less:  Elements which, although helpful, are overdosed. For example: "Process explanation".

Schedule of the Speedrospective

Create sketch

If you're fast (which is what this is about), you draw an X and write 4 words. That should just take half a minute - or a minute, while you're explaining what's coming. (1min)

Collect items

Take 2 minutes to collect feedback - more time isn't needed, because if participants don't have anything on their mind, it's probably not important, anyways - and next time around they might prepare a sticky right in the moment when something happens because they know they can bring it up. (2min)

Decide

After issues are collected, vote ONE the group would like to see implemented. (1min)

Debrief

Agree how to make it happen and thank the group. (1min)

Summary

Speedrospectives are a highly effective tool to close feedback loops, initiate change and establish a culture of relentless improvement. The process is significantly more powerful than the "well/not well" template, because it's fully outcome focused.

Other uses

The suggested Speedrospective template can be used in many contexts, such as event closure - as well as in personal and organizational coaching.

Variations

There are many ways to commence a change-driving Retrospective within 5 minutes. The above approach is neither to be considered prescriptive nor the only way. Try experimenting with Speedrospectives and see what works for you.

A note of caution

Speedrospectives may miss fundamental change opportunities - for example, when we're having the daily frontend architecture status meeting, we will find ways of getting the most value out of this meeting without ever crossing the idea that the meeting itself isn't a good idea. They are not a panacea, just a simple power tool to support a continuous change mindset.

Why organizations use Scream

The Scream framework has struck a nerve. This parody of the Scrum framework isn't just loaded with antipatterns - hundreds of people have already noted how similar Scream is to what they observe in their own organization.

Scream is a parody, and it would seem like nobody in their right mind would do those things - yet people do exactly that. But why?

Scream works!

Scream is effective. It works. The patterns found in the Scream Guide are all ways in which specific problems the organization has encountered have been addressed. And unlike Scrum, there is no rigour to Scream - it works very similar to the ice cream truck in summer. It addresses a need and makes people feel better.

Here's how:

The Scream flow

The Scream flow is easy and intuitive.

On the surface, it works like this:
A problem appears, and there's pressure to act before this becomes a personal issue, such as having an escalation, seeing your performance review drop, and therefore your bonus disappearing or whatever.

So why spend time to identify and isolate the root cause which may be hidden somewhere outside your own sphere of control? Pick a Scream pattern and apply it.

The pressure lifts - or at least, it goes down a few marks on the scale. Scream experts learn to throw Scream patterns at problems before anyone has even noticed there's an issue. Stress levels return to normal, and there's even a reason to celebrate having taken care of an issue.  Instant gratification.

And when the next problem appears? Rinse and repeat. Scream becomes routine quickly.

The rug

There's an insiginificant fly in the ointment. It's so miniscule that most managers and developers are more than happy to just let it go, as the evening is saved and no further meetings are required on the issue:
The problem wasn't solved. A band-aid patch is no cure. The core of the issue has been shoved under the rug, and the Scream "solution" has added another problem to the batch. No matter. Let's call it a day and move on to something completely different while the rizom continues to grow.

And one of these days, it will be harvest time. The problem has grown bigger than the rug and starts to resurface.

No problem - just apply the Scream flow and shove it under the rug again. It feels good to see the issue gone again.

Summary

Scream effectively makes problems disappear in an instant. This feels good. Even though the problems resurface and grow, there's always a solution: More Scream.