In this video, we're going to talk about what Agile is. And what we mean by Agile, what you're going to learn about it. And you may think that Agile comes from some big book. And maybe that makes you feel less than enthusiastic about it. The reality is, Agile comes from this manifesto which is only 68 words long. And the story of the manifesto is that 17 thought leaders in software development got together in Snowbird, Utah and they found they had a lot of the same problems. That their approaches to software development were overly plan driven and they felt like they were getting the kind of outcomes they could reasonably achieve.
And so, they talked about alternatives and they arrived at what you see here in this manifesto. And, basically, the manifesto says that we value an Agile, individual interactions, over processes and tools. We value working software over comprehensive documentation. Now, quick side note, they don't mean end user documentation here, they mean specs and plans, primarily. So if you think you need documentation for your end user, the signatories to the manifesto aren't telling you otherwise. We value customer collaboration over contract negotiation, and here, negotiation just means the achieving an agreement between two people, not necessarily an actual contractual document. So, we value collaborating over, you said you'd do this, you better do it by this date.
We value instead, figuring out what really makes sense for the user, and what's the best, smartest thing for everybody to do together. And we value responding to change over following a plan. This is really important, and you may have heard echoes of this in movements like the Lean Startup Movement, which we'll also talk about. And a lot of that does come from from Agile, in fact. So Agile is, in fact, the core of Agile, the thing that basically everyone would agree is Agile, is this manifesto. And it's very focal, and it's very short. And if you are achieving those kind of results and those behaviors within your team, it probably means that you're doing really well.
That you're getting really good outcomes for both your team and your users. And it's hard to get there, but that's what we're going to learn about practical approaches to actually practicing Agile and getting to those outcomes. And I think it kind of comes down to this particular moment with the individual. We'll call it the blue button moment. So in a not Agile environment, which is just to say, an environment which isn't really achieving the goals of the manifesto, we have Jane. And she's maybe a developer, or a designer, and she sees these blue buttons that she's supposed to make, and she thinks, for whatever reason, I don't think this is going to be on the mark with the user.
I'm pretty sure this is a bad idea because of things I've observed. In the non Agile environment, she's so overwhelmed with obligations, and dates, and emphasis on getting output created rather than driving to a good outcome, that she just wants to finish her work and go home. And when the software comes out, yes, lo and behold, no surprise, but users don't like it. So that is the pattern at the individual day to day level that we're trying to avoid. Let's look at what that looks like with Agile. And I think it's kind of different. So Jane has the same sort of trigger, here.
She looks at these buttons and she thinks, I don't know if this is going to be the right thing. And in the Agile environment, she feels that it's worth her while, that she's in an environment where she wants to go and talk to her collaborators about things she's observed and raise these questions about, are these blue buttons really the right thing? And what might we do instead, if it doesn't seem like the right decision. And instead, they pursue alternatives and over time, over many features and cycles, they're almost certainly going to get to much better outcomes with the user, and they're probably going to have a lot better time working together as well.
And so, when we approach the manifesto, we have to look at the outcomes we want to achieve and the we have to think about how we get there. The reality is, you can't project manage your way to these kinds of outcomes, these successful outcomes from the manifesto. You can't engineering your way to these outcomes. It takes interdisciplinary collaboration across all the different roles in the individual team to get there. And hopefully, you're able to create small, self organizing, interdisciplinary teams. And that interdisciplinary collaboration is really at the heart of the successful practice of Agile. And that's what we're going to be focused on. I'll close with a few focal points.
One, we're going to be really focused on the individual, and we're going to focus on them with testable narratives about what the user wants, both users as well as people within the team. We are going to work on this idea of frontloading value. So how do we get the most valuable things out to the user and observe whether we're really right about those or not? And on a related point, how do we focus on outcomes versus output? So if our goal is to create a high level of user engagement, we need to focus on that, and not how much software is in our next release.
Alex discusses in this video what agile means to the role of a manager, and the importance of interdisciplinary collaboration.
In the last video, we talked about what Agile is, where it came from, and we talked about why it's important. Here, we're going to look at what does it mean to the individuals on a team. And that's important, because you probably are in one of these roles, so you can start to learn about what it might mean for you. But part of your success with Agile is going to be about interdisciplinary collaboration. So it's important to also understand what it means to all the different roles that you're going to work with. Let's start with these manager roles. The project manager is typically a central figure in any software or IT project, and we'll call her Paula in this case.
Paula is traditionally going to be measured on the timeliness and the amount of content that she delivers, and Agile will absolutely help her do that. It's extremely practical, and it is a good project management methodology. But it's about a lot more than that. We're also going to help Paula learn how to create valuable outcomes. So she may be sick and tired of delivering projects on time that then go out into the world or get in front of users and achieve a bad outcome. So we're going to help her learn how to establish project charters with management that make room for valuable outcomes. Now Paula may not have a lot of experience working with the design process and designers.
And the idea of using that in a project, and the ambiguity it creates, might justifiably make Paula a little bit uncomfortable. But Paula's going to learn enough so that she's able to engage with the design teams. And not just designers, but she's able to use tools from product design on an everyday basis to work with sales and support people who are interacting with customers and learning about them every single day. And she's going to learn how to talk to engineering and QA and the implementation teams in the language of what's valuable to the user. And we're going to make this accessible to her.
Now, the project manager may be telling her, hey, we need to go out and do more research about users, learn more. And that's pretty hard to accommodate in a project if it's ambiguous what that's going to mean. We're going to give Paula tools, through design sprints, so that she knows exactly how to go out and identify what needs to be done, put it in a time box, and make sure that she's getting valuable results at the end. Whose importance she can explain to executives and everyone else on the team. Well, let's take a look at the product manager. We'll call him Pascal. His hobbies are fishing and carving things into trees. And Pascal want's to innovate.
He want's to build a breakthrough product that everybody loves. And yet, he feels like he's always overwhelmed by prioritized features, and requests from customers, and that he goes home every night feeling like he did just enough to keep things rolling. And, look, that's fine. A lot of us feel that way. But we're going to give Pascal the tools to work on the design process on an everyday basis so it's not this big, ambiguous thing that has to happen for things to be better. It's something he can integrate into his everyday work with the project people, with the implementation team. I'll give you an example of just one little thing we'll help Pascal do.
There's a classic problem where software isn't usability-tested enough. And often it's because of this circular loop of, well, we can't test it until it's done, and then, once it's done, we have to release it anyway. Well, we'll help Pascal learn how to work with the implementation team to build prototypes and structure really facile, easy-to-use test plans so that they're getting in front of useability issues. And not constantly getting whacked in the behind by them. So here we've talked about what this means for managers. Again, it really has to do with how everybody interacts with each other and their ability to use some of these common frameworks.
To talk about value and to make time for each other, to do things right in a way that drives to valuable outcomes. And in the next video, we'll look at what that means for the specialist that you see over in the right hand-side of this diagram.