#Agile And The Concorde

Someone sent me this article about it being the End of Agile with a note of “FFT” the other day and once I realized that’s an acronym for “food for thought” and bemoaned the irony of needing an acronym for the respective activity I gave it a look and at first it got my blood boiling as expected.

Read it if you can. How you feel as you do may give you a good hint about where you stand on the issue anyhow. 

To me, once I cooled off, it made me think and that’s always welcomed. Not only about whether or not the author was right but about the author in general - their journey, their stance and their level of “getting it”. I’ll cut the suspense, there isn’t much on the latter in my opinion. While they are obviously very experienced in the practice and very knowledgeable of technology, to make a sweeping generalisation at the end of the article where he excuses the fact that he’s equaled Agile with Scrum by saying “all big enterprise basically do that” just means he’s only been privy to a certain set of interactions and shakes the entire premise. It also confirms that while the description of Scrum pitfalls may be accurate they have little to say in the argument for or against Agile as a whole.

With all that said and after the blood cooled off, two elements did give me the proverbial food for thought. 

For one thing, in support of another argument, somewhere, in the beginning, the author says something about the fact that developers become disengaged and there’s routine and lack of real investment setting in with longer projects. The implication seems to be that in time, once they have stopped designing together they will essentially be less performant.

Why does design stop though? To me, this is an attitude issue from the same bag as “EDS/ scaling/ academical/X projects have no customers”. Granted, the initially discussed MVP may have been mapped out but if teams have a constant feedback loop with their customers, (that indubitably always exists if they don’t you’re collectively doing something fundamentally wrong not to have searched for them), then why shouldn’t there be a continuous need for re-design and design iterations?

Furthermore, if we accept developers need the thrill of the creativity involved in the design process why won’t we encourage them to apply design thinking to architectural or technology problems as well?

This is not exhaustive, I’d like to think more of this, read more and ask more Agile people in Software Development as it’s really interesting. As a self-proclaimed Techies Anthropologist and groupie, I’ve always been fascinated by instances when they are finally glimpsed upon as real humans by the business and not this ineffable resource of extreme intelligence that delivers code. “Eventually!”. 

Secondly, and in a way even more interesting, there is a section explaining why in the author’s opinion Agile won’t scale as its many dependencies are not taken into account. One of the dependencies which it deplores not having been explored is the “organizational dependencies” and judging by everything else the author is likely referring to human resources, not the actual organization as a group entity but nonetheless, this one rings true. 

If Agile doesn’t work it’s an organizational issue. If Agile doesn’t scale, it’s an organizational issue. But beyond having both the above be healed by everybody at every level of the organization “getting it” and truly changing their mindset, the effects of non-Agile cultures on attempting to be successful fast at rolling it out, are far from clear. 

Most Agile strategists and own-framework-makers acknowledge the need for the organization to change, to welcome -or at least accommodate- self-contained islands of autonomy and efficiency but little is being investigated regarding how that works in practice on that respective organizations’ various political and structural wounds and warts. 

If the culture is largely SSSS (sick, stuck in the past, slow and sequential) what chance do mini components of awesomeness have to succeed?

This is a big deal and it needs a serious dialogue devoid of generalized impression management and fear and it will make the difference between the author’s title being correct or not. 

What’s more, is that while he is essentially wrong on his premise and potentially not in possession of an #Agile mindset himself, if he were to be right and Agile magically be on its way to becoming confined to the same monstrous human set-backs where the Concorde went, then it would have still forever changed the ones who had gotten it and, fast forward a few years the magic of non-sequential thinking will have spread like a benevolent virus to where one day, in a dictatorially mandated waterfall planning session, people will look around and know that their team is also breaking it all into mental tickets and cards.

Agile is not a project management methodology. Agile is not a process. Agile is not even a way of work. Agile is a way of thinking and because it is, all the Scrum masters in the world, all the examples of sick organizations that failed in the world and all the hockey sticks in the world won’t manage to push it into the same hangar where the Concorde lays.