Climbing the BS Mountain: Agile for the Sake of Agile

By | November 3, 2017


“Why did you start your Agile transformation?”… That’s a darn good question that many change agents and organizational leaders should ask themselves every now and then. That’s the question you should ask yourself and if you feel like you don’t have a good answer or if your answer is just fuzzy, sweet corporate talk, your organization is in trouble. Here’s why…

Most organizations adopt Agile because a company across the street does

That’s a very poor motive…

Every real change is hard. You can say that you transformation is on the right route if it ends up being the transformation of the people’s minds. Anyone can declare a new process; that’s the easy part. What is hard is shifting from the old thinking to the new one and without such a shift all process changes will have marginal impact, if any. As a part of transformation, the enterprise will have to go through a lot of real struggle as many “established” ideas and ways are simply incompatible with Agile. Some examples of that may be current org structure, funding model, HR practices, customer engagement, user interaction, leadership behavior and so forth.

It is very easy to put a bunch of stickies on the wall and start doing stand-ups, retros and things like that. But unless the thinking begins to change – especially on the management side – nothing good is going to happen. And guess what, it takes courage to abandon old fundamental concepts; it requires a real sense of urgency behind the transformation in order to do so. And adopting Agile for the sake of Agile gives your organization zero sense of urgency. It’s a one-way trip to the BS Mountain, which once climbed to, holds you a hostage of false sense of Agility from there on out.

Every transformation needs a set of clear business goals

On the one hand, this is the path to raising the sense of urgency around the transformation itself. This will fuel the journey, especially will help you getting through the hardships of the mindset change, which is the toughest and the trickiest part of the ride.

On the other hand, Agile is too broad a notion that provides certain optimization tools for your enterprise, but you have to decide what and where do you want to optimize. And for that you need a clear problem statement. This is not as simple as it seems, because you may easily get it wrong. Remember: when formulating the underlying problems, the organization will be fully exposed to all possible misconceptions and cognitive bias. Here’s a simple example of how this clouds the judgement and makes the enterprise myopic… Many organizations come to the conclusion that their software delivery function is slow and that’s the big problem they need to solve. What a great example of honest, self-crtitical reflection, isn’t it? Surprisingly no, it isn’t, in most of the cases. What organizations usually fail to see is that they deliver software that isn’t fit for purpose (AKA “crap”). Building it two times faster? What noble goal! The only outcomes of that will be a) more customer frustration and b) even further bloated codebase. I sense you started wondering: why don’t they see that the problem is not in the speed of development and delivery but rather in what is being delivered? Well, to arrive at that conclusion would require acknowledging that basically “we don’t know what we are doing”. That usually is a politically dangerous topic, unless again, the sense of urgency is high enough to overcome it. It’s a whole science (and art) of how to arrive at the right understanding of the problem and probably is a topic for a future post. But for now, let us assume that somehow magically we have arrived at the problem statement that will guide us through this journey.

As soon as we have the problem statement, it instantaneously creates the right focus for the entire organization. It actually makes Agile transformation a meaningful process. Now, instead of fuzzy “let’s be Agile”, we are aiming at very specific things, which in our case could be “effective cross-cutting feedback loops” that would allow the organization to effectively validate product assumptions with the customer and therefore prevent from building volumes of expensive poo-poo. Interestingly enough, such focus and specificity eventually leads to truly “being Agile”.

So, is Agile a mindset or just a set of tools?

I’m glad you asked…

It certainly is a mindset. But the trick is that you cannot directly “wholesale purchase” a mindset. You have to grow it through solving specific problems and for that, concrete tools are necessary. In fact, abstract talks about Agile never result in anything useful to the organization. All it does is only hiding the real problems deeper under the thick layer of false expectations.

So how would you know if you are on the right course? The answer is pretty simple and I will describe it as two mutually exclusive scenarios:

  • If all you do is working with the teams while assuring the management that the transformation goes well, and in doing so the management is being constantly delighted by your effort, you are on the wrong path! The organization is not pivoting to a new thought process; otherwise the management wouldn’t be all that delighted every step of the way. If this is the case, you should stop and rethink your transformation strategy immediately. My assumption is that you take the job of the change agent seriously, therefore will take action without hesitation or remorse…
  • If, on the opposite, you are actively working with the management and together you are going after specific problems; if those conversations are not always smooth and pretty, but the management begins to understand that the enablement they create is the ultimate success predictor in the transformation, then you are on the right path. You will definitely notice that you are moving in the right direction because the right path is pretty bumpy.

Ok, so, solving specific problems means we should aim at specific benchmarks, correct?

No, absolutely not! What are we… trying to “waterfall” the adoption of Agile? As hilarious as it sounds, it’s actually not as useful. We certainly have to focus on specific problems, but that doesn’t mean that we know how exactly we will solve them or in which exact state will our system (the organization) end up being upon solving them. The complexity of the environment in which we operate, does not allow us expect deterministic outcomes, in principle. We can only know the general direction, the vector. But any effort in saying, for example, that three quarters from now we will get customer satisfaction up 60%, is total BS and for that matter, it is precisely what you do if you are a citizen of the BS Mountain. It is critical that you don’t shoot yourself in the foot with speculative goals.

Remember: your transformation will constantly require a certain degree of intentionality. But since mindset and new habits are emergent in nature, you have to let them find their optimal growth pattern. Just like you do with your garden…

Good luck with your transformation!