Please listen to the attached soundtrack whilst reading the following.

Agile really likes to focus on iteration. For a lot of developers, this is code for biting off small, manageable, deliverable chunks. Small, manageable, deliverable chunks is not necessarily the same thing as iterating on a design.

They can be the same, but they aren’t necessarily the same.

Regardless, this means the current state of your product is not the same thing as the envisioned state. This is true for almost every product development process, but agile can make this more of an issue.

How iteration works in the agile process

One of agile’s tenets is that you release small changes to a product frequently, instead of major releases less frequently. The agile sprint is a cycle as short as two weeks where the team is supposed to develop, test, and release a feature in its entirety.

Say you wanted to add forums to your site. By itself, this might take three weeks worth of work. A small, manageable two week task might be to add a way for users to register their email address. At the end of the sprint, the team would expect to release the next version of the product that includes user registration.

On the next sprint, developers might release the back-end updates necessary to handle the forums, and two weeks after that, they might release the front-end interface that allows access and participation in the forums.

During these three example sprints, everyone knows the ideal state: forums on the site. And each sprint moves you closer to this ideal state.

However, iteration requires two corollary management tasks. First, you have to communicate the ideal state to the team. Everyone needs to have the same shared understanding. Second, you need to track the gap between the current design and the ideal design.

Communicating the ideal state

I’m totally thinking “this is why we crank out wireframes”.

To clarify for any non-UX people reading this, drawing, annotating, reviewing, editing, reviewing, approving, communicating, and clarifying wireframes is not the sexy part of the job. Sure, some people really get off on that sort of thing, and I make a point to wear fishnets any time I open Visio, but most practitioners do wireframes because they have to so they can communicate the shared understanding of what the product is supposed to be.

Let me be clear. Deliverables are not teh sex. Teh sex is what leads to the deliverable. (Someone—who shall remain anonymous—put it this way: “Toddlers are awesome. Poopy diapers suck. Wireframes are the poopy diaper that happens after your toddler has eaten a great meal.”)

Of course, this doesn’t have to be a 500-page spec. Doesn’t have to be wireframes. But it has to be something. Even a photo of a whiteboard session that everyone has access to can work. Whatever it is, it has to be something.

Minding the gap

You can’t mind the gap unless you have two sides to point to. One side is the current version of your product, and the second side is the idealized version.

While your agile team is iterating on the current state and marching towards the ideal state, someone has to keep track of what has and hasn’t been built. This seems silly. I imagine agilists saying that the smart, unfettered, goal-centered team members will manage the gap.

Sure. I suppose they could. In my experience they don’t. Nothing against them. I’m one of them. And even being heavily invested in “my baby”, I’m not minding the gap.

This ties into my post on parallel work streams where I mentioned the sprint support role that’s emerged at Fancast. Everyone is busy doing something. Engineers are developing. IAs and designers are designing. Product’s reviewing, tweaking, and iterating. It’s really pretty awesome.

But, if a feature is limited so that it will fit into the current sprint, all of a sudden you have two features. You have the edited version being built, and you have the ideal state you hope is coming. If the functionality is different, you need two shared understandings: one for now, and one for later.

Now stay with me. We’re imagining rolling sprints. This sprint, a small portion of a feature, an edited version of the feature is built. Next sprint, you build the next version. Or maybe you don’t. Maybe the iteration isn’t as important as launching another small feature.

Agile lets you turn on a dime, and you’ve just turned. The ideal state falls into that ghetto, the sprint backlog.

Who remembers that ideal state? The team’s busy with something else now. And what if you’ve got really lean documentation? There’s a gap in organizational memory. And it’s not minded.

Dirty laundry. Look away. Do not read any further

Here’s a dirty little secret from where I work.

Let me set the scene for you. Engineers? Rock stars. Seriously. In the IA group we have engineer love-ins where we talk about the engineer we’re crushing on this week. The product team? Fucking brilliant. Seriously. They just get it. Everything. And the IA team? If I may say so myself: fucking awesome.

(And, no, I am—by far—not the only IA on the team. But, for the record, the entire IA team at Comcast Interactive seriously kick ass.)

So here’s the dirty secret. Back in September we wireframed a new version of the preferences section. In October we “iterated” on the first wireframes, which really meant they were totally redone. Each time, they were bumped off the next sprint by other things.

We’re redoing the wireframes a third time right now.

It’s not the people who are the problem. We’ve got good people. And it’s not the project. The prefs aren’t particularly sexy or ground-breaking. We just don’t mind our gaps very well. Or at all, really.

But if you’re doing agile, you have to mind your gaps, or you’ll forget where you’re going. Heck, if you’re moving really fast, you’ll forget what’s actually made it on to the site.

Talk About "Agile + UX = idealized vs. current state"

Register or Log In to comment

Crystal Kubitsky said:

Brilliant, Austin! I couldn’t have articulated the scenarios and observations any better. Our team’s really are similar in this respect and there’s much we can learn from each other!

Tue, Apr 08, 2008 at 03:23 PM

Jon Moore said:

Hey, Austin. Very interesting; there are definitely analogs on the engineering side, where we make some compromises to get a feature out the door. Most of the time we try to shrink feature scope rather than sacrifice code quality, which contributes to the gap you mention. Sometimes, though, we jam a feature in, even if it’s not *exactly* the right way, and then we’ve created an “engineering gap” for ourselves.

We actually track this by maintaining a “tech backlog” and we try to tackle a couple of these things each sprint; perhaps there could be an IA backlog of gaps. If product is into it, perhaps a small amount of each sprint could go into reducing the IA gaps, just like a small amount goes against tech backlog. At the very least, the gap could get documented as a new user story, with the idealized vision virtually stapled to it, so that it doesn’t get forgotten. Probably ought to be part of the sprint review, although if we’re doing the collaboration right, we ought to be able to write that story as soon as we realize we can’t get the whole way there.

Sat, Apr 12, 2008 at 01:24 AM

Austin Govella said:

Hey Jon!

I found this great article from Jeff Patton on what he calls the “slow software movement’: * http://agileproductdesign.com/blog/slow_software.html

I think your focus on feature scope vs. code quality is really interesting. I prefer to prioritize experience or product quality. I’m more interested in the gestalt of the engineering + the features + the experience.

I feel like a lot of time, the project focuses on engineering or features, which makes sense, since they’re more concrete.

Frankly, the backlog is a ghetto. Things go in and rarely make it back out. There’s a lot of political pressure and shifting priorities that cause this to happen, so it’s not the backlogs fault, but that definitely means the backlog, by itself, isn’t a good answer.

We used to have the “IA bucket”. That seemed to work well. Maybe re-instituting the bucket would be a good thing? We used to use it for bug fixes, features, and design scrubs: all the “experience” things. And maybe there should also be an “engineering bucket”?

Definitely, we should write a ticket as soon as the gap appears. That’s an awesome idea.

Tue, Apr 15, 2008 at 01:01 PM

Jon Moore said:

Liked the “slow software” article. We’ve definitely started to go down this path somewhat, so I think there would be some traction with the team on this. This can be seen by trying to write our user stories to be end-user-centric (rather than ones that begin “as a product manager, I want”) plus I think our iterations are starting to look like “one big, deep, new feature plus a bunch of minor cleanup tasks.”

Re: backlog. I think the IA bucket was what I was trying to describe in my previous comment (I just forgot what we called it). We do already have the “engineering bucket” that gets filled by things off the “tech backlog.” Incidentally, the tech backlog is maintained by the engineers, so perhaps IA could maintain the UX backlog, and pick off a couple of things to suggest for each sprint a la the engineers and the tech backlog.

As far as the backlog being a ghetto, I think you’re right, but I also think this is a factor of having a very full roadmap of ideas and a fixed capacity for turning those into production code. Also, I think the gaps you’re talking about may not be all that bad—we may end up revamping or removing a feature before we get around to getting it all the way to perfect. To me, this is one of the benefits of timeboxing a sprint—it forces you to make the tradeoffs between have 80% now or wait for 100% later. And the choice isn’t always 80% now—just yesterday we had the product team push a story to the next sprint rather than implement a degraded version of it.

Tue, Apr 15, 2008 at 09:58 PM

Hot topic? Subscribe to a feed of this post's comments.