Agile in 3 Easy Chunks

If you’re not familiar with agile, it’s basically a set of practices to help teams innovate. Done right, it’s a workhorse for applied innovation, something every corporation wants. The messy part is that if you talk to someone on an actual team at a corporation about the company’s practice of agile, odds are good you’ll hear a lot of grumbling. And not without good reason!

How Do You Know When You’re Agile?

Across my experience as a founder, a manager, an adviser, an investor and a faculty member, I’ve seen agile practiced a lot of different ways. On one end of the spectrum, you’ll find folks who tell you the important thing is the principles. These principles are encapsulated in the Agile Manifesto, the core of which is only 68 words long. This isn’t wrong, but it’s not very actionable.

On the other end of the spectrum, you’ll find folks that have a very formal, relatively rigid practice of agile, usually prescribed by one of two frameworks: Scrum or SAFe. These “agile in a box” frameworks are highly actionable but not always valuable or relevant to the needs of a particular team.

Most of the high-functioning teams I’ve met get to a strong practice of agile by following three steps:

1. Assessing what’s important to them right now
2. Selecting specific agile practices with an explicit idea of how they might deliver on No. 1
3. Iterating

As with a lot of topics that are easy to understand but hard to practice, doing this takes focus, energy and, above all, endurance.

Step 1: Assess What’s Important

To understand what’s important to your team, I recommend sketching out your software delivery process end to end — all the way from observations about what’s important to the release of working software. Then it’s important to decide what parts of the pipeline you want to focus on improving right now.

This diagram summarizes a few of the major elements you would include in such a sketch (yours may be much more detailed):

Step 2: Determine Relevant Practices

How do you think about all this in terms of focus and methods you might use? It’s kind of overwhelming. There’s variation in the terminology, but I think it’s useful to think about the portfolio of agile practices you might invest in testing across three general areas:

Continuous Design: Knowing when and how to make the right investments in discovering what’s valuable to your customer. You’ll know it’s working if a higher percentage of the features you release see high engagement from users.

Agile Development: Knowing how to organize the work of a development team, including and especially the key inputs, outputs and intervals. You’ll know it’s working if the quantity and predictability of your release content goes up.

Continuous Delivery: Knowing how to organize the integrated work of the development, test and deployment/ops teams, in particular making space for investments in automation and modern tooling. You’ll know it’s working if you’re releasing more frequently.

This table organizes  the three chunks in a little more detail:

Step 3: Iterate!

This is the single most important step. No team, no manager, will perfect their practice of agile on the first go. Having explicit ideas about how each adopted practice will help the team and a way of assessing it during the retrospective at the end of each agile iteration is at the core of successful practice. When I’m asked to coach teams, it’s the first thing I ask and the last thing I emphasize before we part ways.

The good news is that there’s a lot of great material out there on how to practice agile — you just have to know where you want to focus. Since I’m the author and all, I can’t help but go ahead and recommend a few courses we offer online with Coursera:

Continuous Design: Agile Meets Design Thinking

Agile Development: Managing an Agile Team

Continuous Delivery: Continuous Delivery & DevOps

Good luck with your practice of agile, and if you’d like to tell me about it, I’m on LinkedIn and Twitter.