Dual Track Development: Involving The Whole Team In Discovery And Delivery

Jeff Patton at UXDX Europe. Video: https://www.youtube.com/watch?v=JkMse7r10bI

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and what this talk covers

[00:00:00] Jeff: It's early this morning. I haven't had nearly enough coffee. This could go horribly wrong. I've also got to talk about a whole bunch of things, and if anybody's ever seen me speak before, they know that I don't have a gift for brevity. Also, I present a little bit weird. Here's what I mean. Let me see if I can share a screen. All right. You can see my hand, hopefully.

[00:00:35] Now, let's start from the beginning. I'm here to talk about Dual Track Development. I need to talk about this first. I need to explain my terms. I need to say what I mean by Dual Track. And then I've got some specific lessons learned from people doing this for years, so that you can make this better, so that you can actually involve your team, so that it actually works, so that it isn't just a handoff from one group to another group.

[00:01:02] I need to talk about core strength, and no, it's not a yoga thing. I'll explain that in a second. It's important you keep discovery visible. It's important you involve the whole team. It's important to change your process so that you can. And it's important that you keep paying attention to what you've shipped, or keep those outcomes visible. I'm going to start by talking about all these things, starting with this one thing to begin with.

A brief history of Dual Track

[00:01:28] First, I want to give you a brief history lesson. I've had people tell me that I came up with the term Dual Track Development. I know that my friend Marty Cagan has spoken a lot about Dual Track Development, and people give him credit for that. But the person who really deserves credit is this first person I put up here, Desiree Sy. She used to work for a company called Alias. It's now Autodesk, and Desiree doesn't work for them anymore.

[00:01:55] I first met her in about 2004, and she explained to me the way that she and her product team worked. They were early adopters of Agile Development. And I said, you've got to write this down. This is common practice, but the way you're describing it is better, or it's a little bit the way everybody's doing it. But I think if you wrote it down, people would get it. And finally, in 2007, she wrote this particular paper, easy to find online. If you look in it, she drew this particular model.

[00:02:28] Now, embedded in this paper was this short phrase: "Although the dual tracks depicted in figure three seem separate," blah, blah, blah, you can read that. She moves on to explain how these tracks really coordinate and how people are working together, and an awful lot talks about how they visualize things. I remember sitting with my friend Marty Cagan, and we were talking about this model, and he said, "Well, where did you get it?" And I said, "Well, I got it from here." And I pulled up this paper, I pointed to the words "dual tracks", and Marty said, "Okay," and started referring to it that way from then on. That's why we call it that.

Delivery loops and discovery loops

[00:03:05] Now, let me explain to you what's going on in there, and I'm pretty sure most of you haven't read that paper. It is a term that's derived from working with Agile Development. Let me twist my camera, as I start drawing pictures over to the left here. If you're working with Agile Development, you know the basic model here. We start with a backlog and we're going to pull things out of that backlog. You're going to work in these short development cycles. If you're talking about Scrum, that's a sprint, and that's a couple of weeks.

[00:03:52] You'll start every couple of weeks with a planning session where you're going to plan how much work you can do. You do a bunch of work, and at the end you stop and reflect on what you've built. The goal here is to be predictable. You start every couple of weeks with planning, saying, this is how much we can get done. And you end every couple of weeks by actually measuring if you've got that stuff done. Predictable is important. And the done stuff you're talking about is working software, stuff you could ship to your customers. Ideally you stop and review this stuff, and you look at whether the quality is good from a UX perspective, a functional perspective, a technology perspective.

[00:04:24] But this isn't discovery work. If your team is responsible for more than just building stuff fast, if your team is actually responsible for whether you get some benefit from it, you've got to use a different process, and that's a discovery process. In a discovery process, you acknowledge that we are starting with ideas, solution ideas, and you start by building a backlog, but it isn't the same thing as that backlog.

