Struggling with Agile

I’ve been struggling with Agile.

Agile has endured a difficult path for a number of years. That much is true. There is no way to sugarcoat the truth. For a long time, things have not been easy. There is a constant battle to get agility back on track, despite the fact that more and more organizations are moving toward agility and looking forward to becoming agile so they can offer better results and more value to their consumers. Why is that, then? Let’s try to determine what the root reasons of this are. This is, of course, just my opinion on the subject as usual. Whether or not I agree with your perspective, you are more than free to share it. That is after all how we learn.

It’s a bird! It’s a plane! It’s… Agile!

Agile has been touted as the silver bullet all along. Numerous individuals, some of whom ought to know better, have promoted Agile since its inception as the only method for managing projects, products, and, more lately, entire organizations.

Many organizations have been implementing Scrum as the only method for becoming Agile since the very inception of Scrum, and in particular since Jeff Sutherland published the now-iconic book “Scrum: The Art of Doing Twice the Work in Half the Time” (a title that led many executives to believe that speed was the main benefit they would get from Scrum). They mistakenly think that by implementing Scrum across the board, everything in IT will afterwards become lot faster and much more profitable.

Agile became synonym of Scrum. This is error number one. Probably the biggest one. Let’s continue…

There are more mistakes being made daily, let’s look at some (and there will be others but I’m focusing on these):

1. The goal of Scrum is not to complete tasks as quickly as possible. Scrum is geared toward assisting in the resolution of difficult issues by establishing a set of circumstances that promote communication, collaboration, and trust through brief iterations, empowerment, and continuous feedback. Even if one were to believe that they were founded on the Agile Manifesto, they would be mistaken. While Scrum was developed by Jeff Sutherland and Ken Schwabe and introduced to the world in 1995, the Agile Manifesto was finalized in 2001. The three tenets of Scrum — Inspect, Adapt, and Transparency — should be emphasized. By continuing to learn and develop, you may improve your deliveries. The empirical method that underpins everything is the key in this situation.
2. Agile organizations should never have profit as their primary goal. If we provide our customers with high-quality goods and/or services, profit is a byproduct — and a very good one at that. They will buy it if we concentrate on quality and provide them what they need and want. They will also develop into dependable clients. I’ll leave you with two references in regard to this: Simon Sinek’s Start with why:?https://www.youtube.com/watch?v=u4ZoJKF_VuA?and Salim Ismail’s Exponential Organizations:?https://www.youtube.com/watch?v=FNQSM4ipZog
3. Avoid consulting firms that provide “ready made” solutions. These are Agile’s cancer. Some promote that they are Agile, while others can claim to be Lean or even Kaizen. You are being fooled if any expert or consulting firm begins the approach by offering a solution. Any business that takes Kaizen, Lean, and Agile seriously should start by asking, “Why do you want to do this?” Where are you at this moment? What direction are you seeking? Finally, but most importantly: What are you prepared to do to get there? Different organizations, business models, and, obviously, where they are situated in the overall scheme, all have a significant impact on the limits they may impose and the degree of freedom they are given. For instance, a governmental organization may be subject to several restrictions. The same holds true if your clients are governmental organizations. If you work for any financial institutions, insurance companies, or regulatory bodies. businesses that, for whatever reason, use static milestones. All of these call for unique approaches, and various constraints have an effect on what you can do and the degree of transformation you are free to pursue. Never assume that one size fits all.

So you see, most people have been doing it incorrectly. And did I mentioned (again) all the so-called consultants and professionals who have been profiting from this…

Agile is much more than just software

The Agile Manifesto for Software Development has always been exactly what it claims it is. About software. And it will remain exactly that, at least historically. Agile has evolved beyond software development, though. Although the manifesto was preserved in its original form, since it was written with software development in mind, it still holds true today for other approaches, products and services. You’ll quickly realize that it just makes sense if you simply replace the software with the desired strategy.

We are failing

Since 2009, I’ve worked with Agile with numerous Portuguese and international companies, each using a different strategy. Nearly all make the same errors while applying Agile, and they all suffer as a result. Some people only attempt to implement a tool and a few processes at the team level, remaining as waterfall as always (and occasionally worse, as change is always faced with some resistance). Others make a strong first impression by announcing the transformation as something that will be included in their roadmap, and occasionally the announcement suggests top management support, but treat the entire thing as a project to be developed by a few (occasionally hired) Agile Coaches rather than a company-wide effort that requires everyone to be involved and onboard. And others even include the Agile transformation initiative in the roadmap for the digital transformation, which in and of itself breaks my heart. Even though they can be done simultaneously, the two are distinct from one another and should be handled accordingly.

We all end up failing because we don’t adopt Agile as a strategy for getting better results but rather see Agile as the ultimate destination and merely apply tools, procedures, and practices at the level of IT development to get there. When a company is actually a million miles from being agile, it ends up calling itself agile.

And this is why I’m struggling with Agile. The big question now is: where should I go from here?