Thinking and Making: Comments by Jon Moore

Jon Moore — Sat, 12 Apr 2008 05:24:51 GMT

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.

Jon Moore — Sat, 12 Apr 2008 05:32:36 GMT

I think what you’re describing is a skillset bottleneck—not enough “UX” folks to go around. Classic agile solution is to have other members of the team (engineers, designers, product folks) pick up some of the simpler tasks, with UX review/guidance, and let the true UX folks focus on the hard/new stuff. On the engineering side, for example, we have backend engineers do some minor frontend work when our frontend guys are overbooked, allowing them to do all the crazy CSS styling stuff.

Do you think that kind of model would work? I’d imagine after working closely with a set of designers/product folk/engineers they would catch onto your style and tend to come up with an almost-there solution that could be quickly reviewed and tweaked.

Jon Moore — Wed, 16 Apr 2008 01:44:01 GMT

Well, at the very least I’d suggest throwing those requirements out on a wiki somewhere. If the generic requirements can also be elucidated with examples (and anti-examples!) then that might go a long way towards helping educate. Also don’t forget the “why” on these requirements—this is one of the easiest ways to motivate the requirements but it is often all to easy to leave them off (incidentally, this is why I think user stories which explicitly state the value they are extracting are great).

After that, I’d say it’s probably just a continual process of interacting with team members, and referencing the wiki docs when you do—“teach the team to fish.”

Jon Moore — Wed, 16 Apr 2008 01:58:49 GMT

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.

Jon Moore — Wed, 25 Jun 2008 04:03:24 GMT

An interesting question we often ask is: “would you launch this compared to what we currently have in production?”

Sometimes it’s enough to just be better than yourself. :)