Brian de Haaff* explores the different interpretations and outcomes that can result when a team is ordered to ‘go Agile’ and how it often creates more problems than it solves.
Do you know what a capitonym is? You can probably figure it out if I give you a few examples.
August and august. Turkey and turkey. Mercury and mercury.
If you have not already guessed, these are words that mean different things whether they are capital or lower-case.
You can find plenty of lists of these words online, but there was one capitonym missing from all the lists I saw — Agile and agile.
It is deeply ironic that agile with a big A has in many ways stymied agility and flexibility for teams.
This is not another Agile takedown post. I bet you have read plenty, including some I wrote years ago.
A common thread pokes at Agile purists who take a rigid or dogmatic approach to what should be an inherently adaptive way of working.
Another is corporate leaders who rely too heavily on ‘going agile’ as a fix for deep-rooted organisational problems.
A philosophy based on flexibility has turned into a prescription for the ‘right’ way to work.
To some people, agile has become synonymous with overly complex processes, rigid workflows and bureaucratic bloat.
It is no wonder that many development teams resent executives telling them to be more agile without a real understanding of what they are even requesting.
I have long been vocal that going agile is not a transformation. You cannot just change how you get work done and expect it to fundamentally transform the organisation.
However, that does not mean that you should not focus on the ‘how’ — this is clearly important too.
This is because the essence of agile with a little ‘a’ is all about efficiency, responsiveness, and delivering better client experiences.
You do not have to be a project builder to benefit from taking a more agile approach to your work.
Even many marketing teams now, for example, focus on moving quickly, releasing iteratively, and adapting plans to new feedback and data.
No matter your role, being agile allows you to maximise the value you can create for your organisation.
What does this look like in practice? Here are some of the qualities I see in teams that embody agile with a little ‘a’:
Collaborative
To continually deliver value to your clients, you need excellent collaboration between the various teams working on the overall project.
This entails communicating regularly about plans and trusting your colleagues to contribute their best work.
Curious
Being agile does not mean moving quickly at all costs. You need to explore the ‘why’ before leaping into decision mode.
This means considering the impact of what you are planning and how it affects the Complete Project Experience or CPE.
You also regularly reflect on how to improve workflows and streamline processes so you can deliver even more value to your clients.
Data-driven
Using data to measure project performance helps you root your decisions in the broader context of what is going on so you determine what to prioritise next.
Flexible
Project plans keep everyone focused on what matters most, but you must also be willing to adapt.
Agile teams regularly evaluate the roadmap to make sure it still reflects what clients need.
Proactive
The flip side of responding to change is anticipating what is coming.
You do not wait for scheduled meetings with teammates to bring up potential problems.
Being proactive helps you reduce risk by changing direction before the team wastes additional time and resources.
Because your teammates trust you to be candid, you all feel empowered to build a better project.
Productive
Time-boxing can be useful for increasing output.
Whether or not you call it a sprint, what matters is that you find a sustainable cadence for releasing new functionality to users.
You focus on delivering value frequently, without adhering to a rigid schedule.
Resilient
You break down large efforts into manageable chunks.
This makes it easier to take on complex work, release often, and pivot when necessary.
Part of being resilient is maintaining your long-term project vision.
You constantly return to your North Star — the organisation and the project strategy.
Any adjustments you make to your roadmap are in service of the overall vision.
Agile is a state of mind, not a prescription — ideally it should feel expansive and freeing rather than confining.
If your leaders are telling you to “go agile”, you have the power to influence what that will actually look like.
Every team is different, so you have to carve out a way of working that fits your unique needs.
Experiment with different tools, methods, and frameworks to see how they align with your team’s productivity and happiness. Then take what works and discard the rest.
Ultimately you have to define what agile means for you — regardless of the methodology you follow.
*Brian de Haaff is the Chief Executive of cloud-based software company Aha! He can be contacted on Twitter @bdehaaff.
This article first appeared on the Aha! company website.
