Agile Agile Transformation

No, the title is not a writing error.
It’s about agile transformations and attempts that seem to ignore why they want to adopt agile methodologies in the first place. Often it’s just a linear and priority-controlled processing of agile handbooks instead of selling the real ideas behind it. Most of all they fail to consider the consequences they bear for your organization.

Why not transform an organization into an agile one with an agile mindset and approach?

Why go agile in a non-agile way?

In agile software development, big upfront design, i.e. defining the complete or most of the architecture for a system that hasn’t even been started with or making technical assumptions not based on any evidence, is dismissed for various reasons – and that’s a good thing.

Investing too much effort into a complex and unpredictable environment before actually knowing why and what value it has is considered as waste. What’s more, too many facts set in stone prevent you to make incremental and iterative changes and improvements to your system.

Agile software development [ASD] mainly targets complex systems with dynamic, non-deterministic and non-linear characteristics. Those who have successfully implemented it do know that it can work very well.

Do you think that the world around software development is static, deterministic and linear?
(In many cases it’s far worse than the software systems you develop.)

If not (I hope so), why then do so many organizations try to apply agile transformations in a rather non-agile way? Often with a “big bang” approach (“I read about Scrum, sounds cool, let’s do it!”, “Our company has to be agile, because being agile means delivering fast”), not even knowing what problems they can bring about and what an agile transformation actually means.

The core of it all

Coming from a background where the definition of good design is: when there is nothing left to take away of something (not when there is nothing left to add), there is one thing we cannot take away from Agile. Call it the axiom or the least common denominator of Agile Software Development. If you take away this nucleus (i.e. DNA), it cannot be seen as ASD anymore. That could be one thing or more, but every single one of them is absolutely essential in forming the whole.

“So what?” you may think. What kind of new wisdom do we gain from that statement?

If we think of an agile transformation, what’s there that we cannot take away?
The only constant thing is change. Therefore the one thing you absolutely cannot take away is the ability to react to changes.

It comes down to one essential property, an invariant to all parts of an agile transformation and ecosystem: Adaptability.

Everything you do should be aligned to this core capability of any agile “design”, and be the focus of all of your efforts. If you don’t view adaptability as the most important and invariant fact, then probably you shouldn’t even start with (a full) implementation of an agile methodology.

Why adaptability is crucial

Today’s business world is dynamic, complex, and unpredictable; and often chaotic.
Basically the same characteristics are valid for software development as well. That’s the main reason why ASD has been invented. The core of it is that you are able to deliver your product or service early, fast and often. Having a short time-to-market interval is crucial for today’s business success.

Then, if you see adaptability as one of today’s most important factor for success, then every single step, method or process you want to use, include or change in the transformation should aim for reaching the highest possible level of adaptability. You can start small and implement the patterns incrementally and iteratively – fully compatible with the spirit and strategy of ASD.

It’s not about technology or process only. In fact everything you do should be adaptable.

And it’s really about everything! This includes people, architecture, management, technical issues, and marketing.

Don’t try to find the best solution for something – you most probably won’t – but the one that is most easily adaptable to the unknown future. And the one that won’t kill you when it does not work.

If your business is not adaptable today, well, it may no longer be your business tomorrow.

Increment and iterate

As you don’t want to do a Big Design Up Front and e.g. state you need database A and framework B before even knowing what problem you have to solve, don’t say „we need Scrum, Kanban or whatever process or tool“.

Identify and prioritize the problems you want to solve and then start with a small implementation of a method, tool, or process. Some will need time to unfold their usefulness – or not turn out to be useful at all. Keeping it focused and small will even allow you to start a parallel evaluation and after a reasonable while decide which one to use and to dismiss.

Install reasonable and rateable evaluation criteria and measurements for every single part in order to be able to decide when to iterate it further. Try to adapt every single part with the smallest amount of dependencies to other problem spaces in order to be able to assess its real value.

Maybe after some time you’ll end up with the same setup that is described in the official Scrum or ASD handbook or some consultant would have sold you. But instead of being “commanded” to implement Scrum and not knowing why, you have gathered skills and knowledge and know why you are doing something and what benefits and drawbacks it has, accomplishing adaptability. And you are able to replace it with a better approach at any time.

Or you may discover that even non-agile approaches work for you very well. And if they do, why not focus on enhancing them? Remember the manifesto: It’s not about processes or tools, but about individuals and interactions.

Inspect and, well, adapt

Setting all this up and implementing the techniques to be able to constitute and value it always implies the questions “How can we adapt or replace it?”, “How hard it will be to switch to an alternative way?” and “How do we know that we should adapt or replace it?”.

No single part should ever be set in stone or hard to change, not even the most critical or the most expensive ones. The degree of expected adoption effort shows you if you’ve started too big or too small.

This concept can be applied to almost any scale, from an entire organization to single practices. For every part the question stays the same: Can we make it better and at what cost?

Don’t buy into silver-bullet approaches that seem to enable you to control your agile transformation. They are nothing but oxymorons and have done much more harm than good to our industry by trying to stabilize the volatile and control the unpredictable.

If something is not (easily) adaptable, it should not be considered a valid member of the agile ecosystem.