In this three-part series, I’ll be describing how I took elements of agile workflows and applied them to my daily life. We’ll begin with an overview of agile itself.
A few years ago, I went in for a job interview. This was a job I wanted very much at a company I would have been psyched to work for. The interview went very, very well. The term “rock star” was thrown about liberally (and not by me). As I left the interview, the thought occurred to me “If I get this job, I’ll be done.” As in, everything will be easy. Everything will be taken care of now. Everything will be all right if I just get this job.
Almost immediately, another thought occurred to me. “That’s ridiculous.”
Of course I won’t be “done.” I’ll still have to take out the trash. I’ll still have to do the laundry. I still won’t have completed the forty-odd feature films I have bubbling around in my head. Things will be better, to be sure (I hated my current job), but by no means will I be “done.”
The phrase “Everything will be all right if…” should inspire profound skepticism.
So while I was still excited about the prospect of getting this job, I needed another way to think about it that mapped better to reality. Which was a good thing to find, considering that I didn’t get the job.
What Is Agile?
To oversimplify greatly, agile is one of two popular workflows for getting things done. The first, and more traditional workflow is called “waterfall”. In a waterfall methodology, you assume you know what the outcome will be. We’re going to build a house, and here’s the blueprint showing us exactly what it should look like, and nothing is going to change between now and when we finish building it.
As a result, we’re not going to meet much, if at all, during the build. We’ll just assume everything went to plan and meet up again once we’re finished. And when we’re finished will be the only “delivery” during the whole project. We’ll show a completed thing at the end of the process as opposed to a completed room here or a completed room there during the process.
(This is, of course, an extreme vision of waterfall, but it speaks to the values and assumptions of the waterfall approach.)
Agile, on the other hand, works from a different set of assumptions. Rather than asserting the outcome in advance, agile simply agrees upon the goal. We want a place to live. We make certain assumptions beyond that, features if you will. It should be warm. It should allow me to keep my stuff there. It should make it easy for me to run electronic equipment and go to the bathroom. There will even be blueprints but those blueprints are understood to be a first attempt and not necessarily the final outcome.
The blueprint serves as a hypothesis about the outcome, rather than a photoreal representation of it.
Because we don’t assume that the blueprint and the final outcome are the same thing, we meet frequently to discuss how the project is going. Every day in fact. Also, instead of releasing the final build of the house at the end, we work on one room at a time (or one feature at a time), “release” it after a defined period of time, review it, learn what works and what doesn’t and iterate, changing the blueprint if necessary.
This being a house that exists in the real world there are still dependencies (the plumbing has to be in place before the bathroom can be finished) and deadlines, but the idea is to be as flexible as possible around those constraints, while letting them inform how we prioritize and schedule our work.
What Difference Does It Make?
Glad you asked. Remember this?
Remember how awesome that was? That’s why this is important.
Clay Shirky wrote a magnificent dissection of the debacle which highlighted the differences between agile and waterfall and how they impacted the outcome. The upshot is that most government projects are waterfall by definition. It’s very hard to bid on a project where the outcome isn’t predetermined. It’s very hard to write policy for a project whose outcome is not predetermined. (It is not impossible, however. Requirements are actually a very big part of most agile projects, they’re just written smartly to accommodate the process.)
As things went wrong leading up to launch, it was difficult if not impossible to adjust or test accordingly. This is one of the fundamentals of an agile approach, often summed up in the mantra: “Build. Measure. Learn.” This is a cycle where you build something, measure its effectiveness, learn from those measurements, and use those learnings to build anew. It’s an iterative approach. The build/measure/learn phrasing has found its way into other disciplines, including business, where it’s called “lean startup methodology”.
There was no build/measure/learn process leading up to the launch of healthcare.gov. But there was a build/measure/learn process. It just happened after the launch. Publicly. Embarrassingly. Frustratingly. Risking the effectiveness of the whole damned policy-ingly. Had the project been developed using an agile process, all of that would have happened behind the scenes, before the launch.
He also highlights the “failure is not an option” mentality that pervaded this project and is supported by waterfall, limiting the possibility that the higher-ups will ever know that anything is going wrong. Agile, on the other hand, not only refuses to punish failure, it finds a way to value it.
The most telling line that Shirky writes is this (emphasis mine):
Like all organizational models, waterfall is mainly a theory of collaboration. By putting the most serious planning at the beginning, with subsequent work derived from the plan, the waterfall method amounts to a pledge by all parties not to learn anything while doing the actual work. Instead, waterfall insists that the participants will understand best how things should work before accumulating any real-world experience, and that planners will always know more than workers.
This is the primary disconnect between waterfall and reality. When we do things, we learn things. Almost always. Waterfall assumes that a project is like building an Ikea desk. Just follow the instructions and the outcome is predictable. You don’t learn anything building an Ikea desk (except how shitty some Ikea instructions are). This is truer for projects that have been done many, many times before under the exact same circumstances. It is unlikely that you’ll learn anything new if everything is the same. But how often are projects like that? How often is life like that? What I’ll argue is, almost never.
In Part Two, we’ll take a look at why agile is having a moment right now.