Can the Agile Approach Work for Design Teams?
Designamo: What We Learned — June 2016
A few months ago, Dynamo decided to try out the agile approach to better manage our projects. The hope is that this will enable project teams to respond better to unpredictability (read: chaos) through incremental, iterative cadences known as sprints. So far, so good — right?
On the surface, it makes a lot of sense: we work with a lot of startups whose needs are evolving. Having worked in a startup, I was accustomed to using sprints to prioritize specific features amidst growing demands from what sometimes seemed like opposing forces: marketing, engineering and design teams.
“Agile is engineering focused. It works well as a software development methodology, but it prioritizes quantity (or speed) over quality. It encourages progress (velocity, if you will) over creativity and innovation.”
Speaking strictly from a design perspective, it’s been a rocky road — chock-full of speed-bumps, curveballs and a near-endless stream of meetings on a daily basis. Why? Well, agile is engineering focused. It works well as a software development methodology, but it prioritizes quantity (or speed) over quality. It encourages progress (velocity, if you will) over creativity and innovation.
This is fundamentally at odds with what I believe it means to do great design work. Charles Eames famously said that design is in the details, but it’s also in the big picture. It not only includes the planing and foresight to envision how something will grow, scale and evolve, but also the fortitude to craft each and every button. Often, this leads to working in a silo until it’s just right and ready to show.
As an art director overseeing multiple projects, marrying these (sometimes) opposing philosophies has been a challenge. On the other hand, part of what I love about Dynamo is that we try things, and adapt them to fit our teams, projects, and people accordingly.
In keeping with this spirit, the design team has adjusted our approach to better fit with agile processes. Here’s what we’ve learned:
1: Establish roles at the onset
As our team grows, it’s more important than ever that everyone knows what they’re doing. On one hefty project in particular, we’ve divided up the work between overall brand strategy, web design, and product design, which means we have two art directors at the helm. Although this could easily turn into a non-stop, runaway train to conflicting feedback city, Max and I do our best to align on priorities and direction beforehand.
2: Get in the same room together
Design is a relatively solitary activity. I am guilty of trying to get everything done before sharing it, so I’ve tried to break out of my comfort zone by hosting working sessions with my fellow designers. At the very least, I ask for feedback on a regular basis from our clients by showing off work that isn’t completely polished to make sure there’s parity between our design deliverables. Now that we’re working in sprints, it also helps ensure that both the clients and designers are up-to-date on design decisions — so that the product can influence the brand platform and vice-versa — all within a relatively aggressive timeline.
Charles Eames famously said that design is in the details, but it’s also in the big picture. It not only includes the planing and foresight to envision how something will grow, scale and evolve, but also the fortitude to craft each and every button.
3: Design in parallel
I know this sounds like a truly terrible idea, but at the Montreal OFFF Conference last March, the inimitable design duo Anton & Irene explained that they always work separately, but in parallel. For example, when one of them is wireframing an overall user experience, the other starts designing the interface. The next day, they swap files and begin again. In doing so, they avoid sitting around a table engaging in groupthink about how to tackle a design problem, and instead, work and share files with each other to allow for tweaks, collaboration, and cross-pollination. In our experiences with this approach, each designer takes a stab at a proposed solution, and then we reconvene to take the best from each direction. This approach has worked especially well for us when creating style tiles for brand development exercises, but can also be applied to designing interfaces.
4: Write stories with happy endings
We owe a huge portion of our success to very flexible project managers. We’ve been working to write user stories in Pivotal Tracker to reflect bigger-picture design deliverables. The stories we write, approve and assign are geared to a more holistic approach than sprints currently allow, which helps designers think in terms of deliverables (i.e. a website) rather than a feature set (i.e. as a user, I can submit my email to register for this service). Once the design is approved, we break it up into more detailed, actionable items for developers.
5: Pair up with programmers
The reality of the agile process means that we’re designing a lot more iteratively at a much faster pace. This leaves little time for exploration (which I hate), but a lot more room for collaboration — specifically with developers. Working directly with the person who’s integrating my work has proven immensely beneficial to me. Of course, it has ensured that we hit our deadlines, but the unspoken byproduct of this type of teamwork is that we’re able to work out the kinks in the early stages of a concept, which allows us to refine the work more quickly together.
In the end, I love the principles of Agile, but principles do not a process make. I still feel that the methodology is heavily skewed towards software development, but recognize that change is inevitable when working with any client — especially startups — and that there are aspects of any design process that can benefit from this kind of flexibility and collaboration. The key is to adapt the method that works best for your team. Most of all — I remain hopeful that we’ll find the groove that works best for everyone at Dynamo. Until then, #Designamo will keep on keepin’ on.
