Agile Agile Transformation

1 Comment

No, the title is not a writing error.
Its about agile transformations and attempts that seem to ignore why they want to adopt agile methodologies in the first place. Often its 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 hasnt even been started with or making technical assumptions not based on any evidence, is dismissed for various reasons and thats 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. Whats 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 its 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 bangapproach (I read about Scrum, sounds cool, lets 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, whats 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 dont view adaptability as the most important and invariant fact, then probably you shouldnt even start with (a full) implementation of an agile methodology.

Why adaptability is crucial

Todays business world is dynamic, complex, and unpredictable; and often chaotic.
Basically the same characteristics are valid for software development as well. Thats 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 todays business success.

Then, if you see adaptability as one of todays 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.

Its not about technology or process only. In fact everything you do should be adaptable.

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

Dont try to find the best solution for something you most probably wont but the one that is most easily adaptable to the unknown future. And the one that wont 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 dont 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, dont 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 youll 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 commandedto 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: Its 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 youve 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?

Dont 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.



  • Nils Wloka

    Hi Nino,

    I couldn’t agree more. I instinctively ask why when confronted with the wish for an “agile transformation”. Usually, an organization has arrived at its current way of doing things because of some (often implicit) need. Changing it all according to a prefabricated plan is unlikely to yield the expected results (especially if goals haven’t been identified first). I think that’s what “respect the current process” is all about in the Kanban world.

    When working with a customer who wants to do an “agile transformation” (I don’t really like that term all that much), I usually start with a series of retrospectives to find out about all the different perspectives, perceived strengths and weaknesses and useful organizational resources for driving the change. From that it’s all about inspect and adapt: Find one thing you want to change, establish success criteria and start a small experiment. Rinse and repeat.

    Thanks for the great post and kind regards,



Your email address will not be published. Required fields are marked *