Why is agile development so polarizing?

Over the last few years (or by now, decades), the software engineering industry has seen the rise of the Agile mindset. What started with Scrum has culminated in SAFe and beyond. Although many organizations are still making their first steps into the Agile world, some have already reaped the first benefits and are tweaking their approach as they professionalize further.

In my line of work, I work with companies with varying degrees of maturity when it comes to the application of Agile.

It is not unusual to find organizations willing to take the plunge, as the benefits proclaimed by Agile are enticing. More freedom and autonomy for the developers to really work their craft. Space and time for the creative side of the part of software engineering that is all about building something new. Something that does not exist yet. Not forgetting, of course, the promise of more speed in building the right things; that which is actually needed instead of that which was specified as the best effort to describe that need.

We now find ourselves in a position where we are starting to see the truth of Agile, the mistakes that can be made, and the dangers that lie within. 

As with anything in our society, agile is but a method. A tool. Tools can be used for good and for bad. Tools can be used in the right way and the wrong way.

So let’s take a step back and review how agile has disrupted the market dynamic:

1. The craftsmanship of developers has been recognized more than ever before, which is good.
2. The agility of projects did increase, though (I’ll venture) not to the degree we would have liked.
3. The power balance has shifted, leaving managers frustrated and not in control.

And this last point is polarizing because we can see that the power balance in software engineering has shifted. A small available talent pool combined with the digitalization of business has meant the power structure within an organization has changed irrevocably.

The mistake? Not putting up the guardrails that are needed.

Many managers in enterprises that have started their Agile journey are left without a method to understand how to steer their software engineering toward the activities that matter most. To make sure effort is expanded on those tasks that are of most value to the organization. Implementing agile working methods has left managers unable to cope with the power block that developers have been able to generate for themselves.

Determining which technologies to develop. Setting the security guidelines. Arranging the architecture that supports the company’s growth ambitions. Choosing which tools to utilize. Developers are no longer influencers when making purchases but are making the buying decisions.

And I know that many software engineers and developers will brush this situation aside, which is a mistake. 

Why? Because within any organization, software engineering, and the business are symbiosis. When management is frustrated about not being able to steer the software engineering practice in the right direction, this is a real problem.

The solution? Software Engineers and Developers need to acknowledge they are not alone in the organization. Their view of the business might not account for the broader strategic objectives.

Agile work methods have given developers the keys to the kingdom but without access to the room high up in the castle. This high-level view of the business landscape is what makes or breaks a company. The balance has to return, and Agile needs to be understood for what it is: a tool that requires boundaries like anything else.