Are You "Doing" Agile or "Becoming" Agile? Source

Translated

As Agile continues to gain traction and application, it has emerged as the most effective methodology at the team level, with more and more software and IT teams adopting Agile practices. However, the question remains: are you truly Agile in your approach?

Since the influential group of software practitioners gathered and released the Agile Manifesto 23 years ago, Agile development practices have gradually become indispensable management methodologies across various enterprises. Today, Agile is not just a tool for software development teams; it has become a guiding principle built upon transformational initiatives, steering organizations toward agility.

Over the past two decades, learning and implementing Agile practices have become commonplace in modern software-driven organizations. However, for software leaders, the key question remains: how do you steer your team away from merely going through the motions of Agile rituals and truly "becoming Agile"?

For leaders, Agile serves as guiding principles based on transformational initiatives. Although learning and implementing Agile methods have become routine in modern software-driven organizations over the past twenty years, it's crucial for software leaders to ponder how to make their teams truly Agile rather than simply adhering to prescribed Agile rituals.

Implementing Agile does not equate to being Agile

"Agile is an attitude, not a set of bounded techniques," wrote Alistair Cockburn, one of the co-authors of the Agile Manifesto.

While the manifesto's primary principle emphasizes " individuals and interactions over processes and tools," many tools that purportedly facilitate Agile have essentially become substitutes for the process itself. For example, some teams, under the guise of "implementing Agile," engage in overcrowded stand-up meetings involving dozens of team members, making it impossible for everyone to grasp the collaboration dynamics within the team. Overly large teams and extended sprint planning only increase pressure within the team, leading to communication difficulties among members. Agile tools like burn-down charts, intended to monitor progress and pressure, end up "burning down" the team's tools. Therefore, implementing Agile does not necessarily make a team truly Agile because Agile is more than just a work methodology or technique—it's about fostering a team mindset and culture.

Image Source: ZenTao Blog

The Three Guiding Principles of "Agile"

Agile is more about collective thinking and team culture than discrete process support. Many Agile-driven projects lack the ability to mechanically go through the motions without understanding and actively applying the true spirit of Agile.

Based on the experiences of various Agile teams, we have summarized the following three principles to help teams better implement Agile.

Principle 1: Continuously manage business objectives rather than tasks

Ask yourself why the enterprise cares about a particular issue. While this may seem like a fundamental and straightforward question, we encourage managers to continually challenge their teams to answer every feature request and user story. Although this may seem a bit excessive, posing this question throughout the development lifecycle helps teams develop a habit of reinforcing the ultimate goal of the process itself, facilitating coordination between the team and external stakeholders.

For example, we frequently collaborate with clients to help them modernize their technology stacks, migrate applications to container orchestration or cloud-native platforms. While this may seem like a goal, it's actually an implementation detail, not a business outcome we can measure or track. It's essential to understand that tools or technologies serve business goals.

Principle 2: Tools and processes should facilitate interaction, not hinder it

Tools are means to an end, serving the underlying process. Mature processes rely on tools, but they are not subservient to the tools themselves. Whether it's a simple Kanban board or an advanced project management system like ZenTao, we often see many teams using these tools merely to describe the status of "work tracking."

Without a fully matured process, even the best tools can leave the team lacking the drive to pursue the business goals. Agile Scrum Masters should strive to help their teams continually learn and explore: how to best serve broader business objectives. For example, what process metrics should be used to course-correct? Where should feedback come from? How often should feedback be received? Teams and organizations should be able to adapt reasonably to changing requirements without disrupting the entire process.

Principle 3: Focus on the "What," not the "How"

The concept of the Minimum Viable Product (MVP) is foundational to Agile methodology. The goal of driving MVP is to provide new software features to users while collecting and integrating feedback to continue improving the product. However, since team leaders often work across different teams and consider different end users, this process can easily become inconsistent with established business strategies.

One team might be responsible for exploring a new product or service approach and use Lean/MVP tools to determine a solution. Another might emphasize adding or enhancing features in an existing product, while a third might focus on improving developer experience or infrastructure.

In an Agile context, recognizing the differences in development approaches is crucial, especially considering the work rhythm within the organization. We often see infrastructure automation, site reliability, and platform engineering tasks squeezed into a two-week Scrum cadence, even when the nature of the work doesn't entirely fit into two-week increments.

Returning to Agile

Agile, as a theory and practice, aims to help teams better adapt to changing environments, address challenges and problems at work, and improve work efficiency and the quality of outcomes. The methods and tools for implementing Agile should be means to achieve this goal, not the goal itself. True Agile lies in the team and individuals' understanding of Agile principles and the resulting work attitude, behavior, and methods.

From superficial Agile practices to truly internalizing Agile into organizational culture, this requires long-term efforts and experimentation from our entire team. True Agile core lies in the active response of team members, continuous learning, and improvement, thereby enhancing team efficiency and process quality. Therefore, we must not only learn and understand the principles of Agile but also integrate these principles into our daily work to truly "become Agile."

In conclusion, Agile is a progressive and challenging process. Whether you are a team already practicing Agile or a newcomer to Agile, you can unearth deeper Agile insights from daily work, learn and understand the essence of Agile, and ultimately achieve the transition from "doing Agile" to "becoming Agile."