Agile / Lean development is all the rage these days… and for good reason. It is a great way to come up with and release solutions much more quickly than how we’ve been working for years. And the best part for UX designers is that no solution is ever “final”… iteration and change is a key component to the methodology which allows us to receive feedback on our designs and continually update them to be better. Seems like a perfect world right? The problem with Agile, for most UX people, and for companies, in general, is that they are not aware that there is a step, a very important one, that comes before they can even jump into the Agile mix of things. That step being creating and agreeing on a product / UX strategy for what needs to be designed and developed in the first place… or as I like to call it, discovery and scoping.
Not being aware of the need for a agreed upon strategy can cause several issues. The most common one that I have seen is that people jump into Agile expecting it to solve all of their problems. We’ll just take some ideas, write them up as user stories, throw them into the “hopper” and Whammo!… Agile will get them out the door quicker than before. Often though, this method fails. Either the UX team is unable to design “quick enough” because they are not given concrete, research based ideas to design to and iterate on, thus “slowing down” the entire development process. Or the development team is unable to release due to bugs and/or incomplete use cases, thereby not having even a beta product to release “quick enough”. There are tons of ways that this method can fail, but the problem occurs when people blame agile for the failure, and not their lack of planning and decision making.
Taking the time to come up with a strategy for what will be build is a very important, if not the most important, step for successful development of any kind especially in Agile. By interviewing and observing user behavior as well as analyzing the feedback on a current product or new product idea, and taking that information to infer future user needs and behaviors, we can create product road maps that map to our users’ goals and tasks. UX should be a part of this step, and should help lead people through the discovery phase, as it is our job to keep our eyes on the prize, which is, of course, the experience of the user has with our product or service.
Creating a product road map (or experience road map if that terminology is more comfortable for you) allows us, as a team (UX, business and tech alike), to sit back and prioritize based on business need, user need, and technological complexity, thereby bubbling to the top the most important features, and exposing the rankings of the remaining features. After prioritizing, we now have a list of what should be designed and developed, and when those features should be developed, which we then use in our agile development iterations to keep things moving as smoothly as possible (this is software development, we know it’ll never truly be smooth :-)). Also, by keeping in mind that your strategy will iterate and change based on changes in the competitive market, user feedback, technical updates and innovations, one should anticipate constantly updating the strategy, in order to amend to these changes.
Thus, strategy (and prioritizing and scoping that strategy) has a big place in the agile world. Creating and adhering to it, as well as updating and changing it allows us to have a successful agile design and development environment. By taking the really big, goal changing decisions out of the execution step, aka the agile environment, and putting them in a different environment (although closely related and perhaps having the same groups of people) we allow agile to do what it is intended to do, design and develop the features that the user needs in a quick, efficient way. Agile was never intended to solve all the problems of the design and development world, rather it was intended to make the execution phase of this world more efficient, and pulling the strategy & scoping decisions out of this phase and defining them prior to the start of this phase, help to clear up the confusion.
So, before you decide that agile is the way that you are going to go, take some time to think about what you are really trying to put out to your users, but also to determine what problem you are trying to solve by implementing a new design & development methodology. Discovery, as well as scoping and prioritizing based on discovery, is, in my opinion, the most important phase because that is where we will find out what problem we are trying to solve for our users. Then we have a clear vision of the goal of our design and development, and we can execute that vision with a clear mind. Agile will not solve all of the problems of the world, however by planning, and doing the proper upfront analysis, agile can help release the solutions quicker, can save money for, and can bring pleasant and enjoyable experiences to the people that matter the most… our users.