Actually, Agile isn’t that great sometimes

20 Sept. 2018 | Allison Snow | METHODOLOGY

Back ArrowCreated with Sketch.

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! 🙋

That being said, can I accept where Agile does or does not work?

Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a “big bang” launch, an Agile team delivers work in small, but consumable, increments. — Atlassian

At any time, the project can be rewritten and goal post shifted. Sometimes continuous iteration feels like nothing gets done, except a lot of talking, and there is no stable path to completion. Agile has never give me “fewer headaches” as suggested. In fact with all this embracing chaos, it’s often difficult to align with clients around what will be achieved and delivered.

I’ve found that client happiness is a big factor that impacts the whole team, so it’s not something that should be put aside. Client’s expect delivery of a certain thing with a set price on X date. It’s quite hard to manage if this isn’t agreed to before starting. I realise this is different outside of agencies where teams are less restrained by time and budgets.

If anyone out there is working at a magical place with endless time and money, please let me know. 💰

How do we improve overlooked flaws to find balance?

This is different for every team. If I look at the basic principles of Agile, there are some really great guidelines. If something isn’t working, it’s important to question and find a balance so it doesn’t become a burden. There’s no reason to blindly adopt something just because Agile is trendy.

I find Agile most useful for the mindset. It’s about values and behaviour, and organisational culture. It’s about communication, respect, including stakeholders — and users. It focuses on steady workflow, breaking down tasks and having a clear system for managing these, and defining criteria for when tasks are done. It lets teams experiment and make improvements in incremental ways that can brings things to market faster.

The goal of any process should focus on making work more predictable, and driving value for the team, customers and company.

Follow us

Are you interested in working with us?

Whether you have a clearly defined brief or you're not sure wherein the problem lies; drop us an email, or give us a ring for a chat about where you are at and how we might be able to help you.

03 9005 0055