Skip to main content

Introduction to Being Agile - Part 2

First, let’s define some things. Agile is not Scrum (or XP, or Kanban). Agile is not JIRA (or Rally, or VersionOne).

Introduction to Being Agile - Part 2

We're Agile now

You have heard that agile is more than standing up and burning down. It’s a complex system. I challenge you to describe SAFe in a few words (spoilers, it can’t be done). My guiding advice when approaching the topic is to start with the basics, the values of the Agile Manifesto.

Four value statements:

  • Individual and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

They’re simple, elegant, and a great start. Then what? Conveniently on the same site, there are 12 principles. And then? The Six Rules of Kanban, or 29 rules on the Extreme side. Wait, not what I signed up for! Is there a tool to simplify all these things? There are plenty. I won’t even attempt to enumerate them. But which one makes me agile? Do any of them?

Using a multimeter does not make you an electrician.

Chris Antonio, BrainGu’s Learning + Development Manager, asked “What is Agile'' and addressed the distillation of “Agile Methodology '' from the four values through the 12 principles. You can read that post here. To expand on a point in Chris’s post, frameworks and tools are not themselves agile, and just using agile tools does not make you agile. It is a disappointing realization in an industry defined by what you produce as much as what you use to do it. Yes, they are useful tools. Yes, they can correlate to higher measures of agile practice (or agility). But using these tools will not change your mind or culture. As anyone who’s hit their hand using a hammer can tell you, it’s the hammer’s fault, and your fingers just get bigger as your organization grows.

So how do we Agile?

A more precise measure would be to trace the same mapping of values → principles → frameworks → tools in reverse. How are we using this tool to execute this framework? Which principle does it observe? How are we aligning our values? How are we undermining them? Perhaps the best advice for strategic direction is the 12th principle:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

To pull it all the way back, let’s take a look at the first value:

Individuals and interactions over processes and tools.

You may be surprised that it is the first value by the time you’ve steeped in the multitude of rules and tools available. Admittedly I was surprised when reaching for the reference.

Tools are a great first step, but picking an agile tool does not make you agile. The critical shift to agile transformation is to use it while it works and switch when it doesn’t. It is easy to forget that it is not the tool that defines you, they express your actions, and your actions define you. As you exercise the 12th principle and experience an agile transformation, do not neglect the evaluation of an easily overlooked fundamental.

Tool choice does not need to be a uniform prescription for every problem, either. At BrainGu, we generally use Jira but are quick to whiteboard novel issues as lists of tasks, with priorities, dependencies, and whatever is germain to drill into the problem, discuss and assign action items, all without translating to Jira.

If your team is using a tool “because it’s agile,” but it is not enabling your team to be effective, or it just feels onerous, consider a new tool and continue your agile transformation.


Related Posts