Stop “Doing” and Start “Being” Agile

Let’s not beat around the bush here. It is really easy to be cynical about Agile.

I’ve worked with Agile for a long time, and I’ve heard it all. How it impedes productivity, that it costs too much to implement, and is rife with unreasonable expectations. Too many steps, too many meetings, too much indecision. No guardrails, no ways to resolve tech debt. It’s needlessly complicated, incompatible with our company culture, and fundamentally not how business, nor how life works.

I understand where they’re coming from. Agile itself, as a monolith, is so often tainted by the bad experiences people have had with it before – a system learned mostly by going through the motions, and always appearing to get in the way, or fail to set us up for success. It’s little wonder that I’ve met so few people as enthusiastic about it as I am.

However – this is, in my experience, an issue of education, not a fatal flaw in Agile itself. So many teams lose focus because they’ve forgotten, or never learned, why Agile works the way it does. When they take individual parts for granted, or lack the context, they miss out on the mushy stuff that holds it together.

So – for my first article, let’s review the fundamentals of Agile, separated from any framework. We’ll see what it means to “be” Agile, and how to “be” it in ways that teams will benefit from and enjoy.

Boom!

Let’s go back to the 90’s, when IBM and Dell have placed a computer on almost every desk in America, and in every middle-income home. Software companies are popping up everywhere, pushing new ideas, experimenting with new languages, new hardware, new ideas – selling new ideas, creating new solutions to exciting problems as the world witnesses the power of personal computing.

This necessitated the development of new ways of doing things. The industry is a tangled maze of new project management approaches, new ways of working in different sized teams – spurred by a seemingly endless amount of money, limited accountability, and no breathing space.

The wildfire of innovation becomes an inferno at the beginning of the dotcom boom.

Low interest rates enabled heavy investment, and by 1998, venture capitalists are throwing money at the future of a poorly regulated internet. Tech companies are operating with major losses, trying to “get big fast” without the burden of actually having to turn a profit – growth over profits are the key.

But nothing good lasts forever. Interest rates started to skyrocket, and investors stopped investing. Unprofitable companies ran out of cash overnight, and started dropping like flies. Over half of all online companies affected went under over the next four years. It was a financial disaster, and an apocalypse for the software industry, and the discipline of computer science itself.

Enter the Agile Alliance

So – in 2000, seventeen self-proclaimed “organisational anarchists” – project managers, philosophers, representatives and advocates for their own strategies for working with new, fast-paced technologies – got together to discuss a common set of values and principles that unified their different management approaches. This document became a list of Four Pillars (key values) and Twelve Principles (which provide structure to the values), describing their recommended approach to running a successful software project, balancing team health, product growth, and client satisfaction.

They called the document the Agile Manifesto.

Agile Manifesto TLDR;

By no means is this a substitute to reading the actual Manifesto, but at its very basic level:

• Communicate like crazy: with your customer, your teammates, and your stakeholders; collaboration makes it easy to adapt when necessary.
• Respond to the market: chase value, be open to changing direction; don’t fall into the sunk cost fallacy; don’t wait to deliver.
• Human-first: motivate your people, build sustainably, foster creativity, and empower your team to produce beautiful things.
• Chase value: work with your customer to respond to what they need (not just what they want).

However, let’s not forget:

• Agile is not an alternative to having a plan.
• Having a plan does not mean you’re not Agile, so long as the team is able to adapt.
• Welcoming changing requirements doesn’t mean bowing to them, nor requires sacrificing vision or goals.

How does it work?

Meeting	Time	Facilitator	Attendees
Daily Scrum	9:30 Daily	EM/SM	Full team
Sprint Planning	10:00 First Monday of Sprint	PO/BA	Full team
Backlog Refinement	1:00 Every Tuesday	PO/BA	Team leads/BA/PO
Retrospective	9:45 Last Friday of Sprint	EM/SM	Full team
Sprint Show & Tell	2:30 Last Friday of Sprint	EM/SM	Full team + Client

We can admit that the Four Pillars and Twelve Principles aren’t particularly prescriptive. As such, let’s call these Practices. Things we do because we need to do them. But they’re not “Agile” – not on their own.

Agile as Culture

Culture is an expression of how humans engage and interact with each other in certain contexts. Whether it’s social, corporate, or team culture, we have different ways of expressing what we do, and why. By and large, we can understand culture as a combination of the three things we’ve just reviewed:

• Values: What we care about most.
• Principles: How we express our Values.
• Practices: The tangible ways we express those Principles.

With this in mind – it becomes clear that Agile is fundamentally about Culture.

If we want to adopt the Agile Philosophy, we need to practice what we preach. How we do things, and the way we do them, must adhere to the Twelve Principles, while taking into account the reality of project life – team size, timelines, methods of communication, urgency, retrospection. Different people have created different sets of Practices that express the Principles and Values. We call these bundles of Practices “Frameworks” and, when adhered to, they enable our teams and projects to be Agile.

Where it falls apart

Do our teams know this? Many of mine didn’t. Agile was a thing that was just Done – a set of incoherent ways of working, coordinated by someone who memorised the Scrum Master’s Handbook without really understanding the underlying philosophy. The very idea of Agile being a feature of team or company culture was foreign, and ultimately unrealised.

If we don’t understand the values, if they get lost, or aren’t effectively championed, we get lost in dead-ends, leaving things to feel disjointed and uncomfortable.

When so much is lost upstream, it’s easy to understand why someone may never have benefited from Agile. When your Practices have no context, they feel like empty steps that get in the way. When you forget the “mushy” Values, you lose the picture completely, and it’s impossible to embrace a culture of Agility without cynicism.

More than just “Doing”

Agile isn’t a “how” – it’s a “why”.

A team that believes in Agile Values and Principles, and incorporates them into their own team charter and value systems, will deliver faster, develop better solutions, satisfy the customer better, be less prone to in-fighting and conflict, and overall be happier and more resilient. A team that’s just going through the motions can’t compete. Further, by representing and championing those Agile Values, you have a better chance of advocating for your teams, and driving organisational change.

In understanding and guiding culture in this way, contextualising the Practices and Principles, you can start your journey from “Doing” to “Being” Agile.