[00:04:51] This backlog is all the reasons your ideas might suck or might not work out. If your idea is going to be successful, it has to really solve a problem for people. People have to really want your solution. They have to be able to see it and try it and use it easily, and keep using it. And enough of them have to do that that your company gets some ROI or benefit. All those beliefs that you have are your assumptions. And if those beliefs aren't true, those become risks. And sometimes when you try and think of the design of this thing, you've just got questions that need to be answered. This backlog is not a product backlog. It is a learning backlog.

[00:05:31] That's what drives this discovery work. Like all backlogs, the thing at the top is the most important. That's our riskiest assumption, and given our riskiest assumption, we turn that into a question we can answer with a test or with some learning activity. Do people want the solution? Well, let's create just enough of a prototype to show them and evaluate their interest. Can they easily learn to use it? Let's create a prototype that allows us to do usability testing. Can we actually build this stuff using our technology? Let's create what agile people call a spike to look deeper at the technology.

[00:06:04] You get to work and you create a test, and then you get out into the world and actually test it, actually put it in front of people, and all you get back out of that is data. The data changes your idea. It changes your risks and assumptions. This is how discovery works. You can tell it's really different than this stuff. First off, predictability is out the window. I can't predict what I was going to learn. If I already knew what I was going to learn, it wouldn't be called learning.

[00:06:34] The best we can do over here is to time box. We can time box our learning. We can say, look, I'm going to budget this much time to do this type of experiment. And usually we expect these things to be, in the best case, hours, a day or days. Sometimes long runs around this cycle might take a week or weeks, but they're faster. This stuff is also not predictable. You can't predict one experiment after another, because what you learned on the first experiment will change what you do on the next experiment, and so on. So we time box this stuff, and if we focus on velocity here, it's learning velocity.

Two tracks, not two teams

[00:07:21] Now, if you're working with a product team that is responsible for getting stuff built and building the right stuff, you've got to do both of these things in the same process. And when we twist this and draw this type of model, this is where we get the model that looks like this. Again, start with those ideas, and given those ideas, I might do some experiments that take up a few days or a week or a few hours. And every time around this loop, what I'm reassessing is my confidence that I'm building the right thing.

[00:08:00] Now, when I am confident, I can build that product backlog, and I can drop into these comparatively longer loops where I'm focusing on building working software. At some point in time, I'll actually ship that feature, so I can really evaluate it. We draw the model this way, and it looks an awful lot like a waterfall. Yes, things drop from the top to the bottom, from the discovery track to the delivery track.

[00:08:28] But it's messier than that. Look, I might start with an idea and start doing discovery work while I'm doing delivery work on this idea I just finished. And I might validate that we're solving a problem, that people want our solution, that we can build it. At this point, I'm really sure I'm going to build it. So I'm going to do an interim drop. I'm going to drop stuff that I know I need to build, but I'm not done with discovery yet. I've got to build better UI prototypes to do more usability testing and do a little bit more research, and I'm going to keep dropping as I go.

[00:09:08] And this gets super messy. I'm dropping work as I'm doing discovery work, and yes, it changes things and it's chaos. If you go back to Desiree's paper, she'll talk about, "Yeah, this is chaos. This is the way it works, but it's so much better than the way we used to work." Overlapping these two models is what gives us this term Dual Track. But it is two tracks. It is not two teams. So let's talk about the team part. Let's see if I can get back on track so I can actually finish in time for you to ask some questions.

Core strength: valuable, usable, feasible

[00:09:48] All right. Let me tell you what I mean by this core strength thing. If I've got a product and I've got a team that's responsible for it, I've got a bunch of different people on that team. It takes enough people to actually make good decisions. The team isn't being fed work by some other group or some other team. If they really are deciding what to build and building it, they've got to have enough people, or the right people, to make good decisions, but they've also got to be able to execute, or actually build the stuff. They don't make the decisions and hand them off to other people. That's what makes this a real product team.

[00:10:36] So teams swell. They get fairly big. Seven plus or minus two is the standard, but I see teams that are 10 or 12, things like that. Now, this is a product team. It's decision makers and executors that all work together. I want to unpack that decision-making thing, and this helps us understand what we mean by a cross-functional team.

