What is Agile?

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.