The Unbearable Lightness of Agile

How business executives took the good of Agile and killed it

Conflict is as integral and essential to the human experience as birth, love, and death. From struggle comes both the creative and the destructive, and the two are often intertwined. No more so than in the protests and demonstrations for freedom we seen recently.

Milan Kundera, one of the great 20th century writers, experienced the struggle first hand in the former Czechoslovakia during the Prague Spring of 1968. Of the future, he wrote:

“People are always shouting they want to create a better future. It’s not true. The future is an apathetic void of no interest to anyone.”

How often do we talk about change but change never comes about? We want to lose the extra weight, learn a new skill, live in another country, but tomorrow is no different than today. The idea of change is motivating until the reality of how to change sets in. Change is conflict.

So it is when corporate executives want to enact “change” in the organization, they make loud pronouncements and bold promises. There is pomp and excitement and a huge rush of activity. In the end however, the vaunted change runs up into the vast apathetic void.

Agile has become the latest in a long succession of organizational change initiatives. The imperative to change however is very real as companies recognize the command and control hierarchy of decision making no longer competes effectively against more flexible organizations like the tech startups that have rose to prominence in the past decade.

This has led to the adoption of Agile principles of software development as applied to an entirely new framework of management by companies. This framework comes with processes and language and additional principles that have formed to become organizational Agile.

Some have even gone so far as to sideline developers altogether, co-opt the term, and rebrand Agile as something completely different. Take Steve Denning for example. Instead of the Agile Manifesto’s four values and twelve principles, Denning gives us three “laws”. These are the “Law of the Customer”, the “Law of Small Teams”, and the “Law of the Network”.

There is nothing wrong or offensive about what he espouses. His take on “Agile in name only” is very true. Many firms are “implementing the ceremonies and processes of Agile but without the Agile mindset”. He questions the need of frameworks like SAFe to scale Agile across an organization. Likewise, he calls out firms that tout their own version of branded “Agile”.

Even the original authors of the Agile Manifesto agree that the reputation of Agile has taken a beating. Commenting on the current state of Agile last year, Martin Fowler said:

“Our challenge at the moment isn’t making agile a thing that people want to do, it’s dealing with what I call faux-agile: agile that’s just the name, but none of the practices and values in place.”

Dave Thomas concurs, pointing out the bastardization perpetrated by providers of “agile”:

“The word agile has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.”

Where Denning and others from the business perspective go wrong however is when they minimize what Agile means for technology teams.

“Yet the fact that the wording of the Manifesto is limited to software development makes it less than adequate as a definition of business agility.”

He argues that applying Agile only to software development runs into challenges in traditional organizations. However, the Manifesto is very clear about the interactions between developers and the rest of the organization:

“Customer collaboration over contract negotiation”

Agile explicitly states that the customer / user / business is intimately involved in the process of crafting software. Otherwise, why exactly are we writing software in the first place? Agile was meant for developers to work alongside the consumers of software to create better software that delivers more immediate and higher value.

Where Agile has worked is when it is applied to the hardest part of that delivery chain. That happens to be software development. Where Agile does not work is when it is used as a tool by management to browbeat developers into writing code faster. Ron Jeffries, one of the founders of Extreme Programming and co-author of the Agile Manifesto, rightly calls out the problem:

“When Agile ideas are applied poorly, they often lead to more interference with developers, less time to do the work, higher pressure, and demands to “go faster”. This is bad for the developers, and, ultimately, bad for the enterprise as well, because doing Agile poorly will result, more often than not, in far more defects and much slower progress than could be attained. Often, good developers leave such organizations, resulting in a less effective enterprise than prior to installing Agile.”

Agile without outcomes is not Agile. And outcomes are more and more dictated by software delivery practices as the backbone of launching products and features that mean the difference between winning and losing in the market. What Denning and his management ilk talk about is important in helping organizations work more effectively, but that is not true Agile.

I do not believe it’s necessary to delete the word “Agile” from our lexicon as Dave Thomas suggests. Rather, we need to be more vigilant about calling out poor applications of sound principles and the charlatans that promote bastardized approaches.

We also need to loudly proclaim to corporate executives that Agile starts with developers and works outward in cooperation with the business. Because many executives have no idea how software is even developed or the complexities involved, this is where IT leadership has an opening to coach their peers on how the creation and support of software actually works.

Kent Beck had it right. “I would like the world to be safe for developers”. Why can’t we just keep Agile as it was, a set of simple principles to write better software? All this other faux-Agile stuff just getting in the way of getting quality software shipped more reliably.

What has been your experience in adopting Agile in your organization? Why has it worked or not worked in those situations?

What is the purpose of having a countdown during a rocket launch?

I was watching The Right Stuff last night and wondered this myself…

We help IT leaders in enterprises solve the cultural challenges involved in digital transformation and move towards a community based culture that delivers innovation and customer value faster. Learn more about our work here.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s