Lean(er) development strategy — A conversation with Anna Goodman from Gusto

Anna Goodman is a software engineer at Gusto and works alongside Kent Beck — the inventor of Extreme Programming (XP) and one of 17 signatories of the Agile Manifesto.

It all started with me dropping a question to Kent Beck (@KentBeck) on this tweet

To which he tagged Anna Goodman (@itsannagoodman), and to my surprise I got an instant reply and soon it converted into a very useful twitter thread. Since it was getting a bit hard to follow, I’m compiling the discussion with Anna here to make it easily digestible for everyone.

TL;DR

• Go away with iterations and sprints — talk in terms of weeks.
• Plan for the stuff that is most important right now and never plan to full capacity.
• Plan on weekly basis i.e. work on items that are most important to do this week.
• Be deliberate and specific about focus — communicate what your team won’t do.
• Try to avoid keeping a (huge) backlog — or any backlog if possible.
• You don’t always need a sophisticated task tracking tool — Google sheets can work as well.
• If a task is more than a week long — it doesn’t go into planning — unless broken down into smaller chunks.
• Estimates can be wrong — don’t go overboard with them — you’ll get good at them eventually.
• Let the team sign up for work they want to based on availability and interest. Try to avoid assigning the work to them. 1-3 people can commit to each work item.
• Do lots of pairing.
• If there’s a hard deadline to build X — drop every other thing that’s not on the critical path to building X.
• Think about what kind of visibility you want to give to business people — can we come up with something that is more honest and fills the need?
• In certain situations, an attempt to affirm an estimate would range from best guess to outright lie — instead, focus on the path i.e. where are we headed and this is how we are going to do it.
• Add cross-functional people directly in the team so they are able better work on prioritisation, planning and execution.
• Remember, if you get a LOT of work done, it is the best thing for the business.

Full conversation

Q: I’d like to know more about week-based development approach. Anything that you can point me to? A book or something?

Anna: This is how my team works, what questions do you have? It works well for us: a) we surface & agree on what's important to happen right now, b) you sign up for work that interests you, & c) we finish more & don't have as much rollover as planning to full capacity.

Q: I had questions specifically around how the team decides what it “can” do. I have a rough mapping that tells the “size” of a work item. I see you sit together for a) and b) in each iteration.

Anna: It's a good question. Do you mean in terms of "how do you tell what a team is likely to accomplish in a week, given sizes of tasks", or "how do you decide what a team can do overall?" (and we mostly sit together for c) also, lots of pairing)

Q: It’s the second question. What a team can do overall.

Anna: That's either a question about focus or about scope, or probably both. Most teams probably can do anything given resources; no team can do everything, especially not all at the same time, or with fragmented focus. Be deliberate and specific about focus, so that you can clearly communicate what your team won't do. If you don't choose what ball you drop, it'll choose for you.

Q: Also, is there a work structure that is followed? What’s the granularity level of the work the team commits to? Does the work get broken down into some kind of todos after it gets committed? How is the progress tracked?

Anna: We only introduce structure/process that serves us, which means there's not a lot of either (can talk more about what we do/don't do, most of it is in the "don't do" category). We track status on tabs of a Google sheet w/ "todo", "in progress", or "done", no backlog. Granularity has evolved & flexes; nothing larger than about a week goes on the planning sheet. Try to keep it small if possible, but sometimes list themes/impacts instead of "make X button do Y thing". Breaking into smaller tasks depends on preferences of the pair working on it.

Q: “Larger than a week”, without doing estimations, I guess it is based on intuition/experience, right??Also, what’s the (sub)team size that gets each work item? I guess it’s 2-3 persons assigned to a single work item.

Anna: Exactly, and if we get it wrong we get to try again the next week. You get in a rhythm of it, and if you over-commit you sign up for less the week after. "gets"/"assigned" == "signs up for" each work item, it's a combo of availability and interest. If a large percentage of the team is interested on one thing, we'll all pair together (seriously). Most of the time it works out to 1-3 people signing up for each thing, and people hop between things as makes sense, given how the week is progressing (i.e. if some things need more eyes).

Q: That's very interesting, more like a just-in-time (JIT) commitment. Usually, the business side likes to have a quarterly roadmap of the stuff they wanted to be built. With JIT approach, how does ur team give confidence to biz team about the stuff that's coming in future?

Anna: There are very, very few times where I think it makes the most sense for biz to come to EPD with a roadmap fully formed and say "this is what you're going to do this quarter, cool?" without more of a back-and-forth conversation.

However often you're thinking, less than that. Usually, I've seen this play out more like a "here's a list of things we think we want built, here's why we think we should build them, let's talk about them". If in [priority] order, I can tell you "we'll do that one, then the next one, then the next. If I'm clearly communicating about how we're doing as we go down that list, and we've all got flexibility to adjust when priorities change, or when more important stuff comes up, we're good! Team's always making progress on the most important thing, things are getting built.

Now, if there's an actual out-in-the-world real, true date you need to hit, this looks a bit different. I'm talking healthcare open enrollment date, tax filing deadline, you're building the scoring system for the Olympics, idk. I meant what I said when I said most teams can do pretty much anything given resources, but time is one of the most valuable [resource]. If you don't have time, you absolutely need focus, and the people calling the shots on focus should be the ones building. Ideally you get both, but you don't get to pick the date of the Olympics. Now, if I'm building your Olympic scoring system, I'm dropping everything not on the critical path on the floor, unless it gets me to that scoring system faster. If you can call what you drop in the air before you drop it, even better. Things can shift more globally where we all get to reprioritize our balls in the air and make sure that the really important ones get caught by someone else, and we drop/punt less important things. And if you're on the biz side, and you ask me "what else are you gonna do, other than the Olympics? We have these other things we want built", my answer will be "talk to me after the Olympics" because almost everything can shift in the meantime. We're back into guess/lie territory.?

Q: What about estimations and predictability for business people?

Anna: What will you do with the estimations and projections if I were to give them to you? and where are the deadlines coming from? Points in time that dictate our ability to cycle a feedback loop are the ones we care about. My team does tax filings, so that's quarterly/annually. How do we shorten that? Depends — can we build systems that will allow us to shorten parts of that to several times per quarter, or will allow us to build confidence we won't totally ship the wrong thing? We prioritize those — slow in short term, accelerant in mid-long term.

If I tell you "this is the direction we're heading and this is the progress we have made, these are our unknowns and this is when and how we plan to learn more about them", does that fulfill the same info-seeking-request as a request for a roadmap? If we're making steady progress and communicating well about it, does that check the box of predictability? (there is no "right" answer to this, these are questions I'd ask). Can we replace estimates/predictability with something else that's more honest and fills the need? If the honest answer to a request for estimates is "I don't yet know how to mitigate the unknowns here (or even what they fully are, but we know there are a lot of them), here's our plan to learn quick & progress safely, and an attempt at a firm estimate would range from best guess to outright lie", do you still want that estimate? What happens if I give it, tell you it's an outright lie, and then we don't hit it? IMO, far more valuable to do the harder alignment on "this is where we are headed and this is how we are doing so safely. We don't have the ability to project far into the future; so much to learn, so much unknown. We don't waste a learning opportunity, and those are the "deadlines"/points in time we really, really care to hit. We communicate a prioritization framework outward & align on that. Was this an adjustment? Yes, absolutely. Were there teams who did need info about what we were doing & when? Yes, & we added cross-functional folks to our direct team so they were in on the priority/planning/execution. And we get a LOT done, which is the best thing for the biz.

Q: What's your experience in organizations where you have dependencies to other teams? E.g. you want to build a first user story and see that you need a server. You want to order the server and it takes weeks due to many reasons and that delay comes back to you. As a reaction, people start to plan ahead a lot to avoid these waiting-for-other-teams bottlenecks. So you cannot 100% focus on whats most important now, but need to spend time and these longer running tasks.

Anna: If my server-needing thing is my team's most important. project, is the server-providing org's most important project getting me that server??Maybe good reasons for both yes/no. Either I'm going to work on my next most important thing, or I'm figuring out a way to validate pre-server.