[00:10:57] I'm going to leverage a mantra from my friend Marty Cagan. I did not see his talk earlier in the week because I was working, and I'm ticked off. I hope it was good. It's an old mantra from him. He says, look, if you're going to build a successful product, it's an intersection of these three concerns. These days he'll say four, but I'm going to merge these together.

[00:11:21] The product we build has to be valuable. For you to make a good decision on what's valuable, you need to understand your business. That means you need to know how your business makes money. You need to understand your business's vision and strategy. And what's valuable is what's aligned with your vision and strategy and what makes your company money. If you don't understand those things, you can't make good decisions. Teams that don't, fail.

[00:11:48] If you're building a product you're selling to other people, you've got to understand your customers, the people that choose the product or buy the product, and the value proposition they're going to get. Part of understanding those customers is understanding your market, and inside your market are other competitors. Competitors are the alternatives your customers could use instead of your product. There are explicit competitors, other products they could buy, but there are also hidden or ghost competitors: workarounds, cobbling together a solution out of productivity tools, or just still a manual process. That's what you're competing against. Your solution has to be more valuable than your competitor's solution, even if they're just workarounds.

[00:12:35] The next concern is that what we design has to be usable. That means you need to understand who the users are and how they work, or how they'll use your solution to actually accomplish anything. And I'm drawing a distinction between users and customers. If you're building software for a living, you've already got this down. Customers choose a product, users use it. So these are users and choosers. For consumer products, users and choosers are the same people, but for a B2B product, or something we built for internal use, the choosers aren't the same as the users. Users have to use it, and it's only through using it that your customers actually get that value proposition.

[00:13:19] Now, usable doesn't mean just understanding users and how they work. It means we have to identify problems and we have to identify solutions, and not just identify solutions but actually design those solutions so they are usable. If we're going to make good product decisions, we've got to be able to design solutions and make tactical decisions on how the solution design works.

[00:13:42] Finally, any idiot can come up with super cool ideas that we can't afford to build. I do it all the time. But the right solution has to be feasible to build, given the time and tools that we've got. That means if you're building a technology product, you have to understand how to build technology products. If it's software specifically, that means you need to know how to write code if you're going to make good technology decisions.

[00:14:13] Now, I could ask you how many of you have piles of legacy code in your organization, and most people's eyes would roll. Everybody has legacy code. Everybody has existing stuff that they're adding to, and if you don't know how much it costs to make a change in your code, that's not going to help. Yes, if we built from scratch, it would cost this much. But given where we are right now today, how feasible is it to change our product?

[00:14:39] Other aspects of feasibility are those hidden technical aspects, things that if you screw up, you're in trouble, things your customers expect. Things like scale and performance. Things like security. Look, I assume you're going to keep my data safe. I don't want to specify that. And then finally, the last big thing to pay attention to in feasibility is technology trends.

[00:15:14] If we're building new tech products out of today's technology, there's a high likelihood we're getting behind. Where the real potency comes from, where the real innovation comes from, is applying what's just becoming possible to the problems that users have today. For instance, a current technology trend is AI and machine learning. If we can figure out how to apply what's becoming possible with machine learning to the problems people have today, that's how we really get ahead and create solutions that our competitors are going to end up copying.

The core product team

[00:15:49] So look, if we're going to make the decisions, you can see it isn't going to work to have one product manager or one person doing that. That's a lot of stuff, a lot of skills, a lot of expertise, a lot of experience to have. So we look for a collaborative group of people: people that understand things from a business perspective, that's a product manager, or in Agile terms a product owner, and those terms ideally should be synonymous. When we talk about usable, we're talking about someone who is a user experience person, or product design is another term we use. For people designing things that are technical tools, DX is the sexy new term I hear a lot, for developer experience. But we've got to understand how our users work. And then finally, if we're going to make good technical decisions, we need someone who is a senior technologist, not junior. We look at these kinds of people working together to make good decisions.

