Making Agile work with design

I’ve been meaning to write about my own experience with Agile for a long time! Such a persistently hot topic in design circles. After a great happy hour discussion with our peer Citrix Online designers–who function in a total Agile-driven enviro in Santa Barbara–I decided to share some thoughts from my previous Agile engagement.

** First it’s vital to understand that Agile is a development methodology for programmers, not a “user experience” model for designers. It was meant to achieve efficiencies in producing code as PM requirements change (which they inevitably do). It introduces the concept of “code iteration” and rapid collaboration on the fly–among programmers. That’s it. It’s not a panacea or a magic solution to everyone’s “lack of innovation” problems. Agile won’t give you an iPod. Agile won’t make your company the next Apple. Sorry.

Now that we’ve addressed that point, the big challenge is how to fit design into the often brutally short time cycles (sprints) and influence the stories (dev focus areas). Here’s what we did at Involution Studios with Andrei Herasimchuk when we were hired by a small software company called Agile Software (I know, it’s confusing :-) to help re-invent a product lifecycle management application from a visual, navigational, and behavioral POV with fully built prototypes and finished code.

1. Everyone was co-located into the same physical area. This included the Agile scrum-master, product manager, developers, tech writer, and designers. There were a few folks in India but the company flew out folks for several weeks at a time so that at some point everyone saw each other at least once a quarter for a sustained time period.

Being physically together is so critical to improved collaboration, communication, clearing up mis-understandings, whiteboarding on the fly, and of course, social bonding. Great teams require great chemistry, and knowing how to tap into each other’s rhythms. Also being together forced us to view the story list together, burndown charts, etc. Everyone is alert, focused, and “on-notice” in a sense. Overall just creates a nice vibe of being a true team with a common cause.

2. PMs and Dev leads were forced to learn Photoshop and create some mockups. No joke. Andrei had everyone commit to using Photoshop as the tool of choice for producing crisp pixel-accurate comps and final visual assets. This was decided upfront to eliminate ambiguity and mixing of file types, etc. Want good design? Gotta establish clear tools! In addition the non-design folks (lead PM and Devs) had to learn the tool to empathize with the issues of, say, making an icon or adjusting a layout so they realized how difficult it can be and the levels of impact.

Key Benefits: We never heard “can you just make a quick icon” ever. PM/Dev leads adjusted the stories and sprint cycles in recognition of the design time required for research / exploration / iteration / production. A far more sane, productive sprint cycle overall for designers and devs too. A happier collaborative effort overall. No feelings of being shoehorned into code-centric cycles.

3. Designers tried to stay ahead of the dev stories. This was key too, getting the designers ahead of the devs, to keep iterating on designs and buy time for exploration. Else the result would’ve been the force-fitting that drives designers crazy! More appreciation across the team for a continuous design process too.

4. Revisiting designs were part of the process. Everyone on the team recognized the need for revisiting designs as needed, per feedback internally or from informal user validation studies. This was factored in where possible, again thanks to that empathy for design fostered in PM and Dev leads.

5. Everyone was co-located in the same area :-) Just to iterate that point. It’s a HUGE benefit to have everyone in the same place talking and sharing and arguing and sketching together (at least ambiently aware what’s going on).

6. We had lunches together. Sounds very minor but it’s actually a positive social bonding element. Builds up the team chemistry and of course, those “water cooler” chats about design and dev problems, in a less intense situation. Openness of discussion in a non-threatening context is key! The sprints are intense periods of activity, so you need those down moments of casual conversation for what really matters.

7. We shared research findings and user validation results at our stand-ups and factored them into the stories, design changes, etc. So there was total visibility to everyone of what’s going on from that side of the project and it was given the appropriate level of importance, at stand-up calls.

1 comment

Recent posts

Older Posts

Let’s go meta