Agile is my shield - my latest observation of Bad Agile...
Bad practices are usually not rooted in the philosophical roots of a framework or ideal, but instead in the implementation.
There is not much better example than poorly implemented Agile - or - Bad Agile
I tend to do a lot of networking with executive-level folks - I am a consultant, it is how we find new clients and how we stay in touch with what is happening in our little piece of the world.
When the topic turns to Agile, over the past few years, it has become a sore subject, one story of bad Agile after another.
I get the “yes, well, we did that transformation a few years back, not sure what we got out of it, but it is done and we have moved on.”
Or, something like, “we have been through so many transformations”; “clearly none of them stick. I am not even sure Agile is a real thing.”
But lately, a new version of bad Agile has emerged. I observe it as I get in closer, past the executives. I hear this from the directors or the managers, sometimes even the Scrum Master, or the Developer. I am now hearing about Bad Agile from the people who actually get the work done. They do not see it as Bad Agile, they see it as their weapon against the business or executives who would “mess with their world”.
Something along the lines of - “we do not have to [whatever it is being asking for] because that is not Agile”.
An even more perverse version goes something like - “we do not provide the business any estimates because we use kanban”.
I have come to call this “The Agile Shield”. In fact it is not Agile at all, it is a weaponized set of words taken from the Agile Glossary, except, they have taken the words and left the meanings behind.
It tends to form within groups who have been together for a while who like the way they are doing what they do. They are very resistant to change of any kind. They are usually found in a very isolated silo of some business critical (or once critical) app.
The people in these groups tend to put their code above all other things. Well, except maybe their schedule. You will note that Product Owner is not listed as a role I tend to hear this from. These little toxic bad agile silos very rarely will allow any business person to interfere with the code being worked on.
This is bad agile at its worst in my opinion. These are people playing off the ignorance of others and re-writing what Agile is so they can avoid change - or an interruption of their schedule (and I do mean personal schedule, not a business schedule).
These are the bad actors of Agile that are spoiling for those who want to serve the customer. They have decided to only focus on the part of the manifesto that deals with Individuals and they have perverted that to mean only developers.
In the end, this is not something that can be corrected with “more agile training”. All the Certified Scrum-masters in the world could not correct this.
This is a people and culture problem; this is a leadership problem. Start there, look for the business outcome that is being missed and address it at the core.
I suspect that you will find that the teams are formed around code or an app. Software Engineering teams should form like any other team; they should form around the customer. They should be prepared at all times to re-form when the customer changes. If that is correct, then might start by re-aligning your engineering team to the customer.
If not, then dig until you find the core - this little instance of bad agile is toxic, and very contagious. Do not let it infect your entire org.
Agile is meant to serve the customer and respond to change.
Half of the manifesto is about collaborating with the customer and responding to change.
In the end, the Agile Manifesto is very simple, and if what you are doing can not be tied directly to it, then it is not actually Agile at all.