Principles over Process - Getting “Agile” Right

As we head into 2024, it dawned on me how in just ten years time “agile” went from the greatest thing since sliced bread, to an almost dirty word that has become so toxic in many organizations that the word itself has become the new “Voldemort.”

It’s also pretty clear how we got here; let’s take a moment to reflect on that.

Over the past 20 years, digital solutions, namely software, have become so integral to our businesses that the two are virtually indistinguishable today. Software is how we reach our customers, it’s how they transact with us, it’s how we develop the products we sell, and it’s how we fulfill them in both the digital-only world, and increasingly, the physical one as well, from games and media, to groceries and vacations.

Over the same period, what started as “IT,” a small service arm of the company, grew exponentially into the strategic center of the business today. As that importance grew, and as more people came together to craft mission critical software products, the ways of working needed to evolve. Agile grew out of this evolution, recognizing the many problems that existed in the disconnected hard-hand-off driven IT service model, and proposed a more cross-functional empowered model with short iterations and critical feedback loops.

What’s important to note here is that agile was never a prescribed process, rather a set of principles that defined the culture in which an organization should operate (knowing full well that each organization’s nuances would require a personalized implementation). What’s happened, however, is that over the past decade, process-driven professionals have hijacked agile, developing rigid frameworks and systems that appeal massively to command and control led organizations. The irony is that these top-down rigid systems are the complete antithesis of what agile actually stands for - bottom-up empowerment and truth seeking through customer feedback.

So today we find ourselves in the middle of a battle of two opposing leadership philosophies, that of traditional top-down command and control, and bottoms up empowering the person closest to the problem to solve it. And both sides think they’re practicing Agile. It’s no wonder people are confused by the word, and why its true meaning feels so lost.

I still believe in Agile, and I’m not ready to throw away the word, because the principles that underpin it are so central to great product leadership, in my humble opinion.

10 years ago, working with a few colleagues and a close mentor, I developed a list of “product values” that I’ve carried with me through all my product leadership roles, and shared consistently with my teams and my organizations to infuse a specific set of cultural values that lead to Agile ways of working. I want to share those values here with the broader community with the hope that? they lead to reflection, to conversation, and might even inspire some to act to better embrace what Agile is truly about (even if their path so far has been murky).

Principle #1: Customers Come First

Agile teams always put their customers first. They take time to study their customers, observe them, talk to them, deeply understand their problems (empathy). It’s not just the researcher’s job, or designer’s job, or the Product Manager’s job, it’s every member of the team doing this important work together. The team proposes hypotheses about what a better future might look like for the end user, and then they work backward to determine the technology that may be required to achieve the vision.

Principle #2: Take Smart Risks

Agile teams aren’t afraid to move fast, to design iteratively, and to run experiments. They do this repeatedly, at small scale first, in order to test those hypotheses about what might solve their customers’ greatest problems, and deliver value. They don’t get caught up in analysis paralysis, they test and learn, and then they fail or scale an idea.

Principle #3: Design is Everything

Where others often dismiss the value of design, agile teams embrace it. And I’m not talking about the designer per se, but the design process, which is fundamentally about solving problems elegantly. The simpler software looks, the harder it is to build. Few organizations grasp this reality, and it takes great mastery of design to achieve simplicity, which means doing the hard work behind the scenes, in software, rather than putting it all on the customer.

Principle #4: We Are One Team

Agile teams require multiple disciplines to come together all day, every day as one team. Product Managers, Designers, Engineers, QA, and increasingly, Data Scientists. They sit together, they eat together, they build a profound respect for each other’s craft and what makes each other’s jobs difficult. Great agile teams empower the person closest to the problem to solve it. That line, which I repeat in this article several times, is my personal, one sentence definition of “Agile.”

Principle #5: We Celebrate Growth

A growth mindset enables Agile teams to get progressively better over time. They openly and freely discuss mistakes and failures (without judgment) so that they can learn faster, from one another. They celebrate the accomplishments and achievements too, both big and small.

Principle #6: Great Software is Never Done

This principle, more than any other, is the one that I believe separates great organizations from average ones. As I started this article I said that software is indistinguishable from the business, and I truly mean that — today, they’re one in the same. And just as we wouldn’t ask “when are we done with the business?” (it’s a silly thing to say, right?) we should never ask the same about our software, yet so many organizations do. Great agile teams who truly own their platforms and products are relentless when it comes to furthering their knowledge of their customer and using data and insight to continuously improve and evolve the software, and in doing so, drive long term value creation for the entire business.

Embracing these values is the first step toward becoming Agile. After that, it’s not about picking a framework or setting up a tool to prescribe a set of steps and ceremonies… the more important thing to do is to organize your people into small, inter-disciplinary teams that are responsible for the success (or failure) of a platform or product. Ownership is key. Ownership inspires empowerment. And empowerment drives the agile cycle forward. As a leader, it’s now your job to establish outcome oriented goals that align to a vision, ensure feedback loops are in place, clear blockers and obstacles to forward progress, and most importantly, live and breathe these agile values and principles - culture starts with you.

And maybe you’ve had a bad start with Agile. Maybe it’s become a bad word in your company. Don’t give up. The most Agile thing to do in that situation is to reflect on what went wrong, diagnose it, talk about it as a team, and lay out some hypotheses about how to change the situation. Then, focus on the principles. Be a broken record when it comes to championing them. Allow Agile teams the space to explore processes that work for them and which are still true to the principles. For some folks, a kanban board fits their personality and style, and that’s great. For others, a more structured scrum-like approach may be right. Let them experiment here. Promote the adoption of systems and tools that reduce interdependencies among Agile teams, so that teams can move faster, and things like releases become low-risk events.

Remember, above all, Agile is about culture — and culture change isn’t quick. Stick with it, embrace the principles, not the process, and you’ll be amazed what empowered teams can do to deliver value.