[00:16:49] Now, let me draw some pictures. Hopefully there are these people that are working on a business concern, and let me do the technical concerns. Look, I know you've got a technologist on your team, or ideally you should. I know that you ideally have a business person or a product manager, someone who understands the business, on your team. And ideally, you've got someone that understands your users on your team. That's just enough to make good decisions, but for you to execute, it's going to take probably a lot more technologists, testers, DevOps people, others. A product team is composed of all those people.

[00:17:39] There's an old mantra that crowds don't collaborate. One of the things that allows us to move fast, especially through discovery work, is to identify what we refer to as a core product team. A lot of you have already figured this out. If you're a product manager or a UX person, you know that if you can collaborate with an engineer, things go better. I see strong partnerships between UX and engineering, strong partnerships between product management and UX, and ideally all three. So sometimes you've got an implicit core team. Those are the people that talk and work together most often.

[00:18:14] In other organizations, this has been made explicit. One company I've worked with over the years is Atlassian. Some of you may be using Jira every day; that's one of the products that they make. I walk around at Atlassian, they'll show me where teams sit, and they'll point to a group of desks that are together, and they'll say, "This is where the triad sits." Triad is jargon at Atlassian for a core product team. I hear the word triad. I hear the word trio. I hear the abbreviation TO3 used by some companies I've worked with. The weird thing is that team of three can have two people in it, or three or four, even five people in it. It varies. It refers to these three concerns.

[00:19:03] The strength of your product team is only as strong as its core. And when we talk about leading discovery and facilitating discovery, I'm looking at the core to do that. I rely on them. Now, we were going to talk about involving the whole team, but let me give you a few other strategies.

Keep discovery visible with evidence boards

[00:19:25] Let's talk about keeping this stuff visible, and I'm not going to draw all these pictures. I want to show and tell just a little bit. The primary strategy we use for keeping work visible is the same strategy you've seen in any crime show you've ever watched. It's the evidence board. I've watched lots and lots of detective shows and crime shows, and never once have I heard the detectives rush in and say, "Quick, we need to get this stuff into PowerPoint." That's not the way it works. You spray it out on the wall, and as you get new evidence, as things change, you update the board. Things change fast enough, and we want to see it all together.

[00:20:04] When I see product teams working, I see them build these fairly messy, fairly elaborate evidence boards. I took this picture. In front of it are Beth and Archie, and these are stakeholders for this US company called CarMax. If you're from the US, you probably know who they are. They are the planet's largest used car dealership. Now, everybody asks why Beth is looking so grumpy. She's looking grumpy because the hypotheses they're working on are not panning out. They're not testing well. Their beliefs aren't panning out.

[00:20:40] On that board are those hypotheses. That's what they're talking to stakeholders about. They've got concept sketches. They've got metrics from running experiments. They've got simple personas and persona sketches. They've got sticky note evidence, things they've gathered from interviews. And when I walk around their organization, every team has whiteboard space with these evidence boards, in various degrees of completion depending on where they are in their process, that they update and change constantly.

[00:21:14] There are lots and lots of variations of these, but they are pretty consistent about having the hypothesis, having ideas for our solution designs, having what our current experiments are. And in post-COVID days, those things live on tools like Mural or Miro. I mentioned Atlassian earlier. This is the guy I know best at Atlassian, and his name is Sherif Mansour. He really exists; look him up on YouTube. There are several videos and talks from him out there, and he knows what he's doing. I met him when he was a product manager for Confluence years ago, and now he manages a large group of product managers there. As I walk around their organization, it's covered with these variations of evidence boards, stuff that shows what they're currently working on, where it is in status, and lots and lots of evidence of discussions they're having.

[00:22:14] I've got lots of pictures of people doing this. These people were at the Australian Football League. There's a lot of stuff going on on their tiny wall. This is the group that builds the mobile app and the website for the Australian Football League. I wandered around and talked to people inside of Spotify and worked with them a little bit before. One of their problems is they have these nice, beautiful walls, and so they end up using strategies that don't use their walls, things like rolls of butcher paper. Or this group working together: you can see these big foam boards that they're using to keep things visible.

