What we learned from Laura Klein’s AMA

During our “Ask Me Anything” with Laura Klein, author of Build Better Products, we touched on subjects ranging from how to define “agile,” whether “scope creep” is something we should really consider a mistake, to recommendations around how to scale an agile team. Read on for a recap of the session, and please join our Slack here to stay informed about when our next #rm-chat author AMA will be!

Q: Scope Creep is what you call a product choice that was a mistake, yet in every other scenario we would call it Innovation and Entrepreneurial. How do we manage that risk and maximize the possibilities? -Arpy D.

A: Thanks for the question. I’m sorry, but I’m going to have to argue with your framing here. I don’t think Scope Creep is a product choice that was a mistake. I think Scope Creep is what happens when we don’t really understand the specific thing that we’re building and we keep just adding things onto it. That has nothing to do with innovation in my opinion. Some of the most innovative products are very small and well scoped. Also, scope creep was specifically more of a pre-agile thing when features were 100% scoped and estimated ahead of time. Then, when we did a bad job of that (as we always did because it’s hard), we would start saying “oh, actually, it also needs to do x” and “oh, now that it does x, it won’t work without y”. Again, that’s not innovation. That’s just bad planning.

Q: What advice and/or book recommendations do you have on scaling product teams and ensuring they remain agile? Also, I saw you recently tweet about design in agile teams. Aside from your article any other recommendations on this topic? – Cynthia C.

A: The trick is that you need to be outcome driven for each of your teams so that teams can remain semi-autonomous. You also need to have a strong commitment to iteration. The thing I’ve learned from research on this is that There is no Agile! There are a lot of models to this. There’s the team of teams and dual track and scrum vs kanban and guilds/squads, etc.

Q: Do you have any insights or advice around how designers can work better on agile teams? -Adeline C.

A: I’ve been doing a ton of research on this.The extremely UX answer is that it depends. It turns out that when people talk about “agile” it actually can mean one of about a dozen different things, none of which are really terribly agile. Frequently, people introduce Agile because they just want to go faster, which can be really exhausting and burn-out-inducing for designers and researchers.

If you read the Agile Manifesto, it’s not that complicated. The problem is that it is very high level, and it comes out of a bunch of competing methodologies that have very specific instructions and rituals, and those often get very confusing (ie. kanban vs scrum).

Q: Do you see any reason not to go dual track? -Ben M.

A: Sometimes! First of all, I’ve found at least three different in the wild interpretations of “dual track” which makes this a hard question to answer. A lot of dual track seems to be aimed at developing (and validating) biggish new features. It’s probably overkill if what you need are small, incremental improvements, which is actually true of a lot of products. You also have to be careful that you don’t split things up as “this team gets to do cool new innovative stuff and this other team has to maintain our crappy legacy system!” But that’s more about your particular implementation of it, rather than saying you should or should’t use it. If you do use it, use it responsibly for the things it’s good for. The different types of dual track I’ve seen, by the way, are the ones where there’s a team that’s actually focused on discovery of new opportunities and testing out more risky new things vs one where ux and research are all on the first track. That second one is AgileFall, not dual track.