BottomUp - Skills for Innovators

Hello, and welcome to the bottom up skills podcast I might pass since I'm the CEO of quality tenants. And today we're talking about the key roles. In a rapid prototyping team and we are well and truly deep into our series on rapid prototyping. And when you get everybody together to rapid prototype, it's really key that you pick the right team and you give them the right role.

So let's chat a little bit about this sort of cast of characters, if you will, that you're going to need and how that might really give you the insights and the learnings from your prototyping. Now I want to stop just by setting up a little bit of context here and, uh, just remind you of where we are in terms of [00:01:00] rapid prototyping.

You know, rapid prototyping is essentially just testing light versions of a product idea. Testing a sketch or a model that evokes an experience. That's a bit similar to what the finished product would be like. And the whole cheat here is you don't have to wait until the product's finished before you test.

In fact, you can test really, really early on. And what I found is that when you test really early on, you know, what you get all these hints that you would never have thought about to include in the product or to remove from the product. And that's really the beauty of the practice. And we've talked a lot about all the different characteristics and techniques and tools that you might want to use in rapid prototyping right now.

I'm going to yeah. Dig into some, well, some harder and lessons I might say, around the right people in the right roles you need to have when you do it. So the [00:02:00] first thought here is that you can of course prototype just by yourself with one end user now, um, For some of you who didn't catch some of the earlier parts of this series, it is essential that you test your prototype with the actual end user, the consumer, the audience, whatever you want to call them, you're testing with them.

And, um, this is really important because as creators of products, we get a little, uh, shall we say, enamored with our own ideas and, um, After a while we can kind of be a bit lost in the fog of our product. And we kind of think it's amazing, but the true test and the true judge of whether a product is amazing is of course it's the end user.

So let's talk about some of the other people that are involved. If we've got the end user and we're testing with them. You know, as I said, you could do it all [00:03:00] by yourself, but you're going to find it much better, much easier if you do it together as a team. So let's talk about who you want to have in the room, helping you on your side, on your team, pulling together a cool prototype, and helping you do the testing now.

Um, The most important thought here is having a diverse team. And, uh, again, I'm going to give you four archetypes of the type of, uh, people that you want to have in your team. And then we'll talk about the roles that they can play and how you guys can really embrace rapid prototyping. Now, the first one.

Is the, you know, the knowledge seeker, the FactFinder, the magician. Uh, so you want someone who's really good at the facts and the data. And the next one you want is someone more, a bit more like a campaign, lots of energy and positivity. You want someone who's a good understands or very empathetic? [00:04:00] What we might call the mediator.

And lastly, someone who's all about patterns and structures, the architect, um, that would be a really, really high-performance team. If you could bring those sorts of people, of course, they're all going to want to listen to the user of all going to want to listen to. The customer and the consumer, but those are some really good one's types.

If you want to make it even simpler, just make sure you have ideators. Yeah. Makers, um, people who come up with new ways of building the prototype and people who love bringing them to life. So I think it's really important because. You want to avoid groupthink particularly if you're a team that works together and you're working on a new product or service idea, you know, invariably, you're all going to think it should largely be done the same way.

And, um, that's only going to deliver you a very expected outcome. If you bring together more, what I [00:05:00] call the cast of characters, um, if you bring together a diverse team, you know, you really do get some magic through. That intersection of different culture idea perspective is really, really bad half or so.

Try and build a, I always call this cast of characters and together you can do all sorts of things. You can make prototypes and work with your end user. And get some really good outcomes. So this naturally kind of leads us to what's everybody doing? Like there are roles to play. So you're often in an environment where you have a 45 to 60 minutes sprint, where you're going to build prototypes, test them with users, and it's pretty intense.

So you actually need some pretty clear. Uh, roles to play. And of course over the period of a day, if you do lots of different sprints, you can mix it up and take on different roles as well. Um, I generally have always found that people really associate with one of these roles. Then I'm going to share with [00:06:00] you.

And, um, as a result of that, I tend to see people stay in that role for a whole day. Maybe even two days in a row. And that's okay. That's totally. Okay, cool. So what roles are there in a rapid prototyping team who are about to conduct a spring session, uh, where they're going to build prototypes and test them with users?

Well, I'm going to take you through them and explain some of the nuances to each of the roles. So here they are. We've got five main roles. The captain, the facilitator, the designer. The host and the scribe. Okay. Captain, it's all about getting us to the objective here and balancing all the information that you're getting throughout the process, knowing when we should stop when we should start, when we should continue, that's really the captain's role.

Now, the facilitator is really the guardian of the process and that. They're really checking on a few [00:07:00] important things. Are we testing the right thing? Are we listening to end users? And do we really, um, do we agree on what we just learned? And you'll remember that from a previous episode of the bottom up skills podcast, I talked about this key question of what do we learn and what do we do next?

I mean, the facilitators, making sure that that thinking process is really intact. Okay, so position number three, the designer, you really do need someone dedicated to the, if you will, the production of the prototype. And let me just say, this person does not have to be an art director, graphic designer. If you can draw a straight line and a, and a circle with pen and paper, then you're in, I think it's more important that we identify that it is somebody who is performing that role.

Now, of course, It is really exciting to have an [00:08:00] amazing creative or art director person joining your team in this role because they go quicker and they can bring to life in such great fidelity. You'll just have, you'll have your customers and uses drooling over paper prototypes. Let me tell you. Okay. Uh, so we've got three roles.

So far captain facilitator and designer. Now we're going to talk about the last two. Uh, number four is the host. Now the host is such a crucial role because it's often the first person that the recruit or the user or the audience, consumer customer, whatever you want to call them. That's a person who's going to test your project.

It's often the first person they meet. So the host is about greeting the...

Hello, and welcome to the bottom up skills podcast I might pass since I'm the CEO of hollow tents. And we are talking success factors of rapid prototyping. We are, I think we're more than half way through this series on rapid prototyping. And prior to this, we've done a lot of very specific practical, sort of granular level stuff about rapid prototyping.

Now we're going to kind of elevate the discussion a little bit and talk about some of the fundamental principles. You have to adhere to when you're rapid prototyping. So, um, some of these I've covered throughout the series, I've tried to then package them up. I've added a few, uh, tips and tricks that are gonna help you succeed.

And I think this is really, this is a little bit the coaches, uh, prep talk before the big game. These are the [00:01:00] key things to have in mind. If we want to win at rapid prototyping, this is how you do it. Okay. So there's kind of four principles that will set you up for success with rapid prototyping and without them, the.

The result, it really diminishes if you're not doing some of these things. Um, and so this, this to me is just some of the essential things to have in mind. So here we go. Number one, direct experience. Number two, always be testing and learning. Three create compound effects. And number four is create user to use a recruitment.

Okay, I'm going to break those down and zip through them. Let's go through the first one direct experience. It is just so essential that you create a moment that looks like, feels like as close to how people would [00:02:00] use the product, the finished product in real life. So it's got to stimulate their, their senses.

You've got to give them a task. You've got to evoke this direct experience said differently. Please do not allow your rapid prototyping session fall into some sales chitchat. I'm pitching your idea. Sound good. You're not pitching. You're creating a direct experience. It really tests the idea. Don't just talk about it or guess this is not a PowerPoint conversation.

This is rapid prototyping. So that's number one direct experience. Testing and learning. I mean, the key question in between two rapid prototyping tests is, okay, what did we just learn? And what are we doing next? It's just so fundamental. If you can keep this positive forward momentum, you'll find that the velocity of your learning is absolutely fantastic.

Now. The way to test and learn is really based [00:03:00] off this last previous idea of direct experience. But if you have created the direct experience, there'll be so much to learn. And after you've tested with the user and to see if they could complete a task, you can, of course you can ask them questions, but again, don't try and lead the witness, try and be like Sherlock Holmes, asked the important questions and be thoughtful and really push yourself.

To always update change. I grow your prototype between tests. That will be a great way for you to continue your rate of learning. Now, the next thing is compound effects. You got to do lots of tests. You've got to do them close together and whatever, if there's just one idea here that that's important for you to take out is, do not have a couple of tests today.

And then wait another week for another couple of tests because you just, you got really, you're just making life so hard for yourself. Cause you have to try and remember. What did we learn last week? Where did we start off? [00:04:00] And you just get back in the groove and before, you know, you're finished again, you know, if, if you want to maximize compound effects, do four sprints of testing each day, two days in a row, and you will have an abundance of insight.

Okay. So it's all about compounding things as close together, getting that compound interest really short times between your tests and making sure that you move as fast as possible. Now use it to user recruitment. One of my favorite topics here. If you've got a product it's really starting to come together and you think, well, that was looking pretty good.

I think we don't need to test too much more. Aha. Gotcha. Yes you do. If it is really that good, then what you do is you asked a user who's just used your rapid prototyping, uh, experienced as they've used the prototype, they completed the task, then you say, okay, we would like you. To present and introduce this to a new user.

And just do it [00:05:00] all in your own words and what will be really interesting. You'll see how they have actually processed and synthesize the experience. They'll use it a lot of metaphors and analogies you might not have thought of, but this is a fantastic way to see how users might pitch other users to come and joining the experience.

So these are the four principles. If you're not doing these four I'd experienced test and learn compound effects and use it to use it. If you're not doing those. You won't get as much out of your time, rapid prototyping. Now I've got a whole bucket of tips and tricks here. I'm just going to pick a couple of quick ones that I like.

Um, one of em, it's, don't lead the witness. Um, what I find over the years is that the general nature of folks is to pitch the user the idea rather than letting the user test it. So don't lead the witness. That's advice. Number one, number two. You know, there's a couple of good ones in this box, focus on what [00:06:00] you learn, and there is no wrong I'm going to go with.

There is no wrong, you know, I think it's really important to, to go in with all sorts of ideas and possibilities may be spontaneously. You might get something unforeseen, a little bit of serendipity. Um, Yeah. I think sometimes when people hear about a test, they think about, you know, compliance or something like that.

No, there's really no wrong here because, you know, One of the ways I think about when a user doesn't like, uh, a feature and it's confirmed by several users while I'm like, great. We saved ourselves the time of building a feature that they don't want. I mean, that's, that's a good way to think about it. Um, so yeah, there is no wrong just go in and be positive.

Be open. Last one here is balanced. You're talking and doing ratio. Um, people really get it into rapid prototyping and, and doing sprint sessions and. There can be a lot of talking. And like, uh, one of the things [00:07:00] I see is, you know, a small group tests where the user, the user goes back to the green room so they can get ready.

And then they talk for like 10 minutes about what they just tested. And I'm like, okay. What did you learn? What are you doing next? Just be mindful that when you're rapid prototyping, you want to create as many prototypes. You want to test as many prototypes with as many users as possible. And we all have a habit of getting pretty excited and talking a bunch.

And then that just means you're not doing. So there you have it. Um, for principles, a couple of quick tips to set you up for success with rapid prototyping, you can see the entire list of tips and tricks for rapid prototyping [email protected]. Make sure you get the, uh, Rapid prototyping masterclass and so free.

No charge. Just jump in there. You can get the deck. You can enjoy a real deep dive into rapid prototyping. So I hope you've got your success factors locked in and that's a wrap for this episode [00:08:00] of the bottom up skills podcast.

Hello, and welcome to the bottom of skills podcast I might pass since I'm their CEO of quality science. And we, again, I get mega practical in the world of rapid prototyping today. I'm going to take you through the step by step guide for when you're in. The moment where you're testing with users. And I can tell you, when you put a prototype in front of a user, it sounds very straightforward, but understanding, uh, as fellow humans is not necessarily the easiest thing, it can be tricky.

And, um, when the feedback from a user is a bit mixed, Uh, and you're really in those early stages, trying to work out what's going on. What I have found is that this five step guide is essential. [00:01:00] And particularly, uh, if you've got some newbies, um, who it might not be so comfortable, uh, hearing directly back from.

Users and customers, this will be a really, really essential for you, for your colleagues. And frankly, it just helps keep you on track. Getting to this famous step-by-step guide for rapid prototyping. But to set this up, I really want to present you with the moment. It's the moment of truth. And this, I want you to imagine you're with a small group of your colleagues, you're all working on creating a new product, and you're pretty excited.

You've recruited in end users who are the target audience, and you've presented them with a prototype. And you've asked them to complete a task. Um, you know, let's say I, I love using the, uh, mortgage calculator example. Let's say you've asked them to work out how much they can get as a mortgage loan.

What's [00:02:00] the loan amount. And you've got an online mortgage calculator where they can work that out. You've given them the task, you've set the context, they try to use it and then it doesn't work. Now it could be, they're giving you a voiceover as they click through the journey, or maybe it's their body language, or maybe at the end, you ask them after they've attempted to complete the task and the feedback could be mixed bad or just otherwise.

And you're like, Now I spoke about in the last episode, we just need to be open to this. Sometimes I see people that are just not used to receiving such direct feedback and, you know, let's be honest. When it's not great, it's a little, a little uncomfortable, but I'm going to give you this five step guide when you're rapid prototyping that will really serve as, um, sort of a set [00:03:00] of railway tracks for you just to travel along, hit your stations and get to central.

So the first thing I want to talk about is that, um, You've kind of got these five stages. I want to introduce those and then tell you how you navigate them. This is all to be used when you're in the moment you are creating the prototype to test with the user. It could be that the users are coming in in 10 minutes.

Maybe you're in the middle of testing. Maybe you've got one last test for the day. This five step guide will help you. Okay. So this first step in this is to understand it's all about unstained, where you are. Are we trying to understand that's the first step? Are we trying to ideate? Decide, build or test?

Okay. Understand ideate, decide, build, or test. These are the five steps. Now the reason these are so important is that often. People who are [00:04:00] building, creating rapid prototyping, uh, environments, creating prototypes, often misinterpret where they are in the process. So they might think they've really got this thing.

Um, but actually it's built on a really fundamental, poor understanding of the user. And that will just cause no end of havoc for you guys. So. Number one. Um, you need to make sure you can imagine. I want you to imagine you're ticking these off as I go through. Do we understand the user? And this is all about being open, being curious, and you really want to use some of the methods that I've talked about could be card sorting, role-playing, even user interviews.

