On Agile

What is Agile and how do you do it? No topic in our field has spilled more kb of text than this one, so I'll assume you're familiar with most of the Dialog and only discuss the bits on which I disagree or have something to add.

Agile (the principle) vs Agile (the process)

I use "Agile" to mean the ideology and a general approach to doing things; the set of processes used on an agile team is an instantiation of that ideology, and can vary widely even between two teams that theoretically agree on the principles. Some are broadly different enough to have their own names, Scrum and Kanban and so forth, but in my experience two "Scrum" teams can be as different from each other as a Scrum team is from a Kanban team. In the end, every team's process is a snowflake and that's a feature of Agile rather than a bug.

Sometimes two teams with very different processes are both doing agile well, and just have different constraints; other times they're different because one is actually agile and the other ain't. How do you tell the difference?

The Core Central Primary Important Main Gist of the Nub

I believe Agile boils down to one thing, or I guess, two related things: is the team doing the work empowered and engaged in their own processes? If the answer is yes to both questions, they are on the road to success, and if not, not.

• Empowered means they have at least the potential ability to change how they work. They're still beholden to stakeholders, but their proposed changes don't get shot down by fiat because process is definitionally owned by someone else and imposed upon them.

• Engaged means, once they're empowered to make changes, they have to care enough to actually propose them and talk about them and adopt them and later talk about whether they worked. This is difficult and needs encouragement - very few programmers wake up and say, "I want to talk about process today" - but necessary.

The combination of these two requirements is a meta-process, a process for changing process, in which the people doing the work (with the advice and consent of the stakeholders affected by the work) change how they do things. This is very nearly a synonym for "self-managing team" and also for "continuous improvement".

How This Happens in Practice

In theory there are infinite ways to accomplish this beautiful abstract principle, but in practice every successful Agile team I know of does the bulk of their agile-ing in three meetings, so I consider it essentially mandatory to get them right:

• Standup is where the team coordinates their work. How to do standups correctly is a whole other blog post, but the short version is: no more than 10 people, no more than 30 minutes, 80% of it should be "I'm going to do X today but I need help with Y".

• Refinement is where the team discusses the work they've been asked to do and figures out what they need before committing to do it. No, this can't be skipped if your PM is technical enough. It has to be a team meeting because that's how you keep the team aligned on definitions and abstractions.

• Retro is where the team iterates on their process. The best way to define that is to give positive and negative examples:

Terrible Retro

What went well? We shipped the feature. What went poorly? It had a bug. What will we do differently? Try real hard not to make bugs. See you next week!

Useful Retro

I wasted like two hours reviewing Dave's giant sproc change before I found out that Sally was already reviewing it. Could we come up with a way to avoid that? Like, when you start reviewing a PR, you put an :eyes: emoji reaction on the slack notification from the commit?

That right there, a person on a team proposing a process change that will make things work better, that is Agile.

That's it? I mean, that's obvious!

That's a small example, and it's easy to look at that and say, of course my team is empowered to do things like that. The hard part is being open to bigger changes, those that cost dev time or involve asking other teams to accommodate you. Suppose this comes up in retro:

I know the whole company uses Jira, but I hate it and it seems like everyone else hates it too. Remember when we started out, and we just had post-it notes on a whiteboard? It seems like we got so much more done. Could we just go back to that?

I'm not saying you have to say "Yes" to that or you're not agile; but I am saying that you can't automatically say "No" either. Your team has brought up a real problem and you need to find some way to make it less of a problem. If you shut them down - Sorry, Jira was ordained by the gods and no force can dislodge it, let's move on - what you're teaching them is that Process is something someone else owns, not something the team owns, and that is when I get to say you're not agile.

Bottom Line

• Agile is nothing more or less than the process by which teams improve their processes
• Every team that isn't totally burned out wants to improve their process, so you as the leader need to find ways for that to happen
• If none of their attempts to improve things go anywhere, they will quickly learn not to try