Home > Blogs > Choosing Approaches Below the Project Level

Choosing Approaches Below the Project Level

In the book Artful Making, by Rob Austin (who also wrote Measuring and Managing Performance in Organizations) and Lee Devlin, the authors present similarities between how a theatre company prepares for a performance and how agile software teams do their job. The authors identify a number of parallels, but I am most impressed in how they are careful to repeatedly make the point that the approach is not appropriate in all situations. In reflecting on what the authors say, it is possible that no one approach is correct or sufficient for any project.

Let me explain, as that last statement may not easily parse. I’m not saying that we can’t head into a project knowing how to approach the problem. I’m saying, rather, that most reasonably sized software projects are large enough, complex enough, multi-faceted enough to warrant a number of different approaches, for different aspects of the problem. I can’t think of a real-world software project that is perfectly tailored, in its entirety, for one specific approach. Not waterfall (...a few zealots go "yay!"). Not Agile (...a few older zealots go "yay!"). Nothing.

Let’s look at a concrete example. We’re tasked with building a real kick-butt first-person shooter game. Ask almost anyone in a game development company, and they’ll probably tell you this thing is perfect for an agile approach: build some elements, play with them, make them better. Evolve the artwork and the story as you go, and you will eventually converge on a winner. Cool, sounds like fun, but is this the right approach for the whole project?

Well, maybe not. Unless you want to develop the characters and story line from scratch, you are bound to the comic book/historic battle/sci-fi story that is the basis of the game (and much of this will become business rules to abide by, where you don’t have the option to deviate). What about the platform you are running on? Are you going to stick to the lowest common denominator of hardware and software capabilities and settle for lowest common denominator of sales as well, or really go for it? Do you head to the PC and it’s capabilities, or the gaming consoles? If you had started 2 years ago (or plan to start a couple of years from now), you have a new generation of game consoles and their not-so-subtle nuances to contend with. If you are going multi-console, how do you reconcile all of this without too much redundant development? All of this sounds like interface requirements and architectural considerations to contend with. While agility will help you with determining feasibility and selecting among different options, you probably won’t get away without some deep analysis.

OK, let’s go the other way. Many would contend that it would be insanity to head down an agile path for a large safety-critical product like an air traffic control system. There are lives at stake, we have good representation from the user community and they know what they want, and we just can’t afford to ship a little, learn a lot. Waterfall all the way, maybe big-chunk incremental, right?

Not so fast, buckaroo. No matter how big or safety-critical a new product is, if there is no novelty in its implementation you should really be asking yourself why you are investing all that money in the first place. Even if that novelty is under the hood as you port the system to the new platform while keeping the user experience nominally the same, there will be some areas that are ripe for experimentation, discovery, iteration. You won’t be able to nail everything up front, and agility will be required for you to adjust to what you learn. Feasibility issues in the platform you are using, novel algorithms that you will need to explore and tweak. If you are doing your job right, even with what might originally appear to be a vanilla port, there will likely be opportunities to tune the interface to refine the user experience, sometimes dramatically. While deep analysis and specification will be necessary to nail down much of what you need to build, there will be areas that require some agility.

If you can imagine an application that can be built most effectively with purely agile approaches, you probably have an interesting widget that doesn’t provide deep value to someone, or doesn’t interface with anything, or something that has mysteriously popped out of a lab, and not been devised with a clear vision of a problem to be solved. On the other hand, if you can imagine an application that can be built most effectively with purely traditional approaches, you are failing to push the envelope and extrapolate the possibilities for the user, or to explore possibilities before settling on one implementation. The key phrase in both these sentences is 'most effectively', as systems have been built, and success has been declared, from both camps many times in the past. I’m sure, though, that a better job could have been done with more balance.

Shades of gray rather than black and white. The industry is brutal for people taking sides in the battle over which development approach is the best. Some would suggest one approach is correct for everything, some would suggest it depends on the business or team. At the very least, in my books, it is project dependent, but more and more it makes sense to look at an even more detailed level. Even within a project, there needs to be a reasonable balance of flexible and rigorous approaches to be most effective.

The selection needs to be conscious and tactically considered in the context of the strategic goals and current information. This requires expertise in a range of different techniques and the recognition of the resulting value to the customer and the business. Let those in one camp or the other continue to shout about their 'best approach' and try to make everything fit, while you select the right techniques for each aspect of your challenge. A tall order, but worth working towards.