You can really start to use those in your prototyping just to confirm. Your understanding of the user and their needs particular here, what do you want to understand? What are the pains that they experienced when they do the task and what are the gains that they're looking for? Okay. [00:05:00] So that's the understand once you understand where they are, you can then ideate and to ideate, you can ask questions, like what if we created the world's best online mortgage care calculator?

What is the loan amount that you got in that calculator was valid for 48 hours? Without having to go to the branch or you might ask how might, how might we or other ones are great, which are like, what needs to be to be true, uh, to create something. Um, fantastic. So this is, uh, where you really start to shift away from sort of the curiosity of the understanding phase.

Now you're getting creative. Yeah. Energetic in the ideation and everyone should play a role there. So, if you can take understanding of the user tick, we've got lots of ideas, the next thing, and this is really important. Very often. It's overlooked. You need to decide what we're going to build. Now, if your team's doing well, you can have a lot of ideas on the board.

So the question then is. What are we [00:06:00] going to build? So that's why we break out the deciding step as its own step. And you really need to have some critical thinking about, well, what are what's our evaluation criteria? And, um, I love to, uh, questions that could sort of help you create a kind of. Top 10 list.

What's the quickest to make. Um, so that's being super practical. Like what can we just pump out, make it happen? Um, and then the other question you could ask of all of the ideas on the wall, you could say, which ones can have the most impact for the user. Yeah, two very different ways in to reorganizing all of those ideas.

So you can decide what you want to make. Now it could be for the first part of the day, you work on the quick ones. And then the second half of the day, you go for the real big, impactful ones. When you're a bit warmed up or vice versa, that choice is really yours and deciding and discussing as a team is essential.

So [00:07:00] we understand the user, Ida did a ton of ideas. We've now decided which idea we're going to make. So now we need to build now the building is, um, really important because you need to bring the idea sufficiently to life in order to create the direction experience. And so what you want, I really want to do is have a bit of a list.

Um, you might have storyboards use journey maps, content. You might have some digital stuff, might have paper stuff. Uh, everything's up for creativity at this point, but actually more importantly here, it's all about assigning tasks within the group and getting people really productive because sometimes you might have a real doer in the group who wants to build everything, but, um, My experience has been that very rarely works because it's like everything's on one person.

And then the, the scale of the work is too high. They can't produce the prototype, the screens, the clicks, [00:08:00] the pieces of paper quick enough. And so the user testing sort of loses a lot of momentum, but. Decide what you want to build. And in what we just talked about then was that all right, make it clear a choice for what the form of the building is going to be and give out tasks within the group.

Everyone can play a role, um, so that you know what you're going to build. Lastly the testing stage. So, um, the most important thing you're sitting there, you've got your prototype. If you're really good about the first four steps, you've got your prototype. What do you need to do? You need to create a scenario?

Where is the user going to be...

Hello, and welcome to the bottom up skills podcast I might pass since I'm the CEO of quality and sound. We are well on the way with rapid prototyping. And today we're going to talk about some important thoughts. On how to actually do rapid prototype. And the crazy thing is that there is a really distinct pattern to conducting a sprint and to prototyping.

And there's a real journey to it. Any points of which can trip you up? Let me tell you. And, um, one of the key ways to get through all of that is having the right team. So today we're going to dig into rapid prototyping and how to do it so that you can be on your way to building a great product. Okay. Uh, the rapid prototyping journey.

[00:01:00] I mean, it is ridiculous. It's sort of mirrors the classic hero's journey starts off in such a good way. Uh, with lots of excitement, you're prototyping. Maybe you've got some great colleagues and creative people with you. And you're testing. And then all of a sudden, at some point in this journey, be confronted with the user saying, you know what?

I just don't like the prototype. I don't think the product idea is any good. And everybody in the team is going to look at each other and go, Oh, Now for first time, is this feedback, uh, can be pretty confronting, you know, like sitting with customers and having them say, you know what, I'm not into this at all.

Uh, I don't think this helps me is really confronting and it's a bit of a shock. And what I notice is that, uh, the idea of the customer has kind of become quite abstract, uh, for large [00:02:00] organizations. And so when they're actually confronted. Face to face person to person with a, with a user, with a customer saying, ah, this doesn't work for me.

I don't like the idea or whatever. It's like, Ooh, kind of uncomfortable, but it's, this is the moment where you can choose to embrace the feedback. And to work with it and to start to discover what it takes to delight them. And, um, it's really important that if you're rapid prototyping, remember that, you know, you would want to have three or four sprints in one day.

So, uh, you want to do it really close together. And I'm going to talk a lot about why that matters so much, but you don't just want to do one test with a user and then wrap up for the day. Uh, this sort of compounds. So what would be perfect is to do a whole series, like just to have an Epic day testing with users and you know, you're going to learn a ton, but the key to that learning is embracing that [00:03:00] feedback, particularly when either it's not clear or they're just.

Don't like it, because once you make the turn and start to discover what they do like and how it should work and why it should work in that way, that's when you start to move into this process validation and that validation will start you on a long journey. Now. The length of that journey is weeks and months.

Like, don't just think as you have one or two days of good prototyping with your users that you're done, um, I mean, I'm working on a product right now that we've been doing for over three months and we are still. Still learning new things. And we are one week from today, we will be launching and we're still learning new things.

So please remember that learning is a constant now often, um, what will happen when you're in a rapid prototyping sprint? Let's say for one, maybe two days in a row. At the beginning, [00:04:00] it's really all about learning. And then you will kind of shift more into what I call refining mode. So this is another distinct pattern to how we do it.

One embracing that feedback that I was talking about, but to knowing that you will, if you're doing the right learning, you'll get to a moment where you've actually like, Hey. I'm really confident. They like this feature or they like this product or service. Um, and then what you would do is you would move into what we call the refining mode, because what you need to do is tie up some of the loose ends about some of them, maybe the entry points in the user experience, you know, onboarding being a classic one.

Or completing an experience, helping them move into that advocacy part and sharing with others. But I want to give you this next idea. It's really one part learning followed by one part refining. And if you do the learning then refining you'll, you'll feel like a real level of satisfaction that you. You know, went [00:05:00] in, you learn a ton, found the things that worked, you validated those in your find them up.

So they might be ready to brief into a UX person to do wire frames, maybe even straight to a designer or developer. The important point here is make sure there's learning and refining going together. Now, the next thing I want to, uh, make sure that we talk about is this idea of the rate of progress. It is essential that you minimize the time between.

Testing the longer, the bigger, the gap between user testing with rapid prototyping, the harder it is to remember what you learned last time and the harder it is to discern the patterns in the feedback. If you test all day. And do 20 tests and every single one, uh, involved a user where they gave feedback, the pattern.

I mean, you hopefully have worked it out by, at [00:06:00] that point that you're like, wow, they hate this. They love this. We need to fix this. But if you're a particularly, you've got days and weeks between two different rapid prototyping, you're going to really struggle with the decoding of the pattern because you're just like, Oh, what did they say last week?

I can't remember, you know, It's just too much a, of a, of a gap and mint and too much memory or loss to make sure you do your rapid prototyping as close together as possible. And the thing that bridges each rapid prototyping test is the following question. What did we learn and what are we going to do next?

This orientates you to write quickly? What do we learn? What was working? Okay. How might we put that into the next test? How do we take it? One one step further. This is really important because if you do this, you'll get incredible velocity. You'll make a lot of progress and it'll be really, really worthwhile.

