Welcome to hypothesis driven development. Innovation is hard, innovation is important. This is a central reality for most of our work and probably your work if you're here in this course, and Agile is a great fit for that. It is a great way to work when we know what outcome we want but not exactly how we're going to get there, and yet, there are so many practices that you might adopt from this body of work around Agile. And week-to-week day-to-day, it's really hard to know where to focus, and it's hard to make good decisions that in the end cohere into a great outcome for your user. I think it's important to acknowledge that that's really challenging. And yes, hypothesis driven development is a way to really make your everyday work in Agile a lot more purposeful and a lot more effective. If you build software, if you deploy IT systems you probably do something like this, you have certain observations about what's going to be valuable to your user, you have ideas. You design them in some fashion. You implement them. You test them, you deploy them, and some kind of digital experience ends up in front of the user. Hopefully they like it. Hopefully they use it, and hopefully it makes them better off. But how will we know that? I think it's good to unpack our practice of Agile into these three principal areas where we can kind of think about where we need to make our team and our practices healthier. Continuous design, Agile development, and continuous delivery. With continuous design, we're really looking at, okay, how do we make the ratio of features we release to features that are big hits higher, and so how do we how do we increase the kind of numerator here? And and then also, how do we reduce this denominator? How do we just take all the stuff that's in our backlog and instead of like constantly pushing harder to get more stuff out in the hopes that one of them is going to be that thing that really moves the needle. we're extremely focused. Extremely explicit about why we're doing what we're doing and we're able to do fewer things better. Nothing will make more space for your team to work better, to think about their work like reducing the amount of things, the amount of urgencies in the backlog. And continuous design can help you do that. Continuous delivery is about how often were able to release and how hard that is. Amazon famously releases code every 11.06 seconds. It's a highly structured, highly automated process and they are closing this loop a lot. Now, you may ask, what about Agile? Agile is itself, the core of Agile is really a lot about how do we get more stuff out the door? It's about other things too. But really in practice, it's a lot about total output and that matters you got to have software systems that are getting out the door. But all by itself, without these things kind of contributing smarter more focused backlogs and without the ability to release a lot, your practice of Agile will probably always remain a little bit stunted. And so let's look at this continuous design process, one really great way, I think to think about it and kind of make it actionable and practical, and understandable for everybody is to decouple. Finding the right problem, knowing who our user is, knowing what's important to them, because if we don't know that, everything else we're going to be kind of multiplying by 0 and then moving over here and building a great usable solution for them. It's really important to be able to decouple problem and solution to innovate well, and I think we can unpack these things into discrete hypotheses about who our user is, what matters to them. Whether or not what we're going to do for them is going to be better enough than their alternatives for them to use, subscribe, whatever do to our product, and then how do we have a hypothesis about what's usable? What isn't, how we test that? And so we're going to spend some time on this area, continuous design so that we can bring stronger, more purposeful inputs to this process. We're also going to spend time on continuous delivery and our functional hypothesis. How do we know that if a given code change won't break the software and how do we know they're given deploy process is going to reliably work at scale. We'll look at the processes of continuous delivery, the practice of DevOps to make those things better. And so that is what you're going to take away from this course, hypothesis driven development. And I think it's going to make your practice of Agile a lot better and it's ultimately going to help you get get to those strong outcomes much more reliably. Let's get started.
