1 Comment

Reflections on Four Years of Integrating Design and Development

Atomic started down the path of tightly integrating design and agile software development in October 2007. Before that time we’d relied on outside designers, partner firms, and even our clients for the various activities and artifacts that go by the name “design.” We felt then, and we know today, that by integrating design and development we could make better software products for our clients. (Here’s my slightly off-color metaphor: Design and Development get in bed together. What results? Beautiful little product babies!)

Consistent with our mistake-driven approach to business, we’ve tried a lot of different things in those four years. We bailed on what didn’t work, we tweaked what was close, we tried new ideas — we are still in fact learning our way through this problem. What I can say conclusively is that there’s no going back. Atomic is so much stronger for having our own designers, and the work we do for our clients is so much better, and life is just so much more interesting, that despite the additional complexities and some remaining challenges, the results have absolutely confirmed the vision.

Our current strategy is summed up on the face of our snack island in the middle of our office.

“Poly-skilled, co-located, self-managing, teams of makers” reflects our belief that the best organizational unit for our company is the team, that hard-and-fast distinctions between makers (designers versus developers, say) is counter-productive, that teams are directly responsible to their client for fit, scope, quality, time and money, and that the makers on these teams should sit (or stand) together. Drew has contrasted our approach with the more typical one of hard boundaries and specialist teams. (As an aside, the “fixed budget, scope-controlled” phrase on our island refers to how we manage projects.)

We’ve learned that “design” is a word so broad as to be nearly useless. Dangerous, in fact. Back in the day we “knew” that design had to be done by specialist people since it involved selecting colors and drawing pleasing images. What we appreciate today is that the word “design,” in the context of software product development, covers product definition, user modeling and research, marketing intent, feature selection, release planning, information architecture, interaction design, visual design, and design implementation. At least. The big “ah ha” for us was understanding that skilled, experienced developers can contribute to many of those activities without once launching Photoshop or Illustrator. The more abstract the activity, the more the team is responsible; the more concrete the activity, the more specialized individuals tend to be responsible. Along these lines, Jason’s written about his experience pair designing with another developer.

From a capacity planning and scheduling perspective, our “poly-skilled, co-located, self-managing, teams of makers” strategy is pretty straightforward. We just need to insure that each product team has the right blend of skills to create a great product. With our three designers and sixteen developers (leaving out our embedded team) that generally means each project gets at most one designer assigned to it, and some teams only have a half-time designer assignment. (That’s another thing I’ve learned: designers seem to do better than developers with multiple, concurrent assignments.) What this approach eliminates is opportunities for pairing between designers.

Our projects benefit strongly from the fact that our “teams of two” approach to development supports pair programming. What, we wonder, are we missing by not supporting pair design? The poly-skilled team of two allows for design pairing on the higher-level, more abstract design activities, between a designer and a developer, but not between two designers, and not on the lower-level, more concrete design activities. Are we losing something valuable because of this? Brittany’s identified this problem while also describing the advantages of our approach. Anders Ramsay, a friend of Atomic’s from the Agile UX community, identifies advantages of pairing across design specialities. We achieve some of these with our poly-skilled team approach. Leisa Reichelt concluded that pair design, in the sense that our model doesn’t easily support, provides similar benefits to pair programming.

To address this potential shortcoming, we’ve considered assigning a pair of designers to two projects, instead of one designer to each project. Ignoring the practical (i.e. scheduling) difficulties of this approach, in theory it gives each project the same capacity from designers, while supporting the possibility of designer-designer pairing. On the other hand, it might actually work against our goal of team responsibility and minimization of firm boundaries between designers and developers across the broad spectrum of design activities. Seems bad.

One aspect I know our approach makes difficult is designer-designer mentoring. While there is a great deal that developers and designers can teach each other, and a junior designer mentored by a senior developer can pay huge dividends, I suspect young designers would also benefit in specific ways from working closely with senior designers. To that end I’ve suggested that our designers get together for one to two hours a week outside their projects (but inside the work week) to compare notes, review and critique each other’s work, talk tools and process, and generally rub brains. It’s not the same as pair design, but it’s proving to be a successful experiment so far. And I hope that it might make it easier through stronger, closer relationships for our designers to interrupt each other and spontaneously pair on tough problems.

When I look back on the last four years I’m simultaneously amazed at how far we’ve come and frustrated that we haven’t figured it all out yet. Life was simpler before we started down this path. Scheduling was easier. We all got the same jokes and flexed our muscles in the same way. We gave a shit about fewer things. Sigh. On the other hand, I’ll pick an interesting problem over the status quo any day. And I can’t wait to see what we’re doing four years from now.