Um, [00:07:00] so what did you learn and what are we doing next now? The last thing I want to touch on is how to set up, um, a bunch of people, um, and how this is really important to rapid prototyping. We've talked earlier in this series about all the different types of prototyping. We've talked about creating direct response, which is really important.

So I'm assuming you've kind of got this now deep into your mind. And when now we've started to talk about these kind of more matter ideas, admittedly. About how to do these also, well, the rate of progress and making sure you're asking that question of what do we learn and what are we going to do next?

So now I'm going to kind of wrap up with how I would structure a team of people in a rapid prototyping sprint. And there's lots of good books on doing sprints and so forth, but I'm going to give you my go to a formula. And of course, you know, We're often tweaking this depending on the project or maybe some [00:08:00] time and availability constraints, but in a perfect world, this is what I would do.

I would build out from the sprint. So a sprint is going to be like a one hour session then where you've got prototypes, you've got real users, real customers to come and test them and to give them tasks, they're going to give feedback. And within that sprint, you want to look at doing six really good tests.

In a one hour sprint, if you only test once or twice, I would be really concerned about the productivity. I think there would be too much ta...

Hello, and welcome to the bottom up skills podcast I might pass since I'm the CEO of QualityNet and we are in the third installment of our rapid prototyping series. And in this show, we're going to talk about creating a direct. Product response from a user that you're testing with and this stuff, ladies and gentlemen, this is some of the real good stuff.

I'm really getting into some of the magic of rapid prototyping in this show because, you know, When you're rapid prototyping and building all these prototypes and it's pretty intense process, uh, and there's a real art to getting the right feedback from a, from a user and making sure that your not getting misled.

Or making sure that they're not misleading, uh, themselves about what they are actually testing and what I've discovered over the years. There's a bit of a formula actually to getting the best user insights. So let's dig into the world of getting the direct response. The first thought here for me, uh, is kind of the cheat that you get with rapid prototyping.

And that is that you don't have to build an entire product in order to test it. Uh, that really, for me is. The magic of rapid prototyping and rapid prototyping enables you to get some really quality feedback early on, you know, kind of a simple, quick and easy manner. And this is great because you don't have to defer all of your testing until the product is finished.

Actually, here's the real thing. You can make it feel like a finished product for the user without it being. A finished product. So you can get all this really great feedback, which will help you build a better product. And we've lived in a world where the default approach. To building products, particularly with technology used to be, uh, informed by what they call this waterfall approach.

And, um, that would usually defer a lot of the user testing to the very, very, very end. And that always, uh, scares the hell out of me because that's when you get so many issues, um, all at the one time. Simply put with rapid prototyping, you can avoid all of that stress and you can work with a lot more clarity and knowledge upfront because you can create these simple prototypes that still give you really good feedback, even though the product is not finished.

And the reason this is, so is that the. Prototype gives people the opportunity to really respond to what the product may look like and how it may work. And it's completely opposite of how a lot of people do early stage testing, which is where the focus group and the problem with the focus group is everybody.

Sits in a room. So there's a lot of social bias and conditioning. Cause you might have, you know, four to eight people, users recruited, uh, audience. Uh, how are you? You want to call them that are being asked questions by a moderator. So you've got all these social pressures as to what you say is a bit of group thing, but there's something more important here.

You know, if you have a bunch of people in an office room. All right. In a meeting room and they're sitting there and they're asked the question, you know, how would you like a service that made a, that was like a digital mortgage service. So you didn't have to go into the bank and. They would have to kind of think about, well, I guess that sounds interesting.

And people would share stories of the hassles of going into the branch. If you're rapid prototyping, you would create a moment where someone would be likely, uh, you know, filling out an online, um, mortgage calculator and you would give them a prototype of the mortgage calculator and you would ask them to get.

The figure that the loan amount from the CalCare, you would actually set them a task. And this is what we mean by creating directly response. This is now we get great feedback and I'm going to give you the formula. I'm going to explain why this works and what you need to do in order to create this.

Because in the day when we go back to this mortgage example, it makes so much sense. I mean, Rather than asking someone, would you be interested in a, in a digital mortgage loan calculator or digital app for a mortgage? Give them the app, ask them to complete a task and experience. And then that feedback will tell you if it's a good idea.

And this, this is really at the heart of what we mean by creating the direct experience, getting direct exposure response from your users. So let's now go break it down and let's see how we can do it. Because remember the opportunity here is that you can create a prototype that feels like the finished product experience, but you haven't had to build it.

So as a creator builder, entrepreneur designer, developer, This is enormous because you can create these quick prototypes, get some feedback without all the risk of spending days, weeks, months building the product. All right. I've made the case that let's, let's see what it actually looks like. What is that direct experience formula?

Now the context to this, is it all about the perception of the end user who's testing? Okay. So we want to create a, the kind of thing following flow. We want to build a prototype that is as lean as possible. But does enough, uh, to create a, um, uh, a set of experiences, task features for the end user. So pretty lightweight, it could be pen and paper.

It could be using some digital tools like envision and Adobe XD. Now here's the key thing is when you have that prototype, that evokes just one little journey within the, in the product you need to add to that. The situational context. For example, if you're building a product for college students, you would have to say you're at, yeah, you're in your college dorm.

Um, it's two 30 in the afternoon. You've got 30 minutes before your next lecture. And we would like you to, uh, use the, uh, to get a loan amount from the digital mortgage app. You've got, uh, the job you've got your environment, you know, where you are. Go for it. So when you give them the prototype in that context, and particularly in that context, they know where they are, who they're with.

What's the time you've also set them a task to do. And therefore, because they're actually trying to achieve a task and remember they're not in a focus group where they're thinking, trying to guess how they would react. They are actually in. The situation. And therefore we have this great moment where they shift from, um, being an indirect experience and they go into the experience.

They're really looking for the buttons on the app to get the job done. And if you do enough, With your brief to them giving them the context in the task. And if the prototype is sufficient in terms of a basic flow, what you're going to have is the, uh, Evoking of sufficient sensory information, sensory stimulus that shifts them into the direct experience.

Now, once you've got them there, you will be amazed at, you can keep them there for 40 minutes, getting them to do tasks and getting feedback and revising and changing your prototype. This is. Really where some of the great moments you'll have with rapid prototyping. So let's kind of just break this down one more level, just so you really understand why the direct experience, um, can work for you and it can produce all these great insights.

So. You know, you want them to respond viscerally. You want them to respond to your rapid prototype. You want them to respond from the point of view, like they're there and they're doing it. And this is like really essential, uh, for them in order to give you this great quality feedback. So what you want to be able to do is when you have the prototype.

In your hands as a user, you need to touch it. See it here. Now you think...

Hello, and welcome to the bottom up skills podcast I might pass since I'm the CEO of quality science, and this is our second installment of our rapid prototyping series. And in this episode, we're going to talk about all the different types of rapid prototyping. In fact, There has so many different flavors of this practice.

I mean, you can do it in all sorts of ways. High fidelity, low fatigue, Ellie, you can do it in situ you can do it in a studio. You can do everything from role play, you name it. There are so many different ways to apply it. I've been spending years doing this, um, and. It's wonderful. It's powerful. It gives you such clear feedback.

But what I find is a lot of people that I introduced to [00:01:00] rapid prototyping, um, find it a little bit hard to know where to start. And that's what I think this episode is really going to do is going to give you a hint, a tip. A nod or a suggestion towards, you know, the really what type of rapid prototyping should you kind of conduct.

And I'm going to explore that in all its different flavors. So let's get into it. The first thing I want to do is just make sure that we're all on the same page about, uh, what the prototype, uh, really is. And. The best way to explain it. It's like a model or a sketch or a light version of your product idea.

You don't need to completely create the product to prototype it. In fact, the whole idea between prototyping is that you're trying to avoid building any unnecessary elements in which. To conduct a [00:02:00] successful test. So you just want to create the lightest most essential version. It can be a bit rough. It can be a little raw.

It might not have a logo. It might not have all the fancy colors and, you know, wonderful stock imagery. It could just be very functional. They're utilitarian now. So that's what we mean by a prototype and what I want to give you as a, sort of a threshold by which you can judge D is your prototype good enough?

And it needs to create sufficient sensory stimulus. Uh, that suggests what the product might be. So people can give you. Real feedback. So let's break that down a little bit. Um, this sensory stimulus means you don't want people to do a classic focus group situation where everybody sits around the table and the facilitator tater says, how likely would you, um, what you want to do is if you want to test a [00:03:00] product, you want to try and recreate.

The real life situation you want to, you want to try and get real feedback. We are all familiar with products that come out into the world. And as soon as real people start to use them, we're all like, well saying, going to work and that's because they just haven't tested. I can certainly guarantee they haven't used rapid prototyping.

So you just need to create sufficient, um, sensory response. You can touch it, feel it, see it. Um, and it gives me a good sense of the product and it could be put into a situation where you said, okay, we'd love you to research your next vacation and find the perfect destination. Um, Give them enough in order to do something like that.

Or if it's like a banking product, make a cash withdrawal or transfer, there's a classic use cases and you can build some prototypes that do that. The key here with, with the different types is to understand. And the starting point is we're just creating a light version or a sketch. [00:04:00] Okay. Now on think of prototypes, generally being bucketed into three.

Particular types type number one, very early stage, and that's called the diagnostic prototype. The second type is the journey prototype. This is where you sort of paint a picture of an entire experience. And the third one is the experience prototype. And this one is where you are really bringing it to life.

And this might include some sort of clickable digital prototype. Okay. Diagnostic. Journey experience at three types. Now, the important thing is that you create different stimulus and you conduct different activities throughout these different types. Okay. So. What I'm going to do for you is, um, take you through some of the [00:05:00] ones that I really like, some of the activities and some of the stimulus, some of the prototypes that you would use for them.

So if you're doing diagnostic, uh, rapid prototyping, the key thing here is you're really early stage. You might have very, uh, early forming product ideas and you might actually. A prototype with real users, which is another key component of rapid prototyping. We don't just prototype and test it on ourselves.

We actually test it with real users and I've got a whole show about how to do that in the best way. Coming up later in this series. But the first thing you could do is role play. You could do interviews or one of my favorites is card sorting. Now, generally speaking, what you're trying to do in diagnostic prototyping is either to really define the problem [00:06:00] or to in a complex problem, such as personal finance, you're trying to.

For example, using card sorting, you would try and use some card sorting activities to work out. Which thing in this big complex universe of personal finance is your biggest pain or your biggest game. And in the case of card sorting, which has a bit of a personal favorite of mine, you actually ask someone to write down the top 10 things that frustrate them that are the blockers when they're doing their personal finances.

And then you can do a series of activities as, as a prototyping activity where you ask them to sort the cards in priority or biggest pain, or you can do some other ones that, which take the greatest effort, which costs you the most money, et cetera, et cetera. So you have all these different views now where you understand what really matters to users.

But what's interesting about this [00:07:00] as a prototyping exercise is you ask them to create. The stimulus and then you gave them activities sorting through different priorities or effectors in order for you to learn and validate actually what the problem they face is. And what you'll see is we go through this journey, we'll be moving more into what the solution looks like, but this diagnostic set of activities, interviews, role plays, and card sorting.

These are all ways for you to prototype and to confirm to yourself. To test and validate what really is the problem that we're solving. So now I want to move towards the journey and, um, what I want to do here is sometimes we want to call out just a moment in the journey, or we want to show someone the entire journey sometimes, um, you know, This type of a journey prototyping is you might show, uh, today personal finance journey, [00:08:00] and then you might ask them, uh, on that journey to nominate.

If they could solve one thing in that, and they could only solve one, what would it be? What you might do? It was a followup exercise is reorganizing journey and do a, what if and using this stimulus prototype of a user journey, and this can be on a whiteboard, right? You don't have to actually build all the products, just do it on the whiteboard and propose to them an alternate path and get their feedback.

Um, throughout the journey, you could pick a moment of transaction, uh, customer support and just using pen and paper or a whiteboard, bring it to life, ask them questions, ask them a task based completion questions to get their feedback. And the beauty here is that not only within the journey, but within the diagnostic testing.

You have not had to get out your laptop and code anything. You haven't had to illustrate an interface. This is all very low fidelity. And the important thing to [00:09:00] realize is the real reason you want to work pen and paper or person to person i...

Hello, and welcome to the bottom up skills podcast. I might pass on this. I'm the CEO of quality science. And that's right. Folks. We are studying a brand new series on the bottom up skills podcast, and we're going to get into the world of rapid prototyping. We're going to tear this thing apart. We're going to decode it.

We're going to share it together and understand why it is so damn important. And today I really want to frame it for you. Define it for you, give you a little bit of context to do that. I want to start with the story of when I met a guy called Tom Chichi and Tom had spent a long time working at companies like Yahoo and Google, [00:01:00] and he changed my world by presenting to me.

This universe of rapid prototyping. And thanks to him. I discovered something that is an invaluable tool, um, and that is none other than rapid prototyping. So if you're building a product, then rapid prototyping is an essential thing to have. And. What it really does as an act, this idea of building a prototype and then testing it with a user.

He is so invaluable because what it does. This whole idea of rapid prototyping with your end user, with your customer is all about testing and validating your idea. It's seriously the best way to work out. If your product idea really does solve a problem for the user. Now the enormous benefit. That we get from rapid prototyping is that we don't have to wait until we've [00:02:00] spent all that time, effort, money, all that blood, sweat, and tears to build the product, and then to only work out, will anybody use it?

If you create a low fidelity version of the product, create a prototype, an early stage model example and put it in the right context. You can actually get incredibly good testing and validation feedback from users. And it is so, so good. It really, for me, it really filled in like a number of questions and doubts and concerns I always had.

When I was working on early stage ideas, when you just. And I'm sure you've had this too. You just don't know. Is this idea any good? I mean, it sounds good, but you're kind of thinking I'm not really sure. And I would say that if we go into the world of product design, particularly. Software and particularly, um, in [00:03:00] technology you'll often hear people talking about different types of product fit.

So you've got problem solution fit, product market, fit, distribution, and conversion fit. Now we'll get into all the other types of fit at different times in this podcast series and over the course of the many shows that we'll make for you. But today, when we talk about rapid prototyping, we're really talking about the first thing you need to find with your product, which is problem solution fit.

Now, this is the moment. That you actually have some evidence, some real facts that customers really care about. Certain things like they're experiencing some blockers and some pains. They're experiencing a great desire for a certain set of benefits or gains when they do a particular job. So if your product in the travel universe, [00:04:00] people want to travel to a destination of a particular type and they'll experience all sorts of problems.

Like not knowing which. A hotel or Airbnb to book, they're looking to, uh, experienced some gains like relaxation, adventure, excitement, and this whole job is about travel vacation and getting away. Now, if you're in that situation, what you don't want to do is build an entire solution, then test it. That's a very old school way of doing things as sort of the, the waterfall model, um, in the software world.

What you can do with AR with a prototype is you can actually test for problem solution fit. And so when you test whether user, this means you've actually created some evidence that what you're trying to fix is actually worth fixing and, um, That way you've defined the problem. And then you prototype some possible solutions and you learn which one is most likely to fit the problem.

Now [00:05:00] it's not an exact, you know, seal of approval, but if you've done this and if you really learn this, you'll get at at minimum, you'll get this amazing directional feedback from the user about, yeah, this helps. No, this doesn't help me. And it will help you put a lot of, um, validation into your product idea rather than, and this is the big thing.

What so many people do is they are guessing an idea. They have a guess at best a hypothesis about a particular idea that would be supposedly fantastic. And. All it is, is a guess what the embracing of rapid prototyping does is gives you a chance to go beyond the guests and to having a lot more closer to knowing state of mind about your problem solution fit.

And, you know, for [00:06:00] me, What that does is it does a couple of things. It orientates, you much more towards the user, rather than making some fancy good-looking, um, PowerPoint slides that impress everyone, but have very little evidence supporting this idea or this notion. I can't tell you how many people I meet.

Talk to, and when they know that I'm in the world of creating brand new products, the first thing they often will say is, Hey, I've got an idea or I've got an idea for an app. And you know, the interesting thing that is just in my bones is to ask this first question, how many users have you tested this way?

Whether it's a prototype or usability testing on an MVP. How many users have you tested with. And invariably, those that are really [00:07:00] blocked have done little to no testing, and those that are making good progress have great proximity to their customer. Um, so this is why, uh, it's so fun to dive into a world of rapid prototyping.

This is why it is so important in my life as a craftsman, as a builder of products. I need rapid prototyping and without it, I feel vulnerable. And like how many times have we tested this? And it's sort of mature. Sibling is as the product is really forming and shaping as you'd get into more usability, acceptance testing and that sort of thing.

But that's for a different show. We're just talking about really early stage trying to get a hold of what actually really works and, um, What the last thing I want to share with you in, in sort of framing, what is this, um, this art form, uh, this practice of rapid prototyping. I really want to [00:08:00] focus on this idea of perception right now.

The key thing is. We all suffer, uh, many bias, um, and, um, as builders and creators of products, we often think our products are amazing, but we vastly underestimate how little, uh, customers and users really care about our product. You know, we've spent all this time with it, we're in love with it, but the reality is often that uses are not.

Um, and so what you really need to work hard to do is to create. A prototype and to test it and to test it with the user and allow them to objectively give feedback. None of this, coaxing them through a focus group. No, we want to really test it. And at the core of this, we'll be asking them to actually do a task, complete a task, complete a job to be done [00:09:00] now.

Um, the reason that matters. Is the following. And I want to bring it back to perception. You can create a moment in time with rapid prototyping, where the user is working with a prototype and they perceiving the experience like very closely to real life and they can give you great feedback based on that.

Let me give you a little bit of a look into. What rapid prototyping needs to do in order to achieve that. And what you want to do is you want to create a prototype that's the essential feature. Um, and it might be some sort of a low fidelity. Sketch. If you want to go super, super low fidelity, it might even be, ...

Episode 51: 

Hello, and welcome to the bottom up schemes pass. I might pass it because I'm the CEO at QualityNet and we have got to the end of our agile software development series, and there is nothing more fitting than talking about a great scrum practice. It's cold. The retrospective. It's just a different way of saying let's reflect on what on earth we do just did in this sprint.

And the whole idea of doing a sprint retrospective is to make sure that the next sprint is just that bit better. So what we're going to do today is we're going to discuss. How to kind of celebrate wins within the team, discuss the losses and how we can use the retrospective as a way to create more [00:01:00] momentum.

For the following sprint. All right. So the spring retrospective, let's be honest about this thing. It is the first thing that gets canceled when everyone's too busy. And I know, I know it's easy to do and it's easy to justify, but it's so wrong. I mean, You need in an agile scrum project. I mean, man, do you need some time just to pause and say, okay, what did we learn?

I think the important thing is how can we do it better next time? And, um, this is really important because. If you do this at the end of the sprint, if you do a really good retrospective, actually doing the planning session for the next sprint becomes infinitely easier because you've already had a good chat about what happened and how you can do a better it's.

It's it's really, really important. [00:02:00] And, um, it's actually, even though you're formerly still in the old spring, you're already starting to commit to what you guys are going to do better in the next sprint. So this, just talk about this feeding into our agile software development series. And let's just talk about, um, the first and most important thing, and frankly, in a retrospective, as you would have in any type of project, you got to celebrate some wins, right?

You've got to celebrate some good work. Let's say someone did some work at a high quality, um, celebrate that. Call it out. Let's say somebody was able to deliver the work despite having to climb some sort of mountain. Maybe they were ill. Maybe they had to travel. Maybe they had to go over and support another project, whatever it is, celebrate the wins, because here's the interesting thing.

Um, let's say there's someone in our [00:03:00] team and they do something really admirable, make a really good contribution. And that's, for me, that's a win. We're all thinking to ourselves. Oh geez. It was really great that Joe blogs did that thing. Um, but the capacity to verbalize it, to actually say it is such a gesture of Goodwill.

It's such a great thing to bring a team together, to celebrate those wins, to celebrate not only what they did, but the effort that they put into it and, you know, Agile projects are not for the lighthearted. Um, they're pretty fast moving, pretty stressful. You gotta be at your best to get this thing done.

So celebrate your wins. But having said all of that, there's probably something that can contribute even more in celebrating your wins. And that's talking about the losses talking about stuff that didn't go right. [00:04:00] And you've got to create a safe, nonjudgmental environment in which this can happen. And I would always start by volunteering if you're a scrum master and you're running the session or whoever your role is within the team, always start by, Hey, I'm going to put my hand up.

I think I stuffed this. Um, and there's something important about leading. With humility and saying, I missed a thing. And I think you want to set the environment where everyone's accountable. Um, and everyone is safe to raise their hand and say, Hey, I want to do this better. I didn't do a good job. Now. The best teams, the best teams wait for this can be Frank about other people's.

Improvement areas. And this is delicate because, you know, Hey, we're all, we've all got egos, but [00:05:00] getting people in a safe cultural environment where they can say, you know what, Joe, I don't think that was the best. How can I help you do it better next time? That would be my advice to getting the most out of this situation.

So be Frank about the losses. And when we talk about wins and losses, I really want to come back to this idea I've mentioned before on the show. Don't just talk about what you did, talk about how you did it because there's good code, but then there's also things like good support. Good listening. Good communication.

High levels of trust. Those are the, how we do the code. And so you've really got to celebrate not only what you did, but how you did it. Now. Sometimes I see teams in an effort to be highly accountable. They set sort of really unrealistic goals for the next [00:06:00] sprint, my honest opinion here. And it's. It's not always what you want to hear when you're in a project that's not going great.

Is that you've got to set incremental goals. Don't set audacious goal from sprint to sprint because. Sprint's going well, uh, largely the result of good teamwork and good teamwork takes time. So when we think about retrospectives and setting goals for the next friend, I want you to go and ask yourself, okay.

If we could maybe only address one thing, let's just fix this one thing. Um, Hey, maybe you want your goal to be at number 150 now, or just say guys, that list, just get it to 60 for the next sprint. Don't go for the a hundred because I rarely see teams capable of that faster turnaround. It takes time.

Teamwork is incremental. There's trust, there's [00:07:00] communication, safety, accountability. There's a whole lot of good stuff in there, but if you're celebrating the wins and being Frank about the losses, um, Set some incremental goals set, set, a healthy stretch. Don't be crazy because you actually, one of the best ways you can get a team working well is confidence.

And you can build that confidence by them saying, Hey, you know what? Last sprint we did 50, this sprint, we did 60. Excellent more than a 10% improvement rock and roll. Let's keep it going. And I think that's the important thing because every sprint retrospective is immediately followed by a grooming session of planning session where you are actually re-prioritizing and setting the course for the next spring.

So there you have it. This is the retrospective, the very last part of the sprint. Um, the various essential thing at the end of one sprint that builds the connective tissue, the bridge [00:08:00] to the subsequent sprint. And if you can really get the right conversations, Going, if you can get people celebrating and being Frank, you will be amazed that over time you can really start to perform, uh, at a high level.

And this is essential because you're using something like the scrum methodology on your agile software project, and you're moving fast. But if you do all of the things, not only in the retrospective, but everything we've talked about. Organizing yourself, right. Having a real focus on working code and making sure that the team has a high degree of autonomy so they can move fast and really take ownership for the product.

You're going to have a great product, a business, a service, whatever you're trying to build. If you adopt this agile principle set and you use a methodology like scrum, it's gonna be electric. And if you really want to dig into it, you [00:09:00] can go over to bottom up.io where you'll find a full masterclass, not only on agile, but design thinking, rapid prototyping innovation.

We've got some cool case studies where we dig into all sorts of, um, successes, um, a couple of our losses as well from other companies to ask ourselves, what did they do and how might we do ...

Episode 50: Agile Practices: When do we get people together? 

Hello, and welcome to the bottom up skills podcast and Mike Parsons, the CEO of . And today I got to say, we're getting to the wait for it. The second last part about agile software development series. And today we're going to be talking about when we get everybody together and you know, this idea of the let's get everyone together and talk about the product is fantastic.

I mean, look, let's just get people aligned. Let's get people going in the right direction, but these projects can very quickly, uh, involve a lot of people. And the real emphasis to success of bringing people together is all about when and how you get them together. [00:01:00] And I've had to do a pro agile projects with huge mega brands like Coca Cola, a Nike I Kia, and lots of really cool startups like radio up in San Francisco.

Um, and. I've learned. So, so very much, uh, about how to best divide up these moments. So people can have not only the time to understand, but it's also about the chance for them to contribute. And that is, um, I mean, that's a win, win. If people really are aligned, there'll be able to offer all sorts of help, uh, on your project.

And if you're building a first generation product, a business, a new service, you name it, you're going to need some help. So if we can get the most out of bringing people together, chances are you're more likely. [00:02:00] Okay. So let's dive into this and we're going to talk about. Four concepts. The first one is scrum.

The second is a demo. The third is a showcase and the fourth is a brains trust. Okay. So these are different vehicles that have different purposes that occurred different times. They go for different amounts of time, but they also have this purpose of getting people aligned, getting them on board with what's happening because the core team is going to be going like crazy.

They're going to be sprinting all the time, so they're going to catch people up. Uh, and that's really important if you want help, if you want support, uh, then people have got to have some. You know, rudimentary understanding of what's happening, otherwise it's just guessing. Okay. So let's go and jump into the first of these concepts.

The scrum said differently. This is your daily [00:03:00] standup. And as we talked about in a couple of the previous episodes, this is a fast daily session for the core team. That a good one is 15 minutes. I start to get worried if they go for 30 minutes, because then I think you're actually, you've, you've made the classic mistake in a scrum is that you start talking in detail about a thing when that should be handled offline in a separate session.

The scrum it's purpose is to understand. Are you on track? It's amazing message from you to the rest of the team. Hey guys, I promised at the end of the sprint, I deliver this and I can tell you I'm feeling good about where I'm at. And today I'm going to be working on this new feature and I don't have any blockers.

That would be the perfect contribution stand up and [00:04:00] sometimes, and it's okay if you have to say, you know what, I thought that this feature. That I have a dependency on would be ready tomorrow, but I've just realized it's not. So I'm not sure about what I should do for the back half of the week. That's a blocker.

Great. We can tackle that. So the scrum is asking, are you on track and the scrum master, it's their job to go out and help each individuals solve those, uh, blockers that they do have if they come up. So the scrum is only attended by the core team. Um, that would usually be. Somewhere from six to 12 people, um, depending on the scope of the product you're building, I mean, I've got, uh, projects running at the moment that have doubled that number of people in it.

Uh, but they're, they're pretty significant projects. I also have some projects running just on five or six people, so it really does vary, but I [00:05:00] mean, once you're building core application, You've got data specialists, application developers, UX folks. You're going to have quite a lot of people. Paul you've got scrum master BAS client binders, a whole bunch of people running around.

So that scrum is just so essential for, um, making sure you're on track. Okay. So that's the first part of getting people together and what we start to do. In the demo is we go beyond the core team. We might go to some executive sponsors and bring them into the demo. Um, we may even bring, um, some experts in, uh, we might bring, um, client partners, uh, clients, you name it.

Now the demo doesn't happen. Of course, every day it happens usually every two weeks and it's usually a perfect way to wrap up a sprint. And, um, I think you are [00:06:00] showing your progress as a team. But I think if you only share that, then you're leaving a little bit on the field there. Um, I think you can also contribute, and this is a high form of alignment to what you are learning, how your better understanding uses the nuances in how the application needs to work in order for people to be delighted, that kind of stuff that really gets you inspired, but also.

In a capacity to contribute. If you understand, not only what the team are doing and the progress they're making, but you understand that the sort of learning that, the wisdom they're building about this product and how it serves its customers. Now, unlike the scrum, the demo can go for quite a while. And I would say it the list of 90 minute thing, and you want to open it up and make it conversational.

I think from my experience, the biggest [00:07:00] temptation in the demo. To make a presentation where two or three people on the project talk at the others. The best demos I've been in, uh, are aware the product owners are bringing you into the conversation about the progress they've made, um, the ups and the downs and what they're learning.

