Tim Hordern

I ♥ building amazing products and teams. QA + Product + DevOps + Fast = Awesome.

Agile Teams Not Agile Products

I’ve heard people say, “We started using Jira and GreenHopper, so we’re Agile now”. Similar things are said of Rally, VersionOne, LeanKit, TargetProcess, etc. In making those declarations, it’s clear that they don’t understand Agile at all.

The Practices of Scrum (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), the Roles (ScrumMaster, Product Owner, and Development Team), and the Artifacts (Product Backlog, Sprint Backlog, and Product Increment) only help the team support the principles and achieve the goal of delivering working software.

Electronic tools (Task walls, Development Environments, …) or physical tools (Task walls, …) are only useful in so far as they provide support for those principles and practices.

The best analogy I’ve come up with helping people understand the difference between how an agile team behaves, and the stuff an agile team may use is to think of a professional kitchen.

Let’s take a high-end restaurant. This is the kind of restaurant that puts out big, incredible meals for a large range of customers. So, it’s not a diner, or a cafeteria, but it’s not a custom event.

The kitchen comprises a bunch of components that together make meals: some physical, some personality based, some commercial, some seasonal. There’s the team of chefs that work to make meals. There’s the recipes that they use. There’s the tools that they use, like knives or a mixer.

If you think that using Pivotal Tracker (or whatevery your favourite Agile tool is) makes you an Agile team, that’s along the lines of saying that owning a mixer makes you a great chef. A good restaurant may make extensive use of a mixer every night, knowing that it can save them a bit of time here and there, but they also understand that they might not want to use it for every meal. Or that today’s sauce can’t be mixed because it destroys the flavour. The tool is there for when they need it, but it does not make the chef, the meal or the experience.

Okay, but what about Scrum? We do Scrum! We do standups! And Planning Meetings!

Sure, and restaurants might have recipes. Maybe they have learnt that 95% of restaurants who want to make a roast chicken follow the recipe, and they often follow it themselves. But if they decide to have a different sauce, or the chicken isn’t available and there’s only duck at the market, then the recipe is no good. But they’ve learnt the fundamentals of cooking, so they don’t rely on the recipe and can adapt to the changes needed.

If you’re more of a sporting person, then think of it this way: buying a tool to call yourself Agile is like giving every player a whiteboard to take notes on the play that they’re going to do. It helps them but the fundamentals of working together as a team, learning how to work together as a team, and knowing which plays work for them, is a hell of a lot more important to have than the paper to write the play down on.

Just blindly following the meetings that Scrum tells you to do is a bit like having the team always huddle up all the time: if the message that the coach gives isn’t understood, or the team doesn’t understand why they’re having to huddle up, the message will be lost once play resumes.

Having tools don’t make teams into champion teams (whether they are kitchen teams, sports teams or software development teams). Champion people working together on amazing things make champion teams. The tools might make a little bit of that process easier but there’s a lot of fundamentals you have to work on first.