UX and Agile – A glimpse into our process
So, I know this has been a widely written about topic from multiple sides of the equation. I have to say though, if there is one thing I’ve learned from Agile – and from Organization Behavior in general – there is no “one best way” to do anything. That said, I’ll give a short explanation of our version of Agile, what I do, and how I work within our Agile environment as a UXD.
Let’s talk about Agile:
Agile is defined as iterative incremental development methodology. What? This means the product we are working on has new features and bug fixes released, in our case, every two weeks. Everyone involved in the process works together within those two weeks to make it happen from graphic designers to quality assurance testers. This is different from waterfall where the discovery, architecture, development, design, testing, and release phases are all very separate from each other, happen in a specific order, and in the end the product is “final”.
While that may not sound revolutionary by any means, people moving from waterfall to agile tend to have a rough start. Biggest reason why? Things change, nothing is solid, it’s not final, and the team needs to be agile enough to roll with the punches. Let’s put it this way, I haven’t seen a statement of work or product requirements grid for nearly 4 years and I’ve never been finished with a project.
That brings us to the next part. What is it that I do?
User Experience Design:
Well, my official title is User Experience Designer (UXD). In short, I design user experiences.
So, what is a user experience? A user experience is what the user sees, feels, hears, touches, uses, understands, believes, and comes away from any application with. This means I’m a bit of a business analyst, information architect, interaction designer, art director, user researcher, usability expert, heuristic reviewer, and decipherer of languages of developers and business processes past.
But, what do I actually do? My main function is to do all of the above to create wireframes and application requirements from which developers take direction and create an application. Then I go through continuous reviews and revisions throughout the development cycle with the developers where we have to make changes and compromises due to time, resources, and hardware / software (API) restrictions that do not surface until we are already neck deep in the iteration. During that process I’m researching features for the next release and working those into wireframes which include processes and interactions that are then translated into stories. Let’s just say where people normally have peaks and valleys in their work, my work tends to run at a constantly high level.
Our Agile Process:
The other part of the Agile process is the use of stories and tasks by the developers which help direct how they spend their time and what they spend their time on for each iteration. A story is basically the development requirements for each piece of development occurring during an iteration. Each story has a set of tasks and subtasks that developers then divvy amongst themselves. Each story / task / subtask has an amount of time the developer thinks it will take to do, then as they work they report against it the actual amount of time it took. This gives us an idea from iteration to iteration what can be accomplished by the team given the tasks at hand. This helps for planning and keeping the team on task.
Our original process included a meeting to come up with the stories based on the wireframes for the devs to follow. This meeting was important because the stories had to be understood by the developers and had to capture all of the specific dev particulars that a wireframe doesn’t necessarily convey. After that meeting there were meetings to decide tasks, subtasks, and time allotted for each.
Getting Agile with Agile:
During the last two iterations we’ve change it up a bit where I wrote out the stories while I was doing the wireframes and we now use the story meeting as a brainstorming meeting for the devs. This was an important change which allows the developers time to actually collaborate together on the thinking part of development rather than just banging away on their separate pieces of code. It also makes the meeting less mind numbing and monotonous as they actually get to throw ideas out there and bounce concepts off of each other whereas before they had no time to do so. While there are specific Agile processes, we go with what works and the best part about that is it allows us to be agile with it.
There you go! Not the most earth shattering ideas or methods out there, but I think it’s always nice to document what works and to share what you can when you can.