And it should be so compelling that people are. Volunteering contributions, help assistance and support. Um, that for me is it's a great demo. It's not judging jury situation. And you know, you can, you can change the vibe by how you present your demos, how you set them up, how you orchestrate them. But I would just avoid like a super polished thing, because then you're just spending lots of time in your keynote deck and not enough time on your product, if I'm really honest, Okay.

So we've got scrum and demo scrum [00:08:00] core team daily demo, every two weeks core team and extended members. Um, we'll get to the brain stress in a moment, but they're often people you can bring along. But now let's talk about the third one. Now the third and fourth one and not formal parts of agile and scrum methodology.

These are classic Mike Parsons out on, and I can tell you that they help. So very much. Now the showcase there should be a monthly, um, uh, opportunity. It should be something where you demonstrate. The achievements of the team. And very few of the team need to be in the showcase, maybe the product owner and the scrum master exec sponsor.

And you're presenting to folks not only in your brainstorm, um, direct, uh, executive sponsors, but you can also have it as a [00:09:00] fantastic knowledge sharing, uh, opportunity between folks who are. Not related to this project at all. Now, what I tend to find is that, um, there are others in the organization really keen at my clients who are really keen to learn about agile, and they might not be involved in the project at all.

We use the showcase as a, as a chance to, you know, maybe get the CEO, um, uh, involved with what we've achieved. Maybe get someone from a, like, if we're working with the retail team, maybe we'll go over to a team ...

Episode 49: Agile Practices: Sprint

Hello, and welcome to the bottom up skills podcast. I might pass since I'm the CEO of quality wins. And we add in a talk about sprinting, and we're going to be talking about the agile software development card, but it might actually feel like you're on a race track running around. And you're a little out of breath.

Uh, so the sprinter, this is, you know, usually it's a two to four week, uh, development dash in an agile project. I think you're most likely to see, you know, at least 10 to 12 sprints in a full project. Um, maybe more if the product is fairly significant in terms of scope and, uh, one of the things that.

Really kind of sets up scrum so well for anyone in business is that, [00:01:00] um, the scrum methodology within agile really time boxes, the sprint, it can be in other forms that there is not this time boxing, you know, Kanban is the one that comes to mind there, but really. The sprint and time boxing is essential.

If there's a huge focus on delivering a project at a particular deadline. And so. Usually, as I said, two to four weeks, uh, I quite like the two week version, uh, insight generally. And I get to the backend of projects. We will, uh, encourage our teams to actually push a release every week just to keep up the intensity of the sprint.

So I'm a big fan of the two week. I wouldn't, I wouldn't go for four, just there's too much time. Uh, for momentum loss. Uh, so I've got three, three ideas that I'm going to share with you about how to get the most out of doing a sprint. And, uh, I'm really looking forward to getting into this cause this [00:02:00] simple technique creates a ton of value.

It's sort of a hidden accelerator teams. So let's get into the world of the agile sprint. So we talked about in the previous episode, the idea of the backlog, if this is a tool that measures something, what it is applied to is traditionally a two week sprint. Now this fixed length really matters because it just means.

There's nothing like a good deadline to get us moving. And two weeks I've universally found for years is such a good basis for a sprint. And then in a sprint, you effectively agree as a team like, Hey, what are we going to deliver for the next two weeks? And then you go do it. And that's really at the heart of the sprint.

And this is where you start to see the use of the backlog that we discussed. In the previous [00:03:00] episode, they come together, the backlog and the sprint. They're very fundamental concepts in agile. We got two weeks, let's look at the backlog and work out what we should do. So you got this two week period. How do you get the most out of it and how should it be organized?

Well, I want you to imagine that if you looked at the two weeks and let's just say, we're starting on a Monday, that Monday should be about coming together and planning and the very final second Friday, the last Friday of the sprint should all be about. Reviewing what just happened and in between all of those other days, your sprinting, like crazy.

So let's talk about each of days and I'll want to give you a sense of just what I see time and time again, having worked on so many projects, there's the patterns are super, super clear. And you know, the funny thing, when we're going to start with planning, [00:04:00] The planning and the reviewing is the bit that so quickly gets abandoned, um, in teams that are not high performing, they're perceived as almost time-wasters, but they're so, so damn important.

So let's talk about planning. You want to plan your sprint? I would say. We talked about that the backlog brings you priorities. I think a key part of the sprint is to introduce a conversation about dependencies as well. If you're working on a software project, Invariably, you can have a couple of things going on.

Maybe you're working on an Android or an iOS version of the same application. Maybe you you've got some micro services, a web services or API APIs running. Through your architecture. And if that's the case, there's a really a high degree of attention that needs to be placed on this idea of dependencies, [00:05:00] because you need certain web services in order to create certain functionalities inside of the application.

And what happens where teams get lost is working on a priority. Without thinking about the dependencies. And so it's really important that when you do start planning your sprint, you need to work out the dependence you have on perhaps third party systems, or perhaps you need to build past a, before you can generate part B or part C of your product.

I see this quite often as well. And so the art to your planning is not only saying, Hey, what are we going to do this spring? But understanding the dependencies. Cause they tend to have the following effect. Oh, Joe blogs is in. Can I have part B ready until Friday, but we want to start on part C. But [00:06:00] we can't.

So what do we do now? And this is the famous West stuck because we're waiting for Joe blogs. So make sure if you do that good. Say planning exercise at the start of your sprint. It will just go so much better because you've taken the time to think about what's going to be happening down the track now.

We'll get to reviews in a second, but sprinting sprinting is just so damn important. Um, and I'm going to give you a build on best practice. You should be having a daily, standup, or a scrum, uh, where you ha having a short brief, and then quite literally. It is often best practice to, to in fact, be standing up if you're in a room together because it'll go a lot quicker.

Um, you do not in a standup or a scrum, want to list an inventory of everything that's on your mind. You want to limit your conversation to, am I on track? What am I planning to do? [00:07:00] And if you have a blocker, you should bring it up. And if you don't have a blocker, that's okay. It's good. If you don't have a blocker, but.

This should be the cornerstone of every single day of the sprint, the daily stand up. Now, if you're working on something that's tricky or one of your constraints, time, resources, or scope are under a lot of pressure. I strongly recommend that you guys get together at the end of the day, two, a three or four.

O'clock this double touch, uh, point, uh, can sand a little bit, uh, Heavy duty, like another meeting, but sometimes that alignment is needed and I have actually used that project. So it's essential. Don't skip your standups or your scrums. Sometimes you may need to incorporate end of the day checkings and really allows much time for deep work or collaboration [00:08:00] throughout the sprint.

And I think that the there's a point here that it's not just about working in silos and, uh, working on your stuff. The other thing here is you need to be working, uh, In work sessions in collaborative sessions, there's nothing better when a designer and a developer get together to work on a thing, there'll be much more aligned.

It'll create efficiencies down the track. All right. So we've done planning, we've done sprinting reviewing now. W we're going to talk a little bit about, um, you know, some of the, um, The things that we see in more detail at the back of the, uh, a sprint. Um, we're going to talk about retrospectives in a following episode.

So I don't want to get into too much detail here, but here's what I do want to say. When you view your work at the end of [00:09:00] a sprint as a team, It should be open and collaborative and not judgmental, but there's an important tip here. It should be discussing not only what you did. But you also need to discuss how you did it.

Interesting thing I learned on a current project is we had a whole re...