In my last post, we just began exploring the idea of agile design.  The quick conclusion was that there are significant similiarties between design and development as creative processes.  Agile thinking can be effectively applied to both.  The big question is about specific implementation.  How would it work?

There are two ways that I have seen agility applied to design.  For lack of better terminilogy, I’ll call them the:

• two-wheel approach
• one-wheel approach

Let’s start with a quick explanation of what each wheel means.  The two-wheel approach treats design and engineering as two separate teams (or even two separate organizations).  In the two wheel approach, the both teams are working iteratively to push ‘shippable deliverables.’  For designers, it would be shippable designs.  And for coders, it would be shippable code.

The natural progression of work tends to be that the design is done before the development.  As such, the the design iterations generally drive the development iterations.  Once a design product has been marked as solid enough for implementation, it is ‘completed’ in the agile design cycle and it marks the beginning of an agile development cycle.  The lengths of the iterations don’t have to be the same across design and development.  In fact, I’ve seen shorter design iteration length have a better chance of success.

The one-wheel approach is primarily different in that it treats design and development as one ‘product development team.’  This is a cross-functional agile approach for which there is very little precedent.  In this approach, the team is all pushing towards one shippable deliverable together, and each person is doing their part side-by-side with folks of other disciplines.

In the one-wheel approach, the work is not as cleanly sequential.  What ends up happening is that some work is sequential, other work is parallel, and a lot of work ends up happening in mini-iterations within the iteration.  For example, a designer may produce a mock and pass it to a developer, but can be involved in ensuring that it is implemented in a pixel perfect way by the developer on the team.  As the developer has real-time feedback, the designer could very quickly re-mock and pass the mock over again.  As the UI of the app increases in fidelity, the designer can start producing unforeseen assets like icons and other images that are implemented downstream.

Of course, the million-dollar question is: which approach is better?  The honest truth is that I don’t know yet.  I have used both and have seen pros and cons to each.

The advantages of the two-wheel approach are:

• Much easier to do when teams are distributed.  (Even moreso if they are distributed by function.)
• Enables cleaner divides in the organizational structure.  This is particularly useful if your organization is already entrenched this way.
• Easier to implement from a complexity and organizational change standpoint.
• Potentially more efficient in terms of people working on the thing they are skilled at all the time.  (Little to no downtime.. and designers are always designing and coders are always coding.)

The advantages of the one-wheel approach are:

• You get more happiness and buy-in because everyone is involved in the final implementation decision.
• When velocity really matters (you are under the gun), the micro-feedback cycles of a cross-functional team are significantly faster.
• Potentially better outcomes from having diverse viewpoints at the table.
• Potentially more scalable.  Having many cross-functional teams scales more cleanly than bigger and bigger functional teams.

What I am trying to figure out now is: are these approaches more or less appropriate for different circumstances or phases of growth?   I, unfortunately, don’t know the answer yet.  Of course, if you are not in a startup or not in a position to mold the structure of your organization, then the constraint of organizational structure can drive your decision.  (Most of the time, that will drive you to the two -wheel approach.)

The one-wheel approach has some potentially large benefits (like better product outcomes and more buy-in!), but it takes a lot more organizational buy-in.  Cross-functional teaming can be very complex to implement, particularly in organizations where different leaders of different organizations have strong visions for ‘how things should be done’ in their world.

I’ll try to report back after I know more!