Why discuss the state of Agile

Agile Software Development is the only modern way of working whose effectiveness has been proven on the ground: in the early noughties it turned the tide on the dismal record of medium to large-size software development projects. Today many successful big-tech companies (see here) that excel in organisational, technical and business Agility use practices stemming from the lightweight methods that came together under the umbrella of the Manifesto for Agile Software Development.

Agile Software Development also initiated a paradigm shift in the way organisations work. Such a shift was necessary to tackle the complexity of the modern world amplified by digital transformation, and globalisation. Many other industries started facing the very same unstoppable acceleration of change and exponential technological innovation, therefore they started looking into Agile Software Development to draw inspiration from the lessons learned there.

Furthermore, Agile Software Development led to the creation of the world’s biggest and most active community.

Even so, nowadays several software developers, teams and managers are growing disillusioned with Agile Software Development, and the sentiment for many CxOs is turning negative.

Where did this come from? What can we do about it?

The stories and experiences of failed adoptions of scaled and allegedly “Agile” frameworks (see here) and the allegedly “Agile” standard recipes and canned solutions from large consulting companies (see here) have a role in the change of sentiment toward Agile. This is reflected in the market share collapse of SAFe (Scaled Agile Framework) and, more generally, a decline of all scaled allegedly “Agile” frameworks and the other canned recipes by large consultancy firms. You can see this, for example, in the 17th State of Agile Report (see here).

While the market share of bad Agile is shrinking, what can we do to use that free space in favour of good Agile? Here is my proposal:

1. Ditching Imposition and bringing back the paradigm shift necessary for Agile Software Development to work
   
2. Ditching the Agile certification market and thought leaders’ self-promotion
   
3. Ditching Magical thinking that, since Agile has become mainstream, replaces the vetting and testing of any new techniques to prove their validity

1st: Ditching Imposition and bringing back the paradigm shift necessary for Agile Software Development to work

When Agile crossed the chasm to become mainstream, around 2010, the community grew exponentially therefore:

👉 A – there were not enough Agile pioneers and experienced practitioners to support the learning journey of all the new practitioners and trainers => this led to widespread second/third-hand learning, misinterpretations, misunderstandings, and misrepresentations

👉B – the vast majority of new, inexperienced Agile practitioners struggled to find suitable Agile teams with whom they could learn through practical experience by pairing with seasoned experts. Concurrently, many Agile pioneers were laying the groundwork for training and consulting, exacerbating the problem. Consequently, many individuals learned Agile solely from books, akin to acquiring swimming or cycling skills without hands-on guidance.

👉C – the encouragement for each learning achieved by beginners has been confused as a declaration of mastery, leading to novices (as practitioners, trainers, certification bodies, and large consulting companies) becoming self-declared experts.

All the above possibly led to the loss of the fundamental paradigm shift that makes Agile work making Imposition a common element of most Agile adoptions. Therefore, I find it useful to:

=> 🎉🎉🎉 #1 – Ditch imposition and bring back the lost paradigm shift = INVITATION, empiricism, adaptability, people centricity, collaborative partnership, simplicity …

2nd: Ditching the Agile certification market and thought leaders’ self-promotion

Some of the constitutive elements of Agile Software Development can also be found in the Open Source movement and the Hacker ethic (see also here):
– Community & open collaboration to innovate and improve things for everyone
– Sharing, transparency, freedom & democratisation of knowledge, technology, participation
– The paradigm of abundance

Around 2010 the Agile-related market began to grow, and the values above were left behind in many ways:

👉 a – Some pioneers monetised their expertise (nothing wrong with that) creating an offering of closed, proprietary, commercial solutions that, as such, were missing the peer review, feedback, improvements and wisdom of the whole community. SAFe is a good example of the disasters that followed.

👉 b – The economic exploitation of certifications (the Agile badges market) where learning is an afterthought, has become detrimental to the cause of Agile Software Development. What was intended to be the first baby step in the learning journey became a fake declaration of mastery.  The disgraceful feuds and legal disputes that followed around this business demonstrated greed, lack of integrity and disregard for the fundamental values of Agile and its community.

👉 c – Some pioneers monetised their expertise (nothing wrong with that) focusing on personal branding over participating and contributing to the wider community.

All this paved the way creating a very damaging snowball effect. Solutions grown in such a context are typically made-up solutions without enough proof of success that passed independent third parties’ scrutiny.
Whereas ideas, techniques, and methods that came before, like for example eXtreme Programming’s collaborative tech practices, or ThoughtWorks Inception, have succeded in several cases and led to several evolutions adopted in some of the most innovative, successful, digital companies. These do not come with certifications, “Agile” badges, or detrimental commercial exploitations.
This explains why I find it useful to:

🎉🎉🎉 #2 –  Ditch the certification market, thought leaders’ self-promotion, and go back to the original Hacker Ethic…

3rd: Ditching Magical thinking that, since Agile has become mainstream, replaces the vetting and testing of any new techniques to prove their validity

In the beginning, the practices and ways of thinking of the lightweight methods that converged under the Agile umbrella were so counter-intuitive, paradoxical, and unheard of, that to survive:
– they needed to prove themselves every time with an unquestionable success
– they were adopted by rogue teams shielded by the informal authority of forward-thinking leaders
– or they were tolerated only after all the other ways of doing things had failed.

📆⏳ – Around the ’90s and early 2000, most medium-large size software projects failed (as per anecdotal evidence reported by professionals of the time, and somehow documented by the Standish Group’s Chaos Reports) until the adoption of Agile ways of doing things turned the tide on the failures.
Succeeding where most failed before and having to prove yourself with unquestionable successes were the training ground of the Agile practitioners of the time, their baptism of fire that started their journey toward mastery.

After 2010-2012 when Agile gradually became mainstream and popular, things changed:

👉 Most companies’ leadership wanted a new shiny Agile badge.

👉 Most professionals interested in modern ways of working or wanting to join the new industry trends, wanted a new shiny Agile badge for their CV.

👉 Enthusiastic, novel or inexperienced Agile practitioners and clients new to Agile were flooded with unproven “Agile” recipes that had no real success stories or credible theoretical foundation but magical thinking sold by exploiting the popularity of the “Agile” brand.

This explains why I find it useful to:

🎉🎉🎉 #3 – Ditch Magical thinking in favour of putting all the new practices to the test as it has been for Agile before it became mainstream.

My conclusions and the floor goes to you

I believe there is value in moving beyond the misunderstanding and misinterpretations and the damages caused by the unscrupulous economic exploitation of Agile. I think it necessary to allow modern Agile Software Development to serve the growing needs of a changing context (think of Cloud computing, Remote working and WFH, supply chains in a state of perpetual crisis, AI’s LLMs, etc.)

See also:
– Complexity thinking as a second chance to get right the mindset and paradigm shift of Agile to better help product delivery, the customers and the business:
– Interview
– Book
– Agile Patterns and Practices: Link

Elevate the Agility in your organisation.

See how we can help.
You, your department, your organisation.

Advising, Mentoring, Coaching As A Service