(Fr)Agile

What is the response?

Imagine the following situation: you are walking down the street and an unknown man stands in front of you.

He pushes you once.

Seconds pass.

He pushes you again, but this time more aggressively.

Milliseconds pass.

You fall down, hitting the ground.

What is the decision?

Imagine the next situation: a friend of yours offers you a great deal - going to a tech workshop you always wanted to attend, but it was too expensive - for free!

He texts you with a question.

Hours pass.

He contacts you again, but this time by calling you directly.

Minutes pass.

The next message states that the ticket was given to someone else eventually.

Answer?

Imagine yet another situation: you are waiting in the overpopulated queue to get an autograph from your beloved (tech) author.

Suddenly a person behind you steps in and stands before you.

Minutes pass.

Author announces that soon he's going to end the event.

Seconds pass.

The guy that took your place previously was the last one.

Similar?

The world is a system of interconnected subsystems, as some might say.

Some events are happening and we are not "operating" in the vacuum. We need to decide. To take an action.

Or not.

Not taking any action is also an action.

Not making a decision is also a decision.

Our action, or decision, influences the world outside, as we are a subpart of it.

You have probably wondered (or to put it straight - I hope you wondered) about all those scenarios, I brought to you, at the beginning.

Can you say what they have in common?

Probably you can guess - it's related to agility.

But wait, what is "agility"?

The simplest definition (and the laziest, I googled it) could be:

Nice, but now it's pretty coupled to a single behavior. Let's generalize, so it is not tight only to "movement". What could we get?

I assume that such activity is not purposeless, there is some intention behind.

Plausibly, we are acting as a response to a fact that we faced.

We can say we are responding, reacting, with a proper action.

Let's move on (or should I say "act on"?)!

We have "quickly and easily" to think through.

What does it mean "quickly"?

Lazy searching tells me that it means:

and second definition is:

"Delay", "speed" - both of these words relate to time. They are functions of time (meaning, they vary based on the time).

Just to recap, bear with me:

Things are getting really interesting.

Could we say that one can measure his or her agility based on how fast is able to respond with an action?

Minimizing the delays in communicating the reactions to the world.

In the communication, between systems that exchange information, there is a very precise word, describing similar operation. A synonym to "response", "react".

Repeat after me: feedback.

Cursed word

Agile, written with the capital "A", became both a blessing and curse in the IT industry.

Holy Grail and dreaded sin.

I think we can draw the analogy between Nietzsche's "God is dead" and Agile.

The meaning is quite subtle when one adds the missing piece of the sentence: "God is dead (because you people killed him)".

Let's apply it to "Agile": "Agile is dead (because you people killed it)".

"We are Agile, we do daily stand-ups"

The mental journey we did, through definitions, mentioned nothing about: daily stand-ups, retros, technical user stories, etc.

Fast feedback.

As in the first tale, how fast can you react to some stranger pushing you? I think you won't wait much.

Fast feedback.

When a new feature is required to be developed, how fast are you able to introduce it? Hours? Weeks? Months?

Of course, it's very contextual, because you might need to understand the problem (I hugely advise doing so!), design proper architecture, etc.

What about experimenting? Verifying if the idea behind the new cool feature is correct? It will be blazingly fast feedback from the external world - your users.

Can't we isolate it, behind a stable interface, so that it is easy to be removed later? Just in case if it didn't make any sense?

"But I don't need to experiment!"

I hear you - it is not only about experimenting per se.

Experiments, fast feedback, rapid delivery - those are just side-effects. They happen, because something else happened before them.

One could ask - what happened before? What worked as a catalyst to obtain those effects?

Stand-ups? Retrospectives? Planning poker? Giving estimates on a non-repetitive tasks?

What was the first: fast feedback or backlog grooming?

As we already discussed (let's pretend, I know I am the only one talking here), it's not about any kind of ceremony, because it wasn't mentioned in our final definition (simple reasoning, isn't it?).

I also assume none of us wants to perform ritualistic actions to satisfy demigods of time-wasting.

But let's get not out of focus here.

One could call it too simplistic reasoning, but let's do a thought experiment.

We are going to reverse engineer how to get to "fast feedback" state through questions.

Have you noticed? I deliberately left one word without a definition.

Yes, I am talking about "easily". Fast feedback (pun intended) from Google results in two definitions:

and

Using those definitions, we can formulate inital questions.

How can we effortlessly get fast feedback? By introducing a small change.

How can we know it's small enough? By specifying it in isolation.

How can we fearlessly introduce a small change? By integrating it with the rest without any problems.

How can we verify that it integrates with the rest without any problems? By verifying the value is delivered without interruptions.

Stop. Retrospection time.

A small change?

A Specification?

An Integration?

A Verification?

If we compose them altogether, we can get the answer to our question: how to get to "fast feedback"?

Are you Agile?

Repeat after me:

We can now replace "fast feedback" with "agility" and here you go.

But this is nothing new. There are people in our industry telling all of those truths. And we do not listen to them.

So there are four components: a small change, a specification, an integration and a verification. For now, they are only plain words.

Then, what is their technical manifestation?

A small change? Minimum viable capability.

A Specification? Tests.

An Integration? CI/CD.

A Verification? Tests.

What's more:

• don't get misleaded by "Tests" - there is a huge difference between specification and verification (check "The ambiguity of TDD")
• to provide proper isolation one can start with "Feature Toggling" and treat it as a design tool (see my take on "Feature toggling as a design tool?")

Are you Fragile?

Starting from the ceremonial side won't get you far. Ritualistic approach might create illusion of progress and work, but it won't solve problems with agility.

It might make you fragile. Fragility isn't only reserved for all the frameworks that are supposed to help managing the project or delivery.

It starts from the software, from the technical aspect. Why?

Without understanding the problem, we can't assign responsibilities.

Without assigning responsibilities, we can't isolate things.

Without isolating things, we can't get right boundaries.

Without getting right boundaries, we can't get scoped, small changes.

So repeat after me: