Menu

agile

UX and Agile – A glimpse into our process

, 0

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.

Applying Lean Startup Methodology toward PhD Studies

, , , , 6

So, while staying up late to do a paper for class (yes it is spring break, PhD students never rest!), I got this wild brainstorm of how to apply both my development training (I work in an agile development environment as a UXD), and the lean startup methodology I spent all day hearing about at SXSW toward my PhD studies. Below is what I quickly jotted down (instead of writing my paper) as the clock turned from 1am to 3am due to DST.

Agile Development – As in, how to quickly get started and iterate on a project in order to get it to releasable state as fast as possible.

I believe the biggest problem with most of us PhD students is just getting started on that damn 20 page paper or huge research project. Why? Because we don’t know how to begin. Well, who says you need to start at the beginning? If you know that you can knock out a section of your document faster than the others, why not start there then move on to the next fastest and the next fastest until you’ve reached the one part that will take you the longest and now it won’t take so long because you’ve already written the rest and it all applies to what you have left!

MVP: Minimum Viable Product / Paper / Project – What’s the least amount you can get away with? As in, what can I do to make a C? Then, what do I need to do to make it better in order to get an A?

Do what you need to in order to fulfill the barest and most minimum of requirements of your assignment, then build on it. At least at that point you know you’ve touched on every point the professor asked of you, and now you’re going above and beyond.

Or – how to quickly iterate on a paper. Write out a bunch of crap for a paper even though you know not all of it will go in, because you know at least some of it will and you just need to get it typed out. Then, you go back and cull it down to something respectable and focus just on that one thing rather than the overly broad dribble you spewed out to begin with.

Pivot – Change in direction after gaining valuable information

Ever get to that point in your research where you go – “damn it, now that I know more I should really go in this direction instead of the one I originally intended!” Go with it! Change the entire direction of your paper/project it even if it takes more research. In the end your final product is so much better than it would have been had you gone on your initial assumptions without exploring your research further.

Business Plan Vs Business Model – Paper/Project Plan vs Paper/Project Model

What’s the difference? One you’re following simply because you’re told that’s the way you’re supposed to do it (plan). The other you’re modifying and iterating on until it fits your paper/project needs (model). Both give you something to start with, it’s just one is a lot more versatile than the other. You end up with something much better when you can improve upon it rather than sticking with something just because “that’s the way it’s done”.

Metrics – Quantify your results

I figure for us PhD students this plays out in figuring out the least amount of time you can spend on something and still get an A. By keeping track of the time you spend doing each part of the task for each project you do until you know with certainty how long it will take you to nail that paper/project you can then plan accordingly and be not only much more efficient in your work, but also be a lot more engaged in it because of your confidence level and high ROI.

It isn’t a finished piece of work, but hey – I got it out as fast as possible and I can always iterate on it later – especially if I get feedback from readers! So tell me what you think. 🙂

As always you can find me @sollitaire – or email me diana [@] cyber-anthro.com.

Back To Top