resources

Dual Track Agile

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Share on RedditEmail this to someone

You’re no doubt very familiar with Agile as a delivery methodology by now, and would even consider it a ‘way of thinking’. It’s an amazing technique, wonderful for developers, as it gets people out of their hair, and gets them focussed on coding what matters to achieve (hopefully) working software most efficiently.

It does have its challenges though, especially if you’re a UX or Visual designer. Developers are trained to think architecturally, in components, interfaces, objects, and conceive of ways these elements operate independent of eachother. Designers, however, operate in the subjective world and are trained to think of “the whole”. It was certainly what I was taught at ArtCenter, whether in illustration, graphic design, film, or user experience. Agile therefore is hard for designers to operate in. At simplest, they feel rushed when asked to produce an MVP.

“Knock out a quick design/UX for this and lets see what users do”

screen-shot-2016-11-29-at-13-25-51Unfortunately if you’re lucky enough for the users to like it, then the half-assed design stays. If users don’t, then perhaps it was because the design was half-assed. And the designers are all embarassed to show it to their design peers, since they didn’t have time to do it well.

  Dual Track Agile is a the answer. In addition to your Delivery Track, you also have a completely separate Validation Track. Items from your Validation Backlog now must go through Validation Sprints and receive a positive outcome before being considered for the Delivery track. You can validate in many ways, from surveys to interviews to prototypes, whatever you and your team agree indicates users will like it. Designers are far less likely to mind “knocking out a quick design” if they know its just for a test, not a live product. Strike the right balance between minimal effort and maximum validation. In addition to the validation, you’ll also learn a few things about how you ultimately want to build your feature.

In a disciplined way you’ve just;

  • Reduced the workload on the delivery team to things that user really like
  • Justified giving your design (and dev) teams the time they want to do the production version well
  • Increased the probability that your feature will succeed since you tested it first
  • Gotten rid of crappy ideas with a minimal amount of effort instead of wasting Dev time

Let me know how it goes for you!

Here’s a bit more of my work 

View all resources

Subscribe to our newsletter