The original promise of Agile – kept or broken?

Twenty three years ago, seventeen men signed a manifesto. At sixty eight words long, with just four points, it was short. Just a few lines to get across a powerful message. Not that easy to remember though. I’ve found that interviewees can rarely recite it, even those who claim to be specialists.

The manifesto says that whilst there is value in the statements on the right, they value the statements on the left more. Also, that this better way of doing things had been uncovered just by doing it and helping others do it too. What were they doing? Just one thing… they were developing software.

The sentiment behind the Agile Manifesto was simple and lightweight. Yet perhaps like many elegant ideas, simple to say doesn’t always mean simple to do. 

Nobody claimed that this approach could be applied to everything from product development, manufacturing, infrastructure engineering, budgeting, talent management, or even running a family meeting. To look around today at the plethora of fields to which the idea of “agile” thinking has spread, it is clear the impact has gone far beyond software development.

How did the practice of Agile attract such a broad church of converts? I asked an AI for the single word that best described the four core values. It gave me the word adaptability. It asserted that the values emphasised the importance of being flexible and responsive to changes – in order to deliver the best possible outcome.

Fair enough, most of us who practise Agile would nod. The core promise is a flexible, iterative, and customer-centric approach to software development. Teams are empowered to deliver value faster, and to adapt rapidly as needs change. After two decades and several waves of technology later, is this concept of adaptability still key? What about other capabilities like resilience, repeatability, speed to market and quality?

Does the pressure placed on teams to adapt, cause other problems? Is there a risk that agile becomes fragile?

To be clear, I am not suggesting going back is better. The problems of rigid methodologies that can’t adapt to changing requirements, nor cope with unforeseen challenges, are real. I recall in my first job asking a developer if some fields could be added to a COBOL system, finally in use after many months. He replied: “Write them down in a book.” Which presumably I could keep alongside the one he gave me on how to use it. 

However, let’s not forget that it was talented, committed developers who came up with Agile in the first place, to help themselves be more productive. The question to ask is how do we make sure that this is the kind of people we hire into our teams? The talented, committed, self motivated and capable kind?

No framework or process alone will take our teams from good to great. The desire to do better always comes from the team themselves. If it isn’t the team seeking to improve, then whether we follow Agile principles or not, we still risk failure.

Ask an expert for the reasons why the promise of better development through Agile has not translated to reality for many organisations. Can guarantee you will hear more reasons than you can easily address.

You might be told that Agile is not a silver bullet and your business has misunderstood the Core Principles. Did you see agile as a quick fix for your development woes, while overlooking the need for a cultural shift? Where was the ongoing commitment? 

Was your organisation focused on the process over outcome, letting everyone get bogged down in the ceremonies and rituals without prioritising value delivery and adapting? 

You knew that Agile is not about removing all structures, but rather is just a flexible framework that allows for continuous improvement, right?

Or was it cultural resistance, or a lack of proper implementation? Maybe it is insufficient training or other inadequacies, such as an outdated technology stack and a lack of automation tools – slowing down your development cycles and hindering adoption?

If training is the chosen remedy, is it surprising that there isn't a single, universally recognized list of qualifications for Agile practitioners? Early stage career professionals will often ask, which training is better? 

Should they start with a foundation like ICP? For scrum – is CSM or PSM I & II best? For Agile Project Management, is PMI-ACP similar to, or different from, the AgilePM Foundation & Practitioner? Should they become SAFe (Scaled Agile Framework) accredited? Or is MSP Foundation & Practitioner a better way to go?

Confused? Many of us still are, even those of us that have attended most of these courses. There is no shortage of experts with impressive certifications to match their consulting fees, only too ready to help.

In truth, often the best place to start when there are problems is simple. Just be a great manager. Good managers listen. As Stefan Stern says “This is the point about good managers: they are attentive. As customers, we know the difference between businesses that recognise what we want and those that don’t. As employees, we know when a manager is taking a healthy interest in us...”

If we can find motivated people and put them into teams that feel free to take risks and are prepared to help each other, they will astonish us with what they can do. Try not to overthink it. Let’s come back to the simple elegance of the original ideas behind the Agile movement.

Agile is not anti-methodology. It is time to restore credibility to the word methodology. Though as we help the next generation of talent to “level up” and start successful careers within the Agile software development movement, let’s also recognise the privilege it is to be working alongside people who hold compatible values. These are: trust and respect, and a belief that promoting organisational models based on people and collaboration will help build the types of organisation in which they’d want to work.