I work in an Agile shop. It’s been challenging making the transition and we’re still far from comfortable but we’re making progress. There are many changes to the way “we’ve always designed” when adopting an Agile philosophy. This post will focus on one realization I’ve made recently – there are no job titles, we are all designers. Traditionally we’ve segmented our work into IA, visual design, prototyping, etc. When we first rolled out the Agile framework we desperately tried to maintain these differentiations. This came both out of muscle memory for the waterfall process but also from a respect and understanding of other disciplines and our own limitations.
The outcome of this however turned out that our new two week sprint world was now cut down, in most cases, to one week as each role tried to complete their work in time to hand off to the next one and provide them the time they need to do their work. As if two weeks weren’t short enough to create quality designs, we now had one.
It’s worth mentioning that we eased into Agile with the introduction of a suite-wide style guide that was public, wiki-based (and therefore a living document) and easily reusable. The team was generating prototypes using the assets from the style guide so no matter who created them, IxD or visual designer, the end product looked “designed.” It dawned on me at that point that there was no need to break the design process down in the way we’d done in the past.
In practice, we are all designers. Yes, we each have unique strengths, weaknesses and capabilities and it’s exactly those qualities that determine how the work gets allocated. Each person now owns a feature for the full two week sprint – effectively doubling the time they had to work on it in the past. The style guide has helped us reuse patterns as they’re needed without having to reinvent elements each time they come up. The designers on our team work can now focus more acutely on the design challenge at hand and not as much on whether form labels go on top or on the left and what color to use for secondary navigation. It’s proved to be far more efficient and productive. In addition, it’s empowered AND educated our team on the other disciplines.
Now, this doesn’t mean there’s no collaboration. The team is encouraged to reach out to their counterparts to seek advice, input and fine tuning of their work. This collaboration is a team building approach as well as a cross-pollinator of expertise. Everybody wins when everybody’s a designer.
[Jeff]
At one point, I was a lone designer supporting five scrum teams running two-week sprints. My reality was similar to what you describe, but extended to all members of each scrum team: it was almost more important to educate on good design practices and facilitate good design led by others than it was to actually do design. I had to let go of ownership of design, trust my team to execute decent design for standard problems, and limit my hands-on ownership of design problems to only the most strategic and critical problems.
Thanks for the post and the reminder.
We're slowly coming to that realization. It's not comforting, I have to admit, to consider “letting go” of the design – at least to an extent. I, certainly, have spent my career trying to “own” the design and tightly control the quality of the output. The interesting bit is not just that we have to let go. It's that others on the scrum team need to accept part of that responsibility and that product owners and executives need to understand this is happening and adjust acceptance criteria accordingly.
It's a tough sell all around (designers included 😉 .
[Jeff]