The goal of retrospectives (an Agile ceremony) is *improvement*. If no one on the team needs to improve the way their work works, then their retrospectives are BOUND to be totally lame (and a pointless waste of everyone’s time).
I’ve never seen a team with the motivation / need to improve (out of hundreds of teams). Hence, I’ve never seen a retrospective provide any value.
Maybe one day…
The Agile-technical industry complex can indeed be likened to a house of cards, precariously balanced yet vulnerable to the slightest disturbance. Agile, the software development model touted for its adaptability and focus on incremental, customer-centric progress, is often lauded as the ideal approach. However, the complete absence of any scientific or theoretical underpinning for Agile is a glaring shortcoming. And one that nobody wants to talk about.
Its practices and methodologies are founded on heuristics and anecdotal experiences rather than robust empirical data or time-tested theories.
Moreover, Agile’s supposed benefits, such as enhanced productivity, increased customer satisfaction, and expedited delivery, largely rest on unverified claims. There is an alarming dearth of rigorous, peer-reviewed studies that confirm these benefits definitively.
Furthermore, Agile’s emphasis on adaptability and quick response to change, although seemingly beneficial, can lead to volatile project scopes, ever-shifting deadlines, and mounting technical debt. These factors can undermine the stability and predictability crucial to the success of a project.
In essence, the Agile paradigm, despite its current dominance, appears to be an edifice built on sand. Its fundamental principles lack rigorous theoretical grounding, and its touted advantages are not substantiated by empirical evidence. Like a house of cards, it seems Agile may be one disruptive breeze away from collapsing, and its dominance in the tech industry is more a result of hype, ignorance and trend-following rather than any solid, scientific foundations.
I’ve lost count of all the faddish theories of yesteryear, now thoroughly debunked, yet to which proponents still cleave.
Examples:
• Myers-Briggs (MBTI)
• Growth Mindset
• The Agile software development approach
• Learning Styles
• The 10,000 hour rule
• The Pygmalion effect
• The Hawthorne Effect (?)
• The left brain/right brain myth
• The myth of multitasking being OK
• Neuro-Linguistic Programming (NLP)
• Jim Collins – Good to Great / Build to Last (?)
• The Stanford Prison Experiment (?)
• The Milgram Experiment (?)
• Stockholm Syndrome (?)
• The Cone of Learning / The Learning Pyramid
…and so on.
💡 Prepare to embark on a thrilling exposé, where we unravel the tangled web of Agile’s alluring illusion, and reveal the startling truth lurking beneath its glossy veneer – a revelation that will leave you questioning everything you thought you knew about software development!
➡ You know, there’s an old saying that goes, “You can put lipstick on a pig and call it Agile, but it’s a waste of your time and annoys the pig.” It’s such an apt description of the Agile approach to software development, don’t you think? I mean, people talk about how Agile is the be-all and end-all solution to software development woes, but in reality, it’s just one big lipstick-covered pig.
Even when organisations follow Agile to the letter, it never seems to work out as expected. The whole system is supposed to be about flexibility and adaptability, but so often it just ends up being a convoluted mess. Sure, you have all these meetings, sprints, and stand-ups that give the appearance of progress, but it’s really just a bunch of people running in circles.
And let’s not even get started on the endless stream of buzzwords and jargon that’s constantly thrown around in Agile environments. It’s like some twisted game of corporate Mad Libs that doesn’t actually result in any tangible improvements.
So yeah, you can slap a coat of Agile lipstick on your development pig, but don’t be surprised when it doesn’t magically transform into a streamlined, efficient machine. More often than not, you’ll just end up with a frustrated pig and a whole lot of wasted time.
💡 The Agile community has some kudos for promoting collaboration and its revisionary approach to software development. But lurking beneath the surface lies a hidden crisis stalling progress: the deliberate dismissal of invaluable contributions from its very own members.
➡ While the Agile community has made some notable contributions to software development and project management, it’s important to acknowledge that it isn’t without its flaws. One issue that many people don’t discuss is the intentional act of hiding, erasing, and ignoring contributions made by current and former members. These issues contribute to the stultification of the whole field of software development, hindering its growth and improvement.
Addressing this issue requires understanding the community’s strong focus on collaboration and teamwork. The Agile Manifesto itself emphasises “individuals and interactions over processes and tools,” which, at its core, promotes the importance of people and their relationships. However, in practice, this mindset sometimes leads to an environment where individual contributions are overshadowed by the status quo. This can stifle the innovation and creativity needed for software development to evolve beyond the narrow confines of the Agile approach.
Moreover, a more sinister aspect of this erasure exists. Some prominent figures within the Agile community focus more on maintaining their status and reputation, rather than nurturing a healthy, progressive environment. This behavior leads to the intentional sidelining of members who have made significant contributions, especially if they challenge the status quo or introduce innovative ideas that could potentially outshine the work of established figures. This self-serving attitude has stagnated the Agile approach by suppressing diverse perspectives and fresh ideas.
The Agile community might choose to confront this issue, as it contradicts the very principles it represents. The community might choose to cultivate a more inclusive and transparent environment that recognises and uplifts the contributions of all its members, regardless of their background or standing.
As members of the software development community, we might choose to actively advocate for those whose contributions have been ignored, and support a culture of openness and genuine collaboration. By doing so, we can ensure that the software development community continues to evolve beyond the Agile approach, embraces diverse ideas, and continues to progress in a healthy, positive direction.
Do not go gentle into that good night,
Agile development, we loved thee so,
Yet now thy flame is flickering low,
And all the world grows dimmer in our sight.
Once thou wert young and full of fire,
A new way of working, a bright new dawn,
We dreamed of all the things thou couldst spawn,
And all the ways thou couldst lift us higher.
But now we mourn thy fading grace,
Thy light that once shone bright and bold,
Now flickers weakly, frail and old,
And leaves us lost in this darkened space.
No more the sprints that flew so fast,
No more the stand-ups sharp and bright,
No more the retrospectives to shed light,
On how to improve, how to make it last.
Agile development, we bid thee adieu,
Thou wert a bright star in our sky,
And though now we say our fey goodbye,
We’ll hold onto the lessons we learned from you.
I completely agree with the statement that Scrum Masters are a waste of time and money, and I don’t hesitate to say that we should get rid of them. While the Scrum approach can be somewhat effective when implemented correctly, the role of Scrum Masters often becomes redundant and futile when the culture of the organisation in which they operate is a blocker to progress.
Scrum Masters are supposed to facilitate the adoption of Scrum, invite the removal of impediments, and improve the overall effectiveness of the team. However, in most cases, the company culture and policies are too rigid to allow the Scrum Master to operate effectively. This results in the Scrum Master being unable to drive change, improve the team’s performance, or add any significant value.
Furthermore, the cost of hiring a Scrum Master can be exorbitant, and it is an unnecessary expense when a team can adopt the Scrum methodology on their own. Smart team members can learn the Scrum framework and apply it to their projects, without the need for a dedicated Scrum Master.
In conclusion, Scrum Masters are a waste of time and money if the culture or organisation in which they operate is not receptive to change (which is most organisations). Therefore, I strongly advocate for companies to evaluate their need for a Scrum Master based on their willingness to change their culture, and thus their ability to adopt and implement Scrum effectively, rather than blindly hiring one because it is the norm.
Certifications can be seen as a quick fix for professional success. They offer a way for experts to show off their skills and knowledge in a particular area. However, the dark side of certifications is that they are often surface-level and bear no relation to an individual’s capabilities.
One of the most outrageous examples of this is with Agile and Scrum certifications. Many courses will certify you after just a few days of training, which is simply not enough time to truly grasp the intricacies of these methodologies. Scrum, in particular, demands a deep comprehension of team dynamics, communication, and the capability to adapt to change. These abilities can’t be acquired in a two-day course or even in two weeks, two months, or two years.
The problem is exacerbated by the patent naivety of busy managers who believe that certification is equivalent to competence. They see a certificate on a CV and assume that the individual has a profound understanding of the subject matter. This assumption is utterly false and can lead to expensive mistakes and project failures.
The complete inadequacy of classroom learning is also a significant issue. While there is value in conventional learning, it’s entirely insufficient to prepare individuals for the difficulties of the real world. Classroom learning typically focuses on theory, while real-world circumstances are way more complex and require a more profound understanding of the subject matter, especially in matters like organisational culture and interpersonal relationships.
In conclusion, certifications are essentially worthless at best and deeply harmful at worst. They create a false sense of security and don’t genuinely measure an individual’s abilities. It’s crucial to remember that certifications are in no way a substitute for experience and extensive knowledge.
Write a polemic on how the Agile community has failed to assist upper management in making the cognitive shifts necessary for effective adoption of the Agile approach to software development, and to business success more generally.
The Agile community has failed upper management. It has failed to assist them in making the necessary cognitive shifts to effectively adopt the Agile approach to software development and, more generally, to achieve business success.
Upper management is often resistant to change, and the Agile community has not done enough to help them understand the benefits of the Agile approach. Instead, the Agile community has focused on teaching technical practices and methodologies, neglecting the psychological and cultural shifts that must take place for Agile to be successful.
The Agile community has also failed to adequately communicate the value of Agile to upper management. Many executives see Agile as a fad or a set of buzzwords, and the Agile community has not done enough to demonstrate the tangible benefits of Agile in terms that upper management can understand and appreciate.
Furthermore, the Agile community has not done enough to address the concerns of upper management. Many executives are hesitant to adopt Agile because they fear it will disrupt their existing processes and power structures. The Agile community has not done enough to assuage these fears and show upper management how Agile can be integrated into their organisations in a way that is smooth and beneficial.
In short, the Agile community has failed to assist upper management in making the necessary cognitive shifts to effectively adopt the Agile approach. It is time for the Agile community to refocus its efforts on helping upper management understand and embrace the benefits of Agile, and to address their concerns and resistance to change. Only then will the Agile approach be able to truly fulfill its potential and bring success to the organisations that adopt it.
| Me: “Write, in the style of Christopher Hitchens, a scathing critique of Agile software development as a religious phenomenon.”
ChatGPT: “Agile software development is nothing more than a religious phenomenon, a cult-like devotion to a set of vague and arbitrary principles that are masqueraded as a rational approach to software development.” “The so-called Agile manifesto is a hodgepodge of buzzwords and platitudes that has little connection to the realities of software development. It elevates nebulous concepts like “agility” and “adaptability” over the hard work of actually building software. It is a gospel of buzzwords, a collection of empty phrases that are repeated ad nauseam by its disciples without any real understanding of what they mean.” “The Agile movement is dominated by a priesthood of gurus and experts who claim to have a monopoly on the truth. They demand unquestioning obedience to their edicts, and dismiss anyone who dares to question their authority. They demand that software developers become “agile” without ever defining what that means, and punish those who do not conform to their rigid and arbitrary rules.” “The Agile movement is a religion of the status quo. It is a refuge for the lazy and the mediocre, who seek to avoid accountability for their lack of productivity by hiding behind the cloak of Agile principles. It is a crutch for those who are afraid to challenge their own assumptions and biases, and who seek to avoid the hard work of critical thinking and problem solving.” “In short, Agile software development is a sham, a pseudoscientific fantasy that has no basis in reality. It is a religious movement that is more concerned with maintaining its own power and influence than with actually producing useful software. It is a fraud, a scam, and a waste of time and resources. It should be rejected and denounced by anyone who cares about software development.” |
When both customers (executives, senior managers) and users (developers) reject the Agile development approach, it’s time to find something more effective. It’s only taken 20 years for folks to wise up, after all.
How many folks in the Agile community are at all interested in learning? From my experience: next to none.
There is helpful and useful content out there. But finding it amongst all the dross is a massive challenge.
I despair of the boatloads of naive advice, misinformation, and just pure tosh that so-called “Agile” people spout on a daily basis. (Not limited to just “Agile” people, of course.)
Caveat lector!
And just in case you’d like a sanity check on anything suspect or dubious, I’m always happy to support your natural scepticism. Just get in touch for non-partisan help.
Agile is now the rigid and turgid status quo. Ironic, much?
In case you missed it:
[Tl;Dr: Successful Agile is fundamentally incompatible with “management”. And even when successful (rare), is not worth having.]
I suggest “Agile Management” is one of the world’s greatest oxymorons.
I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem.
~
So many people ploughing so much effort into Agile methods and practices, so little positive results obtained.
The risk/reward ratio (often illustrated as a curve) marks the prospective reward an investor can earn for every dollar, pound or yen they risk on an investment. Many investors use risk/reward ratios to compare the anticipated returns from an investment with the amount of risk they must undertake to earn these returns.
Adopting an Agile development approach is a kind of investment decision, much like any other investment decision. NB. Not all the investment is financial/monetary in nature, and neither are all the anticipated returns.
Investors have long understood the necessity of combining the risk-reward ratio with the “winning rate” to know whether a given investment decision or strategy will prove a winner.
Agile adoptions have a remarkably low “winning rate”. Something like 75-90% of all attempted Agile adoptions fail.
It sure beats me why so many decision-makers fail to investigate (and thereby, understand) the risks and winning rates of Agile adoptions. Especially as the rewards accruing from adopting an Agile software development approach are so limited (read: minimal, or negative).
Is your organisation contemplating adopting Agile? Has it done its homework?
– Bob
In case you missed it: Why Does Agile Fail?
Think Different 