A few weeks ago at CivicActions we were just getting warmed up and ready to dive into proposal writing for what looked like a fantastic opportunity – a progressive government agency, one we’d worked a bit with in the past, was looking for bids to lead several years of honest-to-goodness innovation in how they connected with their constituents online. We assembled a dream team of partner organizations to join us on the bid, we mapped out initial approach, and together we noted our preliminary questions about the RFP.

And then, just as the magic was really starting to happen, or something like that, the agency made it clear that (dum dum dummm!) agile processes need not apply. No, seriously, Agilistas, kindly check your iterative mechanisms at the door and furnish us with a detailed project plan, schedule, and cost breakdown.

We sat with this dictum for a day or so, weighing our options, and then decided that we really weren’t in a position to do anything very well given this requirement. We notified our collaborators on the proposal that we were regretfully withdrawing our priming bid.

One of the partners wrote back immediately to say something along the lines of “I get it, but why not work in some fashion that satisfies the Agency’s waterfall planning requirement, but still leaves room for agile processes in the way that specific tasks are implemented?” And thus began an interesting conversation within our own ranks along the lines of “why not a little ‘agile-fall’ combination here and there?”.

Our sales wing answered first: the long and short of it is that we’re set up and oriented to do agile work. Projects that are conceived in an agile and open fashion (where stakeholders are committed to iterative work, user interaction, and continuous testing and feedback) are consequently set up for us to 1) win the job and 2) deliver great work. Projects that aren’t set up this way, and certainly not all projects particularly need be, are neither. Agile and open is what we do best.

But the conversation quickly moved past the logistics of aligning our strengths with the right sales leads. What of “agile-fall”? We’ve tried it in the past to limited effect, but was our implementation to blame? Could a hybrid agile-fall approach work well?

We quickly drafted a very broad-strokes theorem that proved, in a certain respect, a fundamental flaw in “agile-fall”:

  • The basic strengths of agile are in the ways that it helps the client and development teams together understand (and then orient energies and resources toward) elements of highest value to the user base and stakeholders. Agile does this through successive series of releases, testing, re-prioritization, and then authorization of the next increment of work.
  • This fundamental part of agile DNA — release/feedback/increment — is shut down completely by any imperative for a top-to-bottom plan, schedule, or budget that is established before work begins and then restricts opportunities for both feedback and change.
  • In other words, in hybrid “agile-fall” approaches which demand a binding project plan, “agile” loses right off the bat, and never gets to employ the features that make it successful in any meaningful way. If the strategy and approach aren’t agile, the tactical approach can’t be.

And, frankly, this is where our team ended up, in the end. A waterfall approach is predicated on a separation of “design/strategy” from “implementation”, and we feel we’ve had much more success when these areas are considered together, holistically. A detailed project plan binds a team to requirements that can’t be responded to in an agile fashion when they don’t work. And, in our experience, the project becomes increasingly strewn with UX and design landmines, and with weighty technical dependencies, the costs of which are difficult to even assess in a timely fashion. The agile approach values nimble planning over documentation, and generally views efficiency as the key to end value.

But are we missing the boat? Is there a middle way? (Should we have proceeded with our bid??). We’d be interested to hear from teams who feel they’ve made this hybrid approach work well. Feel free to share your stories below. In the meantime, our eyes are peeled for agile work for this dream team we’ve got in the wings.