The reasons to go agile with a little 'a'
Last updated: June 2024
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 lowercase. 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.
But this is not another Agile takedown post. I bet you have read plenty including some intro posts that we 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 organizational 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 the 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 organization. But that does not mean that you should not focus on the "how" — this is clearly important too. Because the essence of agile with a little "a" is all about efficiency, responsiveness, and delivering better customer experiences.
The true spirit of agile is about delivering real value — you must be passionate about knowing and serving the customer.
You do not have to be a product 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 maximize the value you can create for customers and the business.
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 customers, you need excellent collaboration between marketing, sales, product management, engineering, and customer support. This entails communicating regularly about plans and trusting your colleagues to contribute their best work. And you treat your customers as equals in the product development process — collecting user feedback and iterating as your understanding of customer needs evolves.
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 Product Experience (CPE). You also regularly reflect on how to improve workflows and streamline processes, so you can deliver even more value to customers.
Data-driven
How do you measure product performance? Shipped features, user engagement, customer churn — these can all be illuminating data points. But you also need to weigh these sorts of metrics against the qualitative data and customer feedback. This helps you root your decisions in the broader context of what is going on so you determine what to prioritize next.
Flexible
Product plans keep everyone focused on what matters most. But you must also be willing to adapt. Agile teams regularly evaluate the product roadmap to make sure it still reflects what customers need. Customers and business needs change over time — serving both takes constant learning.
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. And because your teammates trust you to be candid, you all feel empowered to build a better product.
Productive
Timeboxing 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 to customers — 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 product vision. You constantly return to your north star — the company and product strategy. Any adjustments you make to your product 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 company leaders are telling you to "go agile," you have the power to influence what that will actually look like. Some product and engineering teams rely on frameworks such as scrum or kanban, others adopt a hybrid "wagile" (waterfall + agile) or scrumban approach, and others create their own methods. 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. Because ultimately you have to define what agile means for you — regardless of the methodology you follow.
Plan today what you will achieve tomorrow. Aha! Roadmaps can help.
Related:
