Are you doing agile or being agile?
Countless CIOs have told me that their software and IT teams are "doing agile," and my response is always the same: "But are you being agile?"
It’s hard to believe that it's been 21 years since a group of influential software practitioners came together and published the Agile Manifesto, a set of principles designed to improve the software development process. The Manifesto emphasizes adaptive planning, evolutionary development, and continual improvement. In the two decades since the Manifesto's first appearance, agile development practices have become de rigueur for all manner of enterprises.
For the modern IT leader, the theme of agility has become both an aspirational credo and a guiding principle for leading transformation-based initiatives. Learning to implement agile methodologies has become commonplace in modern software-driven organizations over the past two decades.
However, I would argue that it’s far more important for software leaders to teach their teams how to be agile and not simply perform agile ceremonies as prescribed in a book.
Why doing agile doesn't mean you are agile
"Agile is an attitude, not a technique with boundaries," wrote Alistair Cockburn, the renowned computer scientist and co-author of the Agile Manifesto.
Even though the very first principle of the Manifesto emphasizes "individuals and interactions over processes and tools," a plethora of agile-facilitating software tools have essentially become substitutes for the process itself. In the name of "doing agile," we've seen 60-person program increment planning exercises, overcrowded standups with scores of confused team members, and 18-month sprint plans that were dead on arrival because the business had already moved on.
As a result, communication between the teams and their stakeholders became weaponized. The burndown chart became a tool to burn the teams. And the work ultimately became decoupled from the KPIs they were intended to support.
Three guiding principles of 'being agile'
Being agile is more about the collective mindset and the culture of the team than it is about the discrete enabling processes. Many agile-driven projects fall short from people robotically going through the motions without understanding and actively applying the spirit of what agile really is.
These three principles come from the direct experience of our team, which has tirelessly documented both the doing and being of agile, highlighting the characteristics that distinguish the two.
Principle #1: Continuously and relentlessly manage to business objectives, not tasks
Ask yourself why the business cares. This simple question is foundational and one that we encourage CIOs to continually challenge their team to answer for every feature request and user story. While it might seem like overkill, posing this question throughout the development lifecycle builds the habit of reinforcing the end goal of the process itself, helping drive alignment within your team and external stakeholders.
For example, we frequently engage with clients to help modernize their technology stack; typically this involves helping them migrate their applications to a container orchestration or cloud-native platform. This can seem like a goal, but really this is an implementation detail, not a business outcome that you can measure or track.
The goal isn't Kubernetes. The goal is to realize greater efficiencies and gain control of your application deployments in evolving multi-cloud environments—potentially working toward business continuity and cost-optimization scenarios at the business level. In other words, the tool or technology serves the business goal, not the other way around.
Principle #2: Tools and processes should facilitate interactions, not get in the way
Tools are a means to an end, the instrumentation that serves the underlying processes. A mature process relies on tools but is not subordinate to the tools themselves. Whether it's a simple Kanban board or an advanced ticketing system such as Jira or Rally, we frequently see what can only be described as a forest of tickets "tracking work."
Absent a fully baked process, even the best tools will lack context, structure, and most critically, clarity into the business objective that’s driving the work.
The CIO who is being agile should endeavor to help their team constantly learn and explore how to best serve the broader business objectives. What should your process indicators be for course correction? Where is the feedback you need coming from, and how frequently should you expect it? Your team and organization should be able to reasonably adapt to changing requirements without having to gut the entire process.
Principle #3: Focus on the ‘what’, not the ‘how’
The concept of minimal viable product (MVP) is foundational to agile methodologies and provides a good case in point on how the being and doing of agile often become conflated. The objectives driving MVP are to both deliver new software capabilities to users while also collecting and integrating feedback to continue improving the product.
However, because you often are working across different teams with separate end users in mind, it's easy for this process to become misaligned from the stated business strategy.
One team might be tasked with exploring a new product or service approach and will use a lean/MVP tool to identify the solution. Another may emphasize adding or augmenting functionality in an existing product, while a third may be tasked with improving the developer experience or infrastructure.
Recognizing the differences in how the work is developed is crucial in the context of being agile—especially given the pace of work within your organization. We frequently see infrastructure automation, site reliability, and platform engineering work shoehorned into a two-week Scrum cadence, when the nature of the work does not fall neatly into two-week increments.
Focus on being, not doing, agile
The reason MVP was such a powerful concept was that it forced the various stakeholders to identify the least amount of work and effort they could devote to clearly understand what they needed to build. However, in the quest to do agile, we end up with a Scrum team working on an MVP for six months and then repeating much of the same work to get to a 1.0 release.
Software is the lifeblood of the modern enterprise, and the CIO who understands the distinction between doing agile and being agile will establish an invaluable foundation that can be applied across the entire IT organization.