Typically, clients and managers don't want to pay for design (or strategy) -- they want ‘results’! Too often, this leads to solutions that just don’t make sense and aren’t valuable to anyone.
Design sprints allow you to meet client's desire for quick, specific outcomes while making time to do things right. In this course, we'll show you how to plan and run situation-appropriate sprints to avoid waste and deliver value sooner. You'll explore how to do this across customer discovery, testing with Learn Startup, usability testing, and product architecture.
As a Project Management Institute (PMI®) Registered Education Provider, the University of Virginia Darden School of Business has been approved by PMI to issue 25 professional development units (PDUs) for this course, which focuses on core competencies recognized by PMI. (Provider #2122)
This course is supported by the Batten Institute at UVA’s Darden School of Business. The Batten Institute’s mission is to improve the world through entrepreneurship and innovation: www.batteninstitute.org.

JM

If the lecture may speak a little bit slowly than he has, it will be much better. The content is very useful. And the questions at end of each session are very helpful for me to recap the course.

CK

Jul 21, 2018

Filled StarFilled StarFilled StarFilled StarFilled Star

This course really takes out the creativity from in terms of experiencing something before building them. I thank Mr Alex for providing in-depth knowledge and hand-on experience.

From the lesson

Testing Approach and Architecture in Design Sprints

In software design, you have a lot of choices about what tools to use. Making the right choice is important because, in practice, there often aren’t that many really great alternatives. In this module, you’ll learn how to manage toward smart decisions and good choices. You'll also complete a peer-reviewed assignment to help you think through how to run each sprint and to determine which sprint to run next. Remember to review your peers' assignments promptly so they can earn their course certificate!

Taught By

Alex Cowan

Faculty & Batten Fellow

Transcript

Let's talk about the Architecture Sprint. In a way, this is actually a well established concept particularly in XP extreme programming, one of the methodologies we'll be learning about. There's this idea of an Architecture Spike and this is either an iteration or if it's a little bit smaller, a story that you delineate where you want to investigate a technical question of kind of major substance. So, maybe a really hard problem where you're struggling to even make a course estimate or a big build versus buy decision on a chunk of your functionality. Or if you are buying, maybe a choice between alternatives. Be those commercial or open source components. So, there's precedent for this. Now, you may be wondering, gee, I thought Agile was all about working software and not about making big elaborate plans and it's a good question. And the advice of the authors of these methodologies is that you should use these sparingly, because working software is the best way to shake out the right choices and see how things are really going to workout for you. Working software in small evidence based batches. So we're going to talk about some ideas for thinking about these architecture decisions. The decisions about approach and these are mostly for kind of larger questions about components. Things you're going to build your solution on top of. The first one is achieving focus. These decisions will be much easier if you've already completed the kind of activity that we went through in the other Sprints. So once you have a user that you understand, a narrative that you want to provide to them, problems you want to solve, solutions you want to deliver against that and tests. It'll be a lot easier to answer all the specific questions that will inevitably come up. So, know what problems you want to solve for the user and have narrative for that. That will help you focus and I guarantee you even if this seems like a sort of technical thing, it'll make these questions a lot easier to answer. And if you're going to do an Architecture Spike or Sprint or even submit a story for this, it'll make those investigations a lot clearer and more focal. My other piece of advice and a place where sometimes this activity has a little bit of a deficit is make sure you consider all the roles involved in these decisions, and this is a good place where you may want to get your team together, and have some kind of a session experience where you go through, and you really think about all the implications of these different choices. Now, not way out in the future. But if you think about the life of a component, maybe you'll come up with some non-obvious questions that are never the less quite important. For instance, a lot of these decisions will be about, well is this a good choice for developers? Can they develop against this? Is it a good fit for what we want to do? But how does that work for your testers? How does it work for say, your operations people out in the field that are managing the system with you? Can they support this infrastructure choice that you're going to make? Is it one choice harder or easier for them and is that important? Can they just train on it? Or is it going to be sort of difficult? Those are sort of good examples of important, but kind of non-obvious questions. Another good example are there sort of editors and non-engineer people, and you'd be able to come in, and manipulate items, and change them. And if so, how are these facilities for them? Does maybe one choice allow for that and another makes it hard where coders or somebody else who's busy doing other things would have to make changes that are otherwise, easy in another alternative. It's not to say that that's the pivot you should make your choice on, but all these different roles are things that you might want to assess out and delineate. So that as you go through, you make your choices you're making it against the bigger picture. Next, I would make sure to rank the problems, the jobs that you want to do where this solution, this consideration that you're making is involved. So I would start with the things that you absolutely know you need to have and they should have a massively higher priority from a decision-making standpoint and an investigation standpoint than say, things that you think you have a good notional evidence that you're going to need them, but your not sure and then things that are strictly speculative. Like a good example with the HVAC in a Hurry team, that's building software for HVAC technicians is they have a pretty good idea of the solutions they want to provide to the HVAC text, the people in the field. They have a general idea of what they want to do for the dispatchers, but that's later on down the line. They haven't done, for instance, a design Sprint to really understand that audience and what their work is really, really like and then HVAC in Hurry wants to franchise and let franchisees use the software. So they could probably speculate about what those licensees might want to do and need to customize, for instance, but that's going to be speculation. They won't really know and one of the things you'll learn about approaches to development with Agile is most of the methodologies recommend, making sure you're really focused on the problems you have right now when you build decoupled solutions for those. So rank your problem scenarios, put your emphasis on the problems you know you have now. And sometimes this will be a little bit at odds with this idea of like, well, we're making a big a choice, we want it to be far-reaching and there's no silver bullet there. I would say, you want to rank the problems you have right now higher and then you need to use your judgement very carefully about the problems you think may have in the future and figure out how much importance you want to ascribe to those. Next, you want to look at the big picture of say, a software component or a platform that you're thinking of using. What is it's scope? You just need a really narrow slice of it and it's really broad? In that case, you may be better of building it yourself, for example. Because you're going to have a lot of other strands, it's going to create for you. What is the direction of this component? Are you using it in a way that either the vendor or the open source community that's supporting it is taking? Or are you kind of using it as a round peg in a square hole, which maybe okay at the moment, but as they develop the solution further, their direction is different than yours and there maybe a parture. And that's, again, none of these things by themselves are likely to be make it or break it or really pivotal decision points, but they're things that I generally recommend you make sure that you're considering. And then next, talked a little bit about this with regard to roles, but what is the operating environment that this solution is going to operate in? So for example, can you get talent to work on this solution? That will change over time and a really new solution might be a good choice even if it has relatively few people that know it, because it's going to grow and it's a really good fit or it might mean that the component is very thinly distributed. And so, it's hard to hire people that know it. You can train them, but it's an inconvenience. And then it's harder to find documentation, discussion boards, all the kind of intangibles that make one solution more robust and sort of easier to deal with than another. So some quick ways if you want to take a quick, quick baseline on this is to do, for instance, a Google search. The programming language SWF is a new alternative to Objective-C for writing, for instance, apps on the Apple platforms. I did recently a Google search on SWF. It has 4.8 million entries, whereas Objective-C has 65. Now, that does not mean that 65 million. That doesn't mean that the one is a better choice than the other, but it just shows you that this new thing is going to have less material on out there than a thing that's been out there a long time. Two things have been out there an equal amount of time and one has massively more search results than the other that might tell you that it's just more widely circulated, used, discussed. There's community of practice around it, that's going to be a real asset to where maybe another alternative doesn't have that. Job words are another good place to do a really course benchmark on these kinds of things. I did a regional search on a job site and there were 10 jobs related to SWF programming, and 65 related to Objective-C. So again, this is a very quick way to benchmark and you'll see differences when the resolution is newer or thinly distributed in these things and then you have to assess what that means for you and whether it is important or not. The other thing I would look at is comparable's. I mean, whatever you're doing, you're probably not the first one to grapple with this question. So look at discussion boards online, places like stack overflow or something particular to your area. Try to talk to peers and colleagues that work in other environments, have your staff do the same. Just talk about their practical experience. There's no point in learning about how this works from scratch when you can go out and find out about other people's real life experiences, and all those sort of intangible goods, and bads that may really be the things that stack up, and make one choice a really great choice, and another choice not such a good choice. And finally, not always, but generally, it's a good way to do these things to make these evaluations by building a prototype. So use these other things to kind of narrow your choices that you're going to evaluate and then try to just build some sample executions. Because as Agile tells us, working software is a great way to suss out what's really important, what's really going to happen from what's maybe not important and strictly speculative. So, this is a good way to drive to conclusions. Now none of these things, by themselves would I tell you that you should always do this and this will always be important in every single case, but these are just things that you probably want to loop through and consider their implications and importance for any kind of major architecture decision that you want to make.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.