Awesome presentation last night by Carbon Five’s Courtney Hemphill for BayALN at Adobe’s offices in San Francisco.

It was really magic sauce for those like me who have struggled to get design integrated an Agile development workflow.

To understand why this preso is so significant, consider: Agile adoption for software developers has been prevalent for a number of years now – but standard methods for integrating a design workflow into Agile have been trailing.

A common approach seems to be contained in a May 2007 whitepaper by Autodesk’s Desiree Sy, which suggests a staggered workflow with designers and developers on separate tracks:

I grant that this type of workflow could work, and probably beats the traditional waterfall by a longshot. But in having been participant in this sort of structure in previous workgroups, I can report it feels in need of improvement. Designers were not pairing with developers due to this structure and cultural walls went up. Two weeks sprint cycles became de facto one month sprints, pushing risk up. The separation of design was often derided as “tossing over the fence” — and is in practice a mini-waterfall: the exact thing we were trying to evolve from by adopting Agile.

The issue has been debated on stackoverflow, with the top response proposing the staggered workflow of the whitepaper. This earned the rejoinder:

I strongly disagree with the answer provided by Jason. The whole point of Scrum is to get rid of the method where designers first “do their thing” and then go on to other stuff. That’s completely and 100% against all lean / Scrum principles!

Well then how else could you structure your workflow?

Enter Mixing LeanUX and Agile

The whole deck is worth a review — do yourself a favor and take 10 minutes to at least glance through it right now.

And though it may not be magic, it might be a tonic: Don’t toss over the fence. A primary takeaway is the stepping away from a traditional design team and pixel-perfect design up front, and relying on more communicative, integrated, cross-functional teams.

Also mentioned in the talk but not in the deck

• They typically run 1-week sprints.
• Smallest team is 3 — dev, designer, product manager/engagement manager.
• They don’t have a dedicated scrum master.
• They do a lot of pairing and joint white-board to avoid “over the fence” issues.
• They use a design charrette (http://www.questionablemethods.com/2011/11/design-charrette.html — that’s the name of the blog…it’s not actually a questionable method… — actually, Mike Long does a great intro to the charrette at his San Francisco LeanUX meetup.
• No traditional heavy-wireframing or pixel-perfect details. Sketch it on whiteboards. (I’m assuming C5 relies on the Lean Startup opinion that functionality tends to trump prematurely optimized design, and focus on precision in design later)
• To enable velocity, they have a design AND development vocabulary ready to go.
• They have a balanced team approach that eschews traditional designer, developer and manager roles in favor of concurrency. In fact, it appears they’ve just had a conference focused on balanced teams.
• They have a concept of cadence, which dictates the following must-dos:
  • Monday — TEAM Retrospective
  • Friday — CUSTOMER meeting with product, observed usage.
• Estimation requires that they scope things down to have 1-week deliverables.
• Typical engagement is 12 weeks, upwards to 1 year.
• They do a sprint 0 (first week). First customer involvement is after week 1, two weeks after kickoff, which is still pretty fast.
• Disappearing boundaries for team members — developers design a bit; designers understand code, everybody is cross-functional.
• Much direct involvement with the client.
• They involve the customer in hybrid prototyping where they use cutouts of the existing product UI and have the customer help with the design.
• They use Rails Cucumber-style Behavior-Driven Design (BDD) language to capture stories.
• They setup strong story acceptance criteria.
• They’ve used this methodology for things that don’t seem inherently design-oriented, like a SAAS product.

It seems that the Carbon 5 method requires a fair amount of prefacing

• Client needs to drink the kool-aid. Where do they find such clients and how do they on-board them?
• Traditional design culture is pushed aside a bit (“Get out of the deliverables business” is a LeanUX mantra. More on this in other posts…).
• In acceptance criteria, how much is satisfying the client’s vision vs. satisfying the client’s CUSTOMER’s vision?

Some questions I didn’t have the opportunity to ask

• In an engagement of this sort, does the team require a design spike? It seems possible to steer into a local max with fast, iterative feedback. Also, story complexity may necesitate spikes. True?
• Lean Marketing calls for tools like split testing of a product. Often, the trend of a preferred product feature will not emerge until there’s a sufficient audience sample, which could take weeks. How does the methodology account for that?
• The impression I had is they were primarily working on “green field” projects so they didn’t have to deal with legacy (and probably the associated company politics). Does this method lend itself more to startup clients, less so enterprise clients?

In any case, I’m intrigued by the continued innovation and creativity of Carbon 5 and to have more of a conversation with leaders in the LeanUX-Agile community in SF.

What should you do now?

• If you’re Courtney Hemphill and have read this far, please post to the comments below and dispell any misunderstandings or illusions I have. Thank you Courtney! See comments below.
• If you’re somebody else who works at Carbon 5 or another Lean/Agile group, I’d like to hear about issues of adoption or problems with these practices.
• If you work at Autodesk, I’d like to know if you’re using the methodology explained in the white paper and whether it’s been successful or not.
• If you work at different design, product dev firm or agency, I’d like to hear what your methodology is and how it compares.
• If you’re not already familiar with LeanUX, or have light familiarity with it (“oh yeah, I’ve heard of that before…”), check out this classic Smashing Magazine LeanUX article .
• A couple of O’Reilly books on LeanUX have recently been published:
  • Lean UX Applying Principles to Improve User Experience, and
  • UX for Lean Startups: Faster, Smarter User Experience Research and Design

Thanks for reading, and please comment below.

edited November 15, 2013 2:21 PM for clarity