|There seems to be a growing trend amongst certain quarters to criticise businesses for the manner in which they have adopted Agile. These criticisms seem to be from Agile purists who have taken umbrage as the businesses in question have not precisely followed the ideals as laid out in the Agile Manifesto[^]. I've read several articles that have been critical of the way that a particular business has adopted Agile.
"That's not how you do Agile"
"That's not following the Agile Manifesto"
"You can't say you are an Agile shop unless you follow Agile to the letter"
I am not and have never been a purist of any particular methodology, including Agile. Every business is different, with different processes, skills and people. Whilst there are clearly certain ways to do Agile wrong (such as following a process that more resembles the waterfall), there are many ways to do it right.
For the record, I have worked in an Agile software team and found it extremely beneficial and highly productive, so this is in no way an attack on Agile. When used appropriately, Agile can bring huge benefits to a team.
Do these same Agile purists rigidly follow the SOLID principles when writing their code? Do they slavishly follow TDD and have 100% test coverage across their code? The answer is (almost certainly) no, of course they don't. Purism only has a place in academic text books. In the real world, pragmatism comes into play. The gulf between theory and practice can often be very wide.
Agile is not a prescriptive, deterministic process. It is a set of ideals that can be tailored in ways that are appropriate to the business. So what if your daily scrum is around a table with everyone seated, instead of around a Kanban and standing up. These are details. It doesn't matter. The key points are that you are building software in a way that is responsive to change and with key stakeholders involved from the business. It's important that you have fostered closer relationships with your customers who have greater input into the project. It's important that your team is evolving into a self organising team capable of taking responsibility for what it does.
There is no room for such pedantry in the modern business. It's hard enough just getting product out the door, without also having to ensure you haven't fallen foul of any of the ideals laid out by your methodology of choice.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare