Editor’s Note: This blog post was originally written in September 2012 for my old blog. Unfortunately, that blogging service is now defunct. So I’m reposting it here, but I plan to do a bit longer series on agile design, so this is now just “Part 1”!
Agile software development is one of the big buzzwords that has many companies quickly trying to change the way they do business. As designers, we are often challenged to figure out how to function in this new agile world. Having been through the “agile journey” at various points in my career, there are a couple ways in which it can be handled. Read more after the break.
One important point to keep in mind. Agile development is an implementation methodology, something that is meant to help you build things (and who doesn’t like building things). As long as you understand that the purpose of agile is to help implement things, then the rest is quite simple.
So, as I stated, we designers have basically 2 options, and these are in no particular order.
Option 1 – DO NOTHING DIFFERENT
Remember what I said about agile being an implementation methodology? Implementing things and designing things are not the same thing. Let me repeat this so that it’s very clear. Implementing things and designing things are not the same thing.
There is a type of design activity that is not necessarily geared towards implementation. Some would consider this the design phase vs. the production phase. The names are ultimately not important. But what is important is that the class of work that we do as designers, to understand what to ultimately produce, that might not fit within a 1 or 2 week sprint, so don’t try! Essentially, do your design work outside of the agile method.
What I’m talking about here is all the research that goes into developing a concept. You might need to do some small informal usability studies to help guide the design process. There might be some heuristic analysis involved. Maybe some competitive research. Whatever it is, it actually takes some time to complete and you never really know where your research will take you. So why try and cram all this useful investigation into such a short period of time? I’m not advocating a 10-month research project with no deliverables. But delivering on customer needs takes time to do effectively, and without that research, what good is cranking out a bunch of features that don’t align with your customer’s needs?
And once you’ve completed the research phase, then and only then can you start thinking about the production of mockups to help the implementation process begin.
The benefit of doing things this way is you get a much more holistic view of what needs to be accomplished, which is really important when designing/building interactive systems. The drawback is it takes time, and usually, upper managers don’t like things that take too long…
Option 2 – Do a “Sprint 0”
This is perhaps the most common way for designers to support the agile method. We in the design industry all agree that the design phase should preceed the engineering phase. This is to minimize the re-doing of earlier work as much as possible.
The basic idea of the Sprint 0 is to keep the design phase prior to the start of implementation, but focus the activities on “just enough” stuff that’s needed for the subequent implementation sprints. There’s nothing innately wrong with this method, but all that you’ve effectively done is made smaller, shorter scale waterfalls (waterfalls, as in the waterfall method).
The benefit of doing things this way is that your design work is instantly fed into some sort of implementation sprint which is very much in line with the concept behind agile development. The drawback (and it’s rather large to me) is that by only designing things in a very narrowly scoped way (because you only have 1 or 2 weeks, remember?), you might miss out on the big picture, the holistic design sense that helps a system feel unified. Sometimes engineering teams need this holistic view to help them accomplish their tasks for the sprint. And if you don’t develop your holistic design as a true Sprint 0 method would have you do, then the implementation sprints run the risk of iterating wildly away from the intended target.
So now what??
You might be wringing your hands because you have to start working in agile and you don’t know which way to go based on what I wrote here. But don’t fret! There is actually a hidden 3rd option!
Option 3 – Pick the Appropriate Method to Suit the Situation
Why does it have to be a world of absolutes? Why does it have to be Option 1 vs. Option 2? The thing to consider in this scenario is that there are projects of all shapes and sizes. Not everything will need a long, protracted research cycle (too much research can drag a project down too). Option 3 is all about adaptation.
For the projects that require more careful thinking and perhaps more importantly, market data, you might actually want to run them under Option 1. And for the small stuff, that may not matter greatly, you might want to run them as Option 2. You will need to quickly identify whether the project warrants one way versus another, but you don’t have to apply the same methodology for every situation. In fact, I wouldn’t. Be a little more free-form. Negotiate with your project stakeholders about when to use Option 1 and when to use Option 2. This way, you get the best of both worlds, some projects where you can devote your best creative ideas, and other projects that you crank out to meet your “Time to Market” requirements.
That’s about it for the background on designing in agile. There are 2 big options for designers to work in the agile process, plus 1 hidden option… Though I must admit, I did not get into much detail here about how a Sprint 0 actually works. Over the coming weeks, I intend to write more on this topic. This is really just the beginning. If you have any other thoughts on this topic, feel free to post away in the comments below!