Deciding What Kind of Projects are Most Suited for Agile

I was recently asked what kind of project is most suited for the agile process. In my view, the most appropriate projects for agile are ones with aggressive deadlines, a high degree of complexity, and a high degree of novelty (uniqueness) to them. We want to use agile when we are doing something that is new, or at least new to the team building it. If it's something the team has done before over and over then the team probably doesn't need an agile approach.

To my mind, this is where some of the manufacturing analogies come in. If we are building the same car day after day, we learn pretty quickly all the nuances of building that car. We don't need an agile approach because the novelty of the situation is low. Novelty alone does not mean we should use an agile process.

I went to my favorite Chinese restaurant for lunch recently. I ordered an entree "triple extra spicy and with jalapenos." It was probably the first time they cooked this particular dish that way and so it was a novel or unique order. The cook prepared it wonderfully though and because I could see into the kitchen I'm sure they didn't need a daily standup or even TDD to make my lunch. (I might have noticed a kanban back there, however. 😊 So, in addition to novelty, the project needs a certain amount of complexity. One final element I believe is required in making a project appropriate for agile is urgency. The timeboxes and iterations of an agile approach are devised to keep the intensity and focus going on a project.

If there's no urgency to the project, those are unneeded. So let's see how these three factors--urgency, complexity, and novelty--mix on various projects, starting of course with software projects. There couldn't be a better fit. Software projects are notoriously complex. Each software project is largely a new endeavor. And in today's world, there is almost always a sense of urgency.

But let's look at one other situation where we commonly here about Scrum (in particular) being applied: getting married. At least a couple of times a year I hear about a couple who planned their wedding using Scrum. There is always a wedding backlog--buy cake, pick photographer, send invitations, pick dress, etc. How does planning a wedding do against the three factors I'm proposing. Sense of urgency? Check. There's always a deadline and it's usually pretty fixed. Complexity? Well, it's not like a software project but it does have its own complexities often enhanced by non-functional requirements such as a fixed budget, who sits next to whom, the type of food to be served, the need to let Cousin Ira's band perform at the reception, etc. Novelty? Yep. Most people don't get married enough times with large celebrations that planning the event becomes second hand.

So, agile is most appropriate on any urgent project with significant complexity and novelty--and that includes software development and weddings. It does raise the question though of whether a couple's first kiss at the end of the ceremony is a product backlog item or part of the done criteria for the overall product.