I recently read this post from Oleg Vishnepolsky (whom I don't know) here
A provocative title "Agile does not work" from the CTO of a reputable company... this is catchy and indeed peaked my curiosity to read anecdotes on Agile failure.
Oleg's 4 points on Agile failures are
1) Short-term thinking that results from following short iterations and daily stand-ups
2) Architecture that often times can not be deployed piecemeal
3) Complex infrastructure in production that is supposedly continuously getting deployed over. If you are Facebook, you can afford automation. Can you ?
4) Business expectations that they do not need to give you any requirements and that they can change their mind at any time.
And his only reference (and proof) is this article https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
For those who know me, you can imagine that I was a bit in shock to read this. In fact, in reading the referenced article, I was really really surprise by the emotional aspects of their arguments against Agile. I met a lot of Agile-skpetics in my life and it's always been fascinating to see how emotional they can be admitting that waterfall is wrong but Agile is evil. Many of these detractors unfortunately ever truly experimented with Agile - as in a deep immersion - and tried to make it work in the long run.
Let's debunk Oleg's arguments:
1/ "Short-term thinking that results from following short iterations" Associating short iterations to short term thinking is a fallacy: decomposition of a plan in smaller plans/steps by no means indicates that you don't have a (global) plan. Agile is simply pragmatic: when problems you are trying to solve are "big", you most likely cannot address everything at once and be deterministic in your options. This is the first fundamental distinction with Waterfall which is really based on a naive thinking: Waterfall assumes that by thinking deeply about a problem you will be able to provide a sound multi-month plan to solve it and all will go well. Agile offers this touch of realism that nothing ever goes as planned and you should re-assess your global plan frequently at the end/beginning of earch iteration. Agile gives you the opportunity to keep options as open as possible for as long as possible to help you face uncertainty (and this statement deserves a whole book in itself, but I'm going off topic here).
2/ "Architecture that often times can not be deployed piecemeal" Let's be a bit sarcastic here: if you cannot deploy your system piecemeal in an iteration or at the end of an iteration, then you have a fundamental architectural issue - time to hire a new architect! Joke apart, I think we - engineers - have to be honest: if things are complicated, it's our fault. Nowadays, there should not be one large big entity in a system which hinders its evolution. In a very Agile way, you will tackle this 'beast' bit by bit. Sometimes it is challenging, true. But this is the beauty of Agile, it challenges your creatvity to force you to think long term. First, you shall always think about the impact and relationship of your work with the entire system. It's good that we have daily standups as this helps staying in touch with everything. It's good that we plan, discuss stories as we get others perspective on our work. This continuously forces us to shoot for the simplest & best solution and when we hit a wall, we collectively think through it. Second, you shall always anticipate the future with present actions: harness your development with safeguard/proper testing and test automation. This discipline will drive you to mock and stub other parts of the system. This effort will in turn serve as the reference for specs/implementation. Much better approach than having your Systems engineers write pages of document that are rapidly decaying.
3/ "Complex infrastructure in production that is supposedly continuously getting deployed over. If you are Facebook, you can afford automation. Can you ?"
Nothing is indeed perfect but it is certainly a good goal to set, the one of achieving perfection. Agile favors the creation of constant improvements. What's in this to blame? Well, Agile detractors use fallacy like this one to simply say: "look at them, a bunch of utopist". In reality, without this constant strive for improvement, you end up with unmanageable systems, ridiculously expensive engineers that have obsolete skills but remain the only one to know how to touch an environment, and most likely stalled innovation... I have never seen myself a fully truly 100% automated deployment system - at least some human supervision was/is required. But that's ok, the goal is a to automate and automate what can be automated. Net benefit: better control, less human errors and also better definition of future goals. By suffering the present, you can better define your future.
4/ "Business expectations that they do not need to give you any requirements and that they can change their mind at any time."
This is the kind of statement I love. In my opinion I see this as the perfect autarcism software enegineers can create. As if software engineers were in the machine room getting orders from the deck and throwing coal into the fire... Sorry, but software engineers have to be team players. They have to understand the business they are in. As a team, group, department, company we collectively want to be better: better products, more revenue, better profitability. If engineers are here to be dumped dumb requirements, then it's not Agile to blame but the CEO and all management staff.
Everyone has a role, from the support guy to the sales rep and it is legitimately assumed that everyone wants to excel to the benefit of the company. Agile is here to set the stage for all to contribute. And we all know that 'things' can change. We all know that customers (or end-users) express new needs and give all sorts of feedbacks every day. We all know that competition is alive and will always try to grab land. So why blaming Agile to set a working environment in which it is permitted to change direction quickly?