Everyone has an Origin Story. This is mine.
I discovered Agile by accident. I was a self-taught designer who’d travelled to Florida to hand off a project to the development team. My partner and I had spent the summer building this perfect product, and I was completely in love with it. But there was a problem: I knew that when those dummy developers got their hands on it, they’d ruin the thing. So I did the only thing I could: I went down there (in a very hostile frame of mind) to defend my baby.
That’s when everything changed.
Those “dummy developers” weren’t dummies at all. They were amazing. Smart, friendly, wonderful people, working in pairs with a sane process. This wasn’t an exception. I didn’t luck out and meet the one rockstar or the lone unicorn. No, this was a world where there was a system that worked to help people build strong web apps in a sane, sustainable way. The process held the promise that all those late nights, all the stress, all that constant re-invention of the design-wheel could be replaced with a systematic, repeatable, tractable practice for design. I returned to New York determined never to go back to the old way. I wanted to bring these things to design. I wanted to figure out how to do Pairing and Testing. Maybe it wouldn’t be exactly the same for design as for development, but the benefits of these techniques were missing in design—and I wanted them.
So I had a choice: find a shop in NYC that practiced Agile, or move to Florida. Happily, Pivotal Labs had expanded to NY earlier that summer. They were looking for an agile designer, and I signed on.
What would an Agile design practice look like? No one knew, but there were signs: how should a development shop interview a designer? Make him pair on his interview! It was intimidating and exhilarating, and a portent of things to come; of intuititing the right direction to go in, even if we didn’t know how exactly to get there. Of adapting techniques on the fly to invent our way to a practice that married agile and design.
On my first day I came in, said ‘hello’, put on my headphones and started working in Illustrator. It was me at my laptop and two pairs of developers: one pair to my left and another to my right. By my second day, I took the headphones off and started listening to everything around me. One of the affordances of pairing is that there’s talk all day. Listen, and you’ll hear the development process unfold. I started to learn the rhythms of What’s Important and What’s Not, of what’s a Real Problem and what’s not, what’s in interesting domain modeling question and what’s an implementation detail. These are distinctions that the design world lacks good language for. These are also, coincidentally, some of the hardest things to learn when you’re trying to learn to build software. This kind of stuff is really crucial, so I was fortunate to be in an environment where even while I was using Illustrator, these guys were coding and testing and pairing; I was absorbing the technique and practice the whole time. For me, that was the beginning of building an Agile design practice grounded in an Agile development practice that worked.
How’s it gone so far? There’re a lot of smart people working on the same problem. There’s still a lot of work to do. Sometimes it could be lonely being the only designer in a shop full of developers, but now Pivotal’s building out a Product Design practice, and it’s a great environment from which to drive out this practice. (Want to help? We’re hiring!). Pivotal’s mission is to change the way the world develops software, and bringing Agile practice to design fits into that mission seamlessly. Agile Design practice has come a long way, but it’s still years behind development. There’s a lot more to do, and I’m grateful to be part of a team that’s doing it every day.
