In this video we're going to walk through what Agile is and how you apply it as a product manager. We talked about how, if you're at that higher level of abstraction, you may interface to Agile teams but not actually be a product owner, not actually be part of them. Regardless, understanding the foundations of Agile is extremely important. A friend of mine who's a developing manager once said to me about their use of Agile, you just can't take a nine-month idea put into two-week iterations and get these great Agile outcomes. Regardless of the level of abstraction they are operating at, it's very important as a product manager that you're able to take a big idea and break it in the small batches where you can meaningfully vet that idea and test whether it's really going to be valuable or not. And that's really at the core of your practice of Agile, is how do you able team but also, how do you take your own concepts and approach to them in a iterative fashion? A lot of people think Agile sucks at big companies because it's been this big standardized thing that's kind of hoisted upon them and there's a lot of kind of aping and stuff and they don't like it. So one of the things I always lead with when I'm explaining Agile, is that the Agile manifesto was actually only 68 words, it's extremely simple and focal and it's really useful to know what it said. It's that we value individual interactions over processes and tools, so we think that standardizing and treating people like cogs in a machine doesn't work very well. And that making sure people interact together in the right way is more important. We think that looking at working software is more important than comprehensive documentation. By this they mean big long plans, specifications if you will. And so these people had learned that we make these big plans because we love the certainty and then we create software that isn't valuable to users. So it's more important to do stuff and see how it is, then talk about it and write big long specs about it. We think collaboration is more important than negotiation. They don't necessarily mean legal contracts here, what they really mean is, it's more important to collaborate and work together to do what makes sense for the company and the customer. Than it is to say, all right, well, this is your deadline and that's your job, you just get your job done and I'll do my job. Well, that doesn't work very well, people just end up kind of measuring their efficiency locally and that doesn't work very well at the future of the product or the company level, it produce crappy stuff. And If this sounds familiar, if this sounds like lean startup, lean start up is in its way a derivation or an extension of Agile. We think it's more important to respond to change because change is inevitable, I think its one of the implicit assumptions here, than it is to blindly follow some plan. I think I would take stock of these things and bear them in mind because I really think they will help you be a better product manager. Now agile, this is where the Agile Manifesto is posted and these are the signatories. A lot of these folks were, at that time were working on internal software for companies, where they really kind of knew who the users were and exactly how they would use it. There has been a lot of extensions to Agile since then, in particular around, how do we bring the tools of human centered design into the Agile process. So that if we're making product that is going to have external customers that's in this hyper competitive environment, that we are able to test for value iterative and quickly because that will help us deliver better product. And that's really what lean startup is about, not to mention all the design techniques you've learn about. So in a way, lean startup is kind of this agile extension or it certainly builds on agile. The use of Design Sprints which we'll talk about is another way that human centered design and Agile are kind of merging or human centered design is getting packaged in a way that's more workable on a repeatable basis for teams within an organization. DevOps, if you've heard of that, was an extension of Agile that deals more with the intersection of development, along with testing and operations or systems administration, so that part of the development picture. And so Agile really has seeded and helped push forward a lot of really positive developments in engineering and product development at large. Focal points for Agile that I think are worth noting are that we really focus on the individual with testable narratives called user stories. This is really important, so rather than talking about everybody wants this or people do that, we really focus on the individual. We make testable narratives, we translate those quickly into usable software and see if anybody cares. All along those same lines you'll hear about front loading value. I didn't really understand what this meant when I first learned about Agile. But now I really, really get it, we want to pick the best parts of the product, the things that we think are really cool and get them out there, ASAP so we can see if we're really right about that or not. And it's interesting because I think the hardest thing about really internalizing this idea of front loading value is admitting that this stuff that you think might be really awesome, it might not be. So you better find out quickly to see if you're right or not, otherwise you could create a lot of waste. And this is probably the hardest thing, especially in a larger organization is we're focused on a certain outcome that we can observe and measure. Not on generating, doing our work, checking things off of our list and generating a certain kind of output. And so chartering a team, we talked about problem-centric charters when we talked about how you were going to relate to your management, for example. That's really where you're focused on, what outcome am I trying to get? Tell me that and then I may generate different output, I may do all sorts of different things to get there. You know Agile is working in this blue button moment, I call it. So, a developer, a designer, she's looking at these blue buttons that are in a sketch or she's started to build in a bad environment. In an environment where Agile is not working she says, you know what I'm under so much deadline pressure and I'm not that bought in to all of this. I'm just going to finish my output which is to make these buttons blue and I'm going to go home because that's what I feel like doing. And then the sad ending is that the users don't find the software very appealing. In a high functioning Agile environment, instead she says, I'm going to go talk to my counterpart. It could be somebody else on the team, the product owner, the product manager, and I'm going to share why I think these might not be a good choice for the user. They discuss an alternative and maybe they decide to pursue it, and in general that team is going to get to much better outcomes with regard to the user particularly over time and across iterations and releases. Also the core ideas of Agile and how they apply to you as a product manager. The most important thing is to be able to break your ideas about what's going to be valuable, what's at the intersection of that desirability, feasibility and viability. Into small testable pieces that you can translate into nice vivid actionable inputs for the Agile teams that you're working with.