As an agile enthusiast I tried to read it open-minded. Maybe there is something I can learn from? Something which helps me to improve? It sadly turned out to be an advertising blogpost for Henry Latham’s book… and one of the strangest things I’ve ever read about „Agile“. In his defence… probably he only checked out „Dark Scrum“-implementations which gave him this impression.
The conclusion of Henry’s blogpost – and I try a summary here – was: Agile product development sucks. It’s only about delivering faster and therefore focusing only on low-impact features. People get stressed because they need to deliver fast(er) and people are only trying to get more points on the board done. I’m guessing, the article refered to Scrum but hey, there are also other methods and methodologies out there!
Startups fail because of Agile methodology?
Henry stated that 90% of the startups fail… and for probably 60 – 70 % it is because they are using Agile. An interesting thought and it would be interesting to know the sources of these figures. My gut feeling says, that the 60 – 70% are gut feeling themselves 😉
Check the principles behind the Agile Manifesto!
What really mattered to me was how the author understood the Agile Manifesto. Reading his blogpost I was wondering if he has ever tried to find out what Agile really is about.
Sorry Henry, but there are also powerful Agile Principles behind the manifesto… and that is where the magic starts! If Agile is as you decribed it, then the ones „doing it“ are definitely not agile…. they probably „do“ agile but they are not agile. They never can be.
And yet, despite this fact, everyone simply continues using this model — a model that objectively dramatically reduces their chance of success — without questioning it.
The basis for business agility is transparency, inspect and adapt. Simply following a model without thinking is definitely NOT agile.
Yet what that means in practice is a whole lot of low-impact busywork.
I would like to answer with the principle #1 and #8: „Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“. Read it twice… VALUEABLE is the keyword in there which can definitely not be fulfilled with low-impact busywork.
„Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.“ Indefinite constant pace… still… no place for low-impact busywork.
Agile focuses on efficiency, not on impact.
Wow… principle #1 will hopefully clarify this as well!
We become stressed, we sleep less, we think less, and busy ourselves with inconsequential tasks as we relentlessly strive to just get more points on the board — to get more done .
That is a tough one. First of all, let me again refer to Agile Principle #8 (indefinite contstant pace… you remember?) as well as principle # 10 which is „Simplicity – the art of maximizing the amount of work not done – is essential.“
One where you build a stream of low-impact features that may be built quickly, but never help you build a simple, high-value product for your customers.
It’s the job of a product manager, product owner or similar roles to exactly focus on the high-value product… otherwise they would’ve understood their job completely wrong. Oh yes, and by the way… there was Agile Principle #1 😉
More effective collaboration towards a common goal.
Imho this is about effectivity as well as about proper communication. I would like to answer with the Agile Principle #4, #6 and #12: „Business people and developers must work together daily throughout the project.“, „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation“ and „At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.“
During the past couple of months I had the opportunity to do a deep-dive into the principles behind the Agile Manifesto. Yes, I knew them beforehand for quite a long time but really focusing on the single words is something I never did. I really recommend everyone who „thinks about Agile“ and „doing Agile“ to have a close look at the 12 principles as well. Feel free to download them <here
Related to Henry’s blogpost I recommend working with people who understood what Agile is about. To answer the question in the headline of this blogpost: No, Agile does not do harm! It’s simply not about using some methods and frameworks. It’s about understanding the principles behind and working every day to become better.