Hey, Do You Guys Do Agile?

We do project reviews at Soliant. We sit down with the PM, ask them how the project is going, or went. If it went well, we drink metaphorical beer and celebrate. If it encountered challenges, we ask questions, occasionally pointed ones. We try to learn from the good and bad.

A question I tend to ask is, what process did you follow? We have a pretty well-understood process framework at Soliant, but each project is different. And, while we try to follow a consistent process, we try to make sure that the process is sensibly adapted to the individual project. So I always like to hear how the PM approached the project, how they tailored our overall process to the specific case.

In general, we favor more design up front rather than less. For projects of any size, we conduct a “Foundation Phase,” which consists of discovery and design: requirements, data tables, UI screens at a minimum. Technical prototypes and proofs of concept if need be. How “heavy” these products are can vary by project: in some cases we design all the screens down to the pixel, in others (way more often) the technical lead will produce low-fidelity mockups. Requirements docs could run to 200 pages, but more often we have a leaner set of lighter-weight use cases. At a minimum though, the rules are these:

1. If it’s a new project, or a significant extension to one, do a foundation phase
2. When you do a foundation phase, the outputs are the following, at a minimum:
   1. Prioritized list of features/use cases/user stories
   2. System mockup, of whatever fidelity appropriate, covering all user-facing UI in detail
   3. Clear mapping of features/use cases/stories to UI
   4. Data architecture (at least an ERD, prefererably a data dictionary with all known user-facing data elements)

Now, we had this view of things pretty well understood. Then I started looking more into “agile”. And I made what I will admit is the mistake of introducing the term into the organization without adequate groundwork. That has led to the occasional project review conversation that goes like this:

“So how would you describe the process you followed on the Tasty Froots project?”

“Well, we ran this project in more of an agile way.”

“Not sure how you mean that. Did you do a foundation phase?”

“Not exactly a full one, no. The customer was eager to get started. And to be honest, there wasn’t exactly budget for a foundation.”

“So how did you figure out what you were going to build?”

“Well, Kallia (the lead developer) sat down with Michael (the lead customer) and got some requirements. She’s pretty sure she knows what we need to do.”

“So how are we doing on estimates vs actuals?”

“Well, Kallia thinks she’s about 60% done.”

“Well, but you’ve used 75% of your budget. Are your confident in her 60% estimate?”

“I’d like to be. I guess I might wish for more visibility.”

Indeed. “Agile” here, as often elsewhere, often seems to mean “we didn’t have time/budget/will to make a proper plan.”

So, that’s not what agile is. Doing the right amount of planning is critical to a project. I definitely lean a bit toward Joel Spolsky and his penchant for Big Design Up Front. At Soliant, the exact amount of bigness varies, but Design Up Front? Well, you just gotta.

And agile, to me, doesn’t mean not doing that. “Agile” is not incompatible with “planned”. We’ve struggled a lot in the process area to pin down what “agile” or any of its compatriots like “lean” is, and how it differs from … well, we even struggle with to call the other thing. Waterfall? Nope, really bad word. Plan-driven? A nice term, from a very good book by Boehm and Turner, but still imperfect.

So what is agile, or what should it be, for an organization that strongly believes in measure-twice-cut-once, ounce-of-prevention kinds of things? Oil on water? Water on phosphorus? No, not really.

Here, I think, are some key agile-ish principles that just make for very good projects, and are in no way incompatible with even large amounts of planning.

1. Start as small as you can. Meaning, in defining scope for a new project, work aggressively with the customer to define the smallest app that will deliver the most tailored, focused piece of business value they need. Don’t make it smaller than it rightly should be. If it’s big it’s big. But fight gold-plating like the plague. Scrub your requirements, and start early. (Spiritually akin to “do the simplest thing that could possibly work, which I actually think makes much better sense at the requirements level than at the technical design level where it was originally proposed).
2. As an aid to the above, prioritize, prioritize prioritize. This is a hallmark of agile, which takes it to a very tactical level, but it’s sound, slap-your-forehead project management as well. If time or money run out, or stuff happens, make sure that what you’ve built to date is what they need the most. Also this conversation, like the one previous, helps to educate your stakeholders, if need be, that successful projects are all about tradeoffs, and the sooner those are surfaced and discussed, the better.
3. Focus on the user’s view of functionality, not on how you’re going to build it. Work with use cases or stories. Save task breakdowns till the last minute, if at all.
4. Use rolling-wave planning. Don’t try to write a task breakdown for six months of work and Gantt chart it. It won’t be right. Work with something like three levels: project, release, and iteration. For shorter projects, two levels will do. Only the current release should be planned in any detail. Only the current iteration should be planned at the really detailed design and task level.
5. Use agile tracking principles to manage the development work. Break the release into iterations. Stick to a timebox, Do an iteration planning meeting where you review the requirements and hammer out the last design details. Do a task breakdown now IF THAT HELPS. Stick to a timebox Use story points to estimate. Do what Mike Cohn says in his very good book. (Except ignore the stuff about how your project’s a failure if the requirements don’t change much).
6. Track doneness by user functionality delivered, not tasks complete. See Alistair Cockburn’s fundamental blog post for more.

All of these practices are designed to limit scope, to do the right planning at the right time, to focus on user value, and to maintain high discpline and visibility during construction. Call it agile, call it lean, call it adaptive … or if you like, just call it “software development best practices.”