Many companies and teams have lost sight of what being agile is all about. It has become a taboo not to mention "Agile" in job postings, onboarding and team lingo. Work, on the other hand, has remained as rigid as ever. Preaching one thing and doing the opposite has created the perfect environment for keeping employees confused, questioning and underperforming.
The following is a list of anecdotes that illustrate this situation.
We discuss the process 10 hours a week
Being agile extends to the process and keeps refining it based on the team’s needs. In reality, the process is used as a panacea for the team’s dysfunctioning. Everyone is encouraged to blame it on the process (or its loose application) when things go wrong. When teams underperform, it can only mean they haven’t been “Agile” enough.
Our daily standup HAS to take place at 9 am
Few things are more rigid than ceremonies that have to happen at specific times or intervals. Forcing everyone to spill out their updates at the same time every day has no advantages. Self-organising teams know how and when to communicate their progress.
We spend weeks crafting our 6-month roadmap
Long roadmaps are the antithesis of agility. Anybody who claims they know the future is either lying, delusional or a combination of both. Being agile is about learning from the past and focusing on the present. For all intents and purposes, the future might never happen. Products get cancelled, markets change and consumers move on. Time spent on roadmaps is time the team hasn’t used to deliver value.
Our estimations are on point. That’s what management says
Agile teams are endowed with the magical ability of accurately estimating their work. They intuitively eliminate all uncertainty and spit out cookie-cutter solutions. This in turns keeps management happy as they see numbers and charts flashed in presentations. Meanwhile, developer sanity and user needs are crying in the corner.
We take feedback seriously… when it doesn't interfere with our roadmap
The six-month manifesto roadmap is infallible. The great minds that crafted it know better. User feedback is left to rot in a spreadsheet away from the team’s reach. After all, the developers are tasked with the important work: Moving tickets to “Done”. Users can wait; the priority is for the burndown chart to hit 0.
We like to experiment… with our retrospective format
Keeping up with the never-ending discussions about the process, the team is sold the illusion they are free to self-organise. They are encouraged to try different formats for their ceremonies, in line with what blog post the CTO has recently read. Experimentation with the product and development is frowned upon and discarded. The mythical next quarter is apparently the best time for that.
We react to change… in our checkbox and radio button components
Developers are asked to write code day in, day out. They don’t need to speak up, understand the product or interact with the user. They are intentionally kept in a state of blissful ignorance. Many are led to believe it is in their best interest not to be interrupted all day long. In the meantime, a bunch of know-betters are delivering their godly revelations to the team.
We believe in continuous delivery… when our CI/CD pipeline is not down
Budget-conscious managers are very picky. They can't stop preaching the importance of reducing costs. They cut down external services and, sometimes, replace them with subpar internal tools. At the same time, they don’t hesitate to hire tens of new developers to “move faster”. The typical victims are tools considered non-critical. Why invest in a CI/CD pipeline when developers can do that manually? Automation only makes sense when setting up Slack reminders for the daily standup meeting.
We move fast... to keep our Jira board up to date
Soon enough, the "Agile" mindset turns into an obsessive disorder. The artefacts and ceremonies become the holy grail that must be protected and revered at any cost. God forbid the backlog doesn’t reflect the current status of development. God forbid a user story finds itself in the wrong column. God forbid someone questions the utility of that.
We don't deploy on Fridays... or any weekday for that matter
How to give developers the impression you care about their wellbeing? Forbid deployments on Fridays. What’s better than enjoying the weekend undisturbed by emergencies? In reality, it is a testament to how little faith managers have in the release strategies and pipelines. Pushing value to the user should happen all the time. The team’s mission is to make that a reality.