I know it’s uncool to say so, but sometimes I think that Agile isn’t all that.
It is entirely possible that I’m not doing it right, but that is the case with a lot of companies that have adopted the Agile methodology, and even spent money training large teams. The problem is when not correctly understood, Agile wisdom is more of a burden than help. On top of that, there is a tendency to enforce rigid practices without questioning if these drive value or have relevance for a particular team.
For the record, the 12 Principles behind the Agile Manifesto highlight important ways of working. The keys to an Agile team are collaboration, openness and flexibility. The focus is on quality and customer needs. Empowering teams is crucial. I completely agree with that! 👪
So what’s the problem?
Most organisations get overwhelmed by setting strict Agile ceremonies where followers know that it’s sacrilege to suggest any flaws. ‘Should We Change The Agile Manifesto?’ from Forbes agrees.
There’s an entire industry and professions built on teaching Agile — creating a backlog, sprint planning, daily stand up, sprint retro, user stories and acceptance criteria.
What I find frustrating is that there is a certain cultish, blind following which is a driving force behind the popularity of the method. Often people are absorbed into going along without question.
Do these practices benefit the team, product quality, and customer?
A lot of times the answer will be yes, that this process does work. The problem is that sometimes we don’t try to improve or set the structure for our own team because it’s “not doing it right.”
Teams struggle to estimate stories, and then debate on how many fit into an arbitrary amount of time called a sprint. There are companies dedicated to training teams on exactly how to run these meetings, but inevitably still end up with the same guesses. It takes roughly 5 sprints working with the same team to be able to accurately measure velocity.
Occasionally, Agile is used as an excuse for not writing documentation; the purpose should be less documentation that people don’t read, and a greater understanding from team members on tasks and the definition of done. During a sprint, addressing technical debt rarely fits into or is prioritised over a new feature. This is a difficult area to tread with clients, and can be harder to set their expectations.
I remember a number of years ago when I first started to learn about Agile, and how I felt confused by the lingo and the rules. It turns out, these words are used to describe some pretty basic stuff, but with intensity and terminology that can be a bit overwhelming.
I’m not advocating the waterfall method or defending another way as a better approach. If a project is defined top down by executives, and developers are left feeling like their only job is the grunt work, this is dysfunctional. There is little satisfaction or motivation to do the best work when all the decisions have already been made.
If I can get releases out faster, plus validation from stakeholders and input from users, then great! 🙋