[00:22:49] Now, I'm watching time running short. I've got to make this work. A couple more things I want to point out that are part of visibility. It's not just your hypothesis. It's not just your ideas and how they change. It's the work you're doing. It's common to have tasks for discovery. We've got to figure out what we're doing to support that next best experiment, and build a task board of to-dos, doings and dones. That's common. And this particular board does have discovery tasks running. It has the hypothesis, the most important thing, or the thing we're trying to learn next.

[00:23:31] At the bottom of the board are what we call deltas. Deltas are what we learned. That's how we make the learning velocity visible. I'll always ask people, at the end of every cycle of discovery, what did you confirm? What did you think was true that you really validated is true? What were you wrong about? Because if you weren't wrong about anything, then, look, if you're always right, then you're either super smart or you're fooling yourself. So you were wrong about something. What's brand new information, the unknown unknowns, things you couldn't have known, but that came out? We set up for our next round of discovery by asking what questions do we want to answer next or get answered. Those things go back into our learning backlog. And then we always come up with new ideas or opportunities.

[00:24:23] Look, if you're going to involve the whole team: I wasn't going to draw all this while we were talking, I wanted to show you pictures. Keep your hypotheses, your learning backlog, your problems and context, things like personas and journey maps, visible. Keep your solutions visible; those are UI designs and solution maps, even technical design. And keep your plans visible, and keep your learning visible. Those are the kinds of things that you put on an evidence board, and those are the kinds of things that are sometimes way too invisible.

Involve the whole team

[00:24:59] Third thing. I want to get through five. I've got to really go faster. Look, you're going to need to involve the whole team in what you're doing. Or you don't need to, but you should. Let's talk about the easiest ways to do that, leveraging this build, measure, learn mantra that you've probably seen in Lean Startup or Lean UX thinking, where measure means that's how we actually get out there and do those tests. So I've got lots of examples. Let me back up. I didn't want to skip this quote.

[00:25:47] This lady's name is Leah Buley. I've known her for a long time, and I don't know exactly where this quote is written down, because she said it to me in a bar over a drink. Hopefully it's in her book, or some variation of it is: "Design isn't a product that designers produce. It's a process that designers facilitate." A lot of discovery activities look like UX design activities and research activities, and it's common for designers now to orchestrate design, to figure out how to involve groups of people.

[00:26:18] These people are on site observing customers using something. The guy on the right is a product manager, the person on the left is a UX person or a researcher. The guy behind the guy on the right is an engineer. He's been trained to take notes and listen. It's super important for him to get the empathy. Now, I've got lots of pictures of people out there talking with customers, observing users directly, and it's always something I'm encouraging.

[00:26:46] Here's a quote from my friend Sherif. Again, he gets upset every time I use this picture, because he doesn't like that picture of himself. He's said this and keeps supporting it: they don't do customer interviews without having a developer in the room. This is critical.

[00:27:03] Look, I mentioned CarMax earlier. This is my friend Archie Miller, and this is one of his team's evidence boards. There's a whole bunch of these simple two-by-twos. They bastardize a bit of an empathy map, and they use these debrief [?] notes for interviews. They've taught everybody how to do this, not just engineers and testers on teams, but marketing people and business people and customer service people. Anybody is welcome to sit down and watch an interview. You just have to know how to listen and take notes. They create these simple rooms where people can observe remote interviews and sit down and take notes while the interview is underway, and then synthesize those together.

[00:27:50] Everybody works together to observe experiments and take notes. Once we've got notes, we use those notes to update or make changes to these design artifacts, things like personas, things like simple journey maps. And there's maybe one last simple way that we involve teams I want to make sure I mention. There's a common practice that's referred to as design studio or design sketching, and a lot of companies have this nickname of crazy eights. We don't delegate the design of the UI to just the UX people. We ask everybody to weigh in on the design.

[00:28:35] That crazy eights practice gets called that because you take a sheet of paper, A3 paper specifically, fold it three times and open it, and it now has eight boxes in it. And we want people to sit down and draw eight variations, or a flow that has eight panels, or some amount of panels. Everybody draws, everybody comes back and synthesizes and shares, and people work together to build simple prototypes. And I'm not going to talk through this, but they test simple prototypes. These are people testing a simple paper prototype.

[00:29:15] Now look, I want to bookend Leah's quote with another quote from another old friend. We are involving everybody, but design by community is not design by committee. Just because everybody participates doesn't make it a democracy. We don't want engineers voting on the best UI design any more than we want product managers and UX people voting on the best code. It's important for everybody to weigh in, but that's how we involve people. That's the way this works.

[00:29:47] I'm not going to update this. I want to move on. But look, when we're building, we're going to need team help to participate in design, in things like design studios. We'll need teams to build more technical prototypes. We're going to need team time to observe interviews, to take notes, and to synthesize those notes and make sense of what we've learned. There are ways to involve the whole team, but not all at once.

Change your Agile process

[00:30:20] Let's talk about how you change your Agile process in order to involve the team. If you're using a simple Agile process like Scrum, you've got a sprint planning session, and in that sprint planning session you talk about your delivery work: the stories that you intend on building this sprint and how much time they're going to take, and you work hard to predict it.

[00:30:45] Now, I'm going to tell you, from now on, in your sprint planning, you need to start by talking about your discovery work. What are the hypotheses that we're working on? What are the most important things to learn next? And what kinds of tests or experiments might we be running? What kinds of activities are we planning? Out of talking about this, we can talk a little bit about a time box. UX people and product managers generally spend most of their time doing this, but the rest of the team, maybe not. I see teams using time budgets anywhere between four hours, or half a day, and two full days to participate in things like observing interviews or participating in a design studio or helping to synthesize notes or working on more sophisticated prototypes.

[00:31:33] Once we have that time box or that time budget, we carry that into our delivery planning. So we use the rest, oftentimes the bulk of the time, on delivery. Look, in review, yes, you're going to review the delivery, or the software you built, but it's important that your reviews now review the discovery, and that's where that little delta thing comes in handy. If we talk about what we validated, what we were wrong about, what's new information, that's the real product of discovery. We can also show prototypes, things like that. Show what we're working on, not just what we're delivering.

[00:32:14] Now, this plan and review cycle is carried out every day in processes like Scrum. Look, we have a daily standup, and you know how that goes. You review what you did yesterday and you plan what you're going to do today. The first tip I've got for you is to stop going around in a circle and asking people what they did yesterday and what they plan on doing today. It focuses on who's busiest, and it feels like a status report because it is.

[00:32:47] In your standup meetings, start by talking about delivery, but don't go person by person. Go story by story, or backlog item by backlog item. Talk about who worked on it yesterday. Where are we in it? And how do we move it forward today? It turns into a real-life planning discussion: how do we get more work done faster, and how do we work together to do it? Split your standup meeting: talk about delivery and then talk about discovery. Same thing. We're talking about the hypothesis or the current idea we're working on, and what we're doing today. And if everybody's there, someone can say, "Hey, if there are interviews going on this afternoon, I can step in and observe and take notes. I know how to do that, and it fits in my day."

[00:33:39] Now, look, I gave you the high points for that. It's easy to find an article online on Dual Track Development. At the bottom of that article are links to recipes. If you're practicing Agile or Scrum by the book, this is the new book. There are four recipes there that describe the way planning and daily standups and team reviews and stakeholder reviews go in Agile Development, or Dual Track Agile Development.

Keep outcomes visible

[00:34:08] Last thing, and I think I can say this in just a minute. So I have a chance to exhale. Sorry if I'm going so fast you're not catching any of this stuff. I hope you did. Look, your team is going to work together. They're going to do discovery work. They're going to drop things to a delivery track, and people are going to start to use those things. The actual outcomes happen when things come out, and despite all of our best efforts, the discovery work doesn't always go perfectly.

[00:34:42] Every time you release a whole feature, I will ask teams to stop and reflect, first on what we'll call the actual effort. I'll ask them to arrange the things they've released, and I don't mean the individual stories, I mean the whole features, from small to large. Things that are similar will start to stack up. You get things that take days on the left, weeks towards the middle, months, and there are some whole features that take quarters to deliver.

[00:35:16] Every time something's delivered, stop and say, "Okay, we got that whole thing done. How long did that take?" And then one of the big questions we ask is, how long did that take relative to what we expected? If it took a lot longer, mark it: these ones were challenged. They were late. They took a lot longer than expected.

[00:35:38] Now, everything we ship, if we talk about the actual outcome, starts in the "I don't know" category, because we don't know until people start to use it. But above that, we've got a continuum that goes from awesome down to awful, and in the middle is what I'll call the thud zone, where it's not awesome or awful. In every sprint review, you revisit this and say, "Hey, we shipped this last sprint, or shipped this a little while before. Where is it now? Do we still not know what the outcome is? Or did people complain immediately and it was awful? Or do people love this and it's awesome?"

[00:36:19] These things start to bubble up and move around. This keeps that visible, and it lets the team start to say, "Gosh, this was a thud, and we want it to be awesome. What do we need to do to improve this thing?" Everybody always notices, from building this type of thing, how few things end up in awesome and how much is in the middle zone here. And people also start to notice that whether it was late or not has nothing to do with its outcome or its awesomeness. Late things can be awesome. On-time things can be awful. There's no correlation between that. It moves the team's focus back to the outcome. That's it.

Q&A

[00:37:04] Rory: Well done. Stand back, take a breath for a few seconds, but that was really good. I really, really enjoyed that. Really visual. It seems a lot of the people who are watching today did too, and we have a few questions in. The first question was, how do you recommend teams build an evidence board, or an information radiator, but in a virtual environment?

[00:37:29] Jeff: I showed one at very lightning speed, a Mural board. Everything's a virtual environment now, and we're figuring that out. It used to be easy for me to walk around environments and take pictures of their boards, and I noticed that evidence board as a common pattern. I do see teams using Mural and Miro and making sure everybody has access to that. And that's all I've got: try using those tools that give everybody control and that are spatial, that work like virtual whiteboards.

[00:38:05] Rory: And they're improving a lot as well, moving along with the updates. Someone else mentioned, if different people from the team are getting involved at different times, how do you ensure continuity of knowledge across the team for the people who weren't present?

[00:38:19] Jeff: Two things. We're using those ceremonies like sprint planning and daily standups and sprint reviews to make sure everybody hears about what's in progress. We're using things like those evidence boards, so people can see it. And first off, it's also important that everybody in your team are adults, and they like each other and talk to each other, so that they can lean over and ask somebody what's going on with that, or they can catch up if they weren't there by talking with people. And then finally, as I already said, those routine meetings are how we socialize things. That's what the review is for, to keep people up to speed. But yeah, people are coming in and out. Lean on your team to help communicate that, lean on those artifacts, lean on those ceremonies to do it.

[00:39:08] Rory: And just one final question that came in, and we just barely have enough time to cover it. Someone was asking, how do you recommend getting stakeholders who aren't on the team to buy into this approach? This comes up all the time. How do we get someone to partner?

[00:39:20] Jeff: Two things. First, there's a recipe in there for stakeholder review. And I've found that when stakeholder review isn't just about showing what you built, but showing the discovery evidence, stakeholders get really excited by that, especially when they see busted myths, or things we were wrong about, or really hear what customers said. So that stakeholder review is a key part of making the work visible to them. And the only other thing I've got to say: if you're in an organization where you have to get permission to do things, there's an old friend of mine that said, just do it. They don't know what you're doing anyway. Ideally, you shouldn't have to ask permission to do your job well. And if you really are responsible for the success of these things, this is important. Do it, and show them the evidence, and keep that visible.