I thought we would take a second and recap a few things from Agile and the applied practice of innovation. If you already know about these things, this won't be long. And if you don't already know about these things, this will give you a brief intro and I think you'll probably just kind of understand them in context as we go through them in the course. But if you want to take a pause at any point, you can find backup resources on them in the resources section of the course; some readings and quick tutorials you can read to get a little more depth if you wanted. The first thing, is the Agile manifesto itself. And this is probably the only thing that everybody would agree is in fact Agile. And this was created in 2001 and it basically said we think that individual interactions are more important than processes or tools. This is important, so you don't kind of over Agile your Agile. And we think working software is more important than comprehensive documentation. By documentation they don't mean documentation you have to provide to the user, although hopefully that's at a minimum because your software is really usable. What they mean is big specifications and requirements documents that you do up front. And we think that collaboration is more important than negotiation. By this they mean really just the negotiation between individuals. So, "Hey when can you do that?" "Oh, by Friday." "Okay, you've contracted with me you are going to do it by Friday." And they're not saying that all this stuff over here on the right is completely always bad and never do it. They're just saying you know on a relative basis, these things on the left here are a lot more important. And finally, following a plan is less important than responding to change. And this is probably the most important thing and it's spawn lots of other thinking about innovation like, for example, lean startup if you've heard of that. There's references on this tutorial Agile just the basics in the resources section, if you want more about kind of what's Agile and what does it really mean? We're going to use this venture design process as a way to just think about the sequencing and interrelationships between a few really key innovation practices that are widely used in delivering good outcomes for teams that are doing digital. And the reason for this sequence is basically that as you go through this process, your options narrow and it helps you think about when should we kind of be exploring and thinking about a lot of possibilities, and when do we really need to zero in on something that is specifically right or specifically wrong so that we don't just build a lot of junk and hope that the user finds what they want? Because that's not a good way to build stuff or deploy software. That results in a lot of extra expense and very bad outcomes most of the time for the user. And then, of course, cost is going to escalate as we go through this process. So, for example, it's a lot more expensive to go out and talk to some subjects, some users about what's on their A list, what problems are important to them and then to test whether our proposition is going to be valuable enough for them and then create good user stories and good prototypes. So, really think about what we want to do for the user. All that stuff is of course less expensive than building actual software or deploying software and getting it up and running and maintaining it. One thing you saw in the beginning there was these problems scenarios and alternatives. And the idea here is that whenever we're going to do something for the user, we should understand the problem scenario, the underlying job or desire that we're going to deliver on. And we should understand what alternatives they have today because our proposition, whatever we're going to do, is got to be better enough than the current alternatives at solving this problem that it's actually worth doing. For example, let's say we're building some IT software for people that repair heating and air conditioning systems to go out and look up parts. Well, the underlying problem scenario would be finding parts availability and pricing. And their current alternative is that they have to call the dispatch or the central office and wait and get a price and a timing back while their customers are waiting and they're figuring out where they should go, should they go to the next job or should they stay? And our proposition is if we build a piece of software where they could self-service to look up parts availability and pricing, then they would engage with it and use it, and it would deliver better outcomes for the customer or higher customer satisfaction and lower times on site. And so, that is an example of how we would structure these things and you'll see a few examples of that in the course. Next, we look at really basically the practice of lean startups. So, how do we structure those value propositions and think about ways to test whether the customer is adequately motivated or not to have our proposition? And then finally, we look at user stories. And you've probably used these if you've done Agile. They have these three clauses as a persona. So, some user that we've seen and we can think of five examples and we've hopefully spoken to them and asked how their job is and what are the top five hardest things about doing accounting here or keeping your CRM up to date? And we're going to help them do something so they can derive a reward. And what's really important about this last clause here is this is a testable reward. So, we have a user story. As an H-back technician, I want to look up parts availability and pricing so that I can figure out my next steps on the job. We could put a working prototype in front of them where they find that parts, see it's availability and pricing, and we can ask them, "Okay, let's say you have to go tell the customer the price and the timing on this part, what would you tell them?" And if they know what to tell the customer from what they're seeing, then that's a positive outcome, a pass. And if they can't figure that out, then it's a fail. It means it's not usable enough. And here's another example of a user story just to kind of texture this out. I send the salesperson. I want to update the lead to indicate I visited them so I know the rest of the team is up to date on the account. And so that is the way that we will go through and kind of think about these innovation practices. Another thing I'll call attention to is the relationship between user stories, prototypes and usability testing. This is the user story is really important because as we saw, if we have a nice clear testable reward that tells us what patterns we should look out for prototyping and it tells us what things we should be looking for as a pass fail criteria for usability testing. Those are the few innovation practices we'll be referencing throughout the course. If you want more depth on them, check out the resources. And otherwise, we're going to go onto the next thing and get our hands dirty.
