The Manifesto in Progress

In this video, we’re going to look at what these clauses of the manifesto actually mean in practice, with a few specific examples. The manifesto is great. It is the core of Agile. It’s the part that everyone likes and everyone agrees on and everyone wants to achieve. But, it’s not a magical incantation. You can’t just say these things and have them happen. So I’ll try to give you a little texture here about what these outcomes actually look like in an actual team.

When we say that we value individual interactions over processes and tools, that could mean a few things in practice. I think one thing that it means is that people generally in these two roles here need to spend a lot of time going out and observing individual users and figuring out what’s valuable so that they can then bring that understanding into narrative collaboration with the rest of the team. So, it isn’t to say that they specifically need to do it, but somebody does and somebody needs to drive narrative collaboration and focus on those individual interactions so that they’re of a high quality. So just saying that, that’s important doesn’t get you there.

You have to create an environment where there’s opportunities to have nice, substantial interactions. The Project Manager, what does that mean for him or her? That means they have to make space for that and instrument that narrative collaboration into the pace of the schedule. And that’s probably going to be something that’s a little bit new for them. I mean maybe they’re used to writing requirements but actually having these discussions about who is the user and how do we relate to them, that’s probably something that is relatively new to them. We’ll learn how to do that over the rest of this course. And what does it mean for the various specialists, for example, specifically?

Well, I think part of what it means is asking what the designer, Donald Norman, who wrote The Design of Everyday Things, calls the dumb questions. And he doesn’t mean that it’s an ironic statement. What he really means is they’re the obvious questions that everyone should be asking but probably isn’t. So if we value individual interactions, and we’re specialists, and we want to contribute to this environment, we ask the dumb questions. We ask, why do we think the user wants to do this? How will we know if we’re really being successful with this? And we use those to push narrative collaboration, which is what will help you drive to valuable outcomes. We value working software over comprehensive documentation.

Okay, good, and we’re maybe starting to understand what it means to look at something that actually works and we can observe rather than try to write a big long plan. But how do we actually put that into practice? Well for the product manager, it probably means helping to define testable narratives about what’s valuable to the customer. So that when they finish an iteration, the product manager is helping the rest of the project team, the project manager in particular make time to do things right and get those observations.

And for the rest of the team, it probably means keeping that narrative in mind as they develop things and figuring out at the end of the iteration and pushing everybody else, because it’s a team job, to make sure that we’re not just building working software for the sake of building working software. We’re building working software because we want to know something at the end of this that will inform what we do next so that we can get to a valuable outcome. So everybody else needs to kind of help push to make sure that those observations are instrumented into each of these iterations.

Customer collaboration over negotiation, so this is a really, really hard one. It’s so much easier, ostensibly, for if you’re in charge of the project and delivering it on time, to break it down into detailed tasks and assign specific dates to everyone and expect that they’re going to do those things, but there’s a couple problems with that. One is your plan’s probably not going to be perfect and anticipate everything. And two, if as a specialist, a contributor, you just get these very arbitrary, overly specific tasks, you’re not going to feel that motivated to keep your eye on an elevated outcome about what’s really valuable to the user. So the project manager has a real challenge.

They need to create these vivid narratives about what a successful outcome is. And give the team enough room so that they know how to get things done at the end of the iteration, because that still matters. But also where they have enough room to interpret what that means. And so that kind of loops back to frequent interactions, lots of observation about how things are going.

And finally, we value responding to change over following an arbitrary plan. Now, that is tightly related to the discussion we just had about working software. So responding to change, well you know, having no plan at all is not what agile is about. It’s just a structured, if not more structured, than the alternatives. So responding to change doesn’t just mean, I had a new idea, so let’s go do that. What it means is instrumenting change into your processes and knowing what change, what direction you should be going in. So we’re replacing the implicit ambiguity of an overly rigid plan that’s out of touch with reality with a different structure that allows us to encounter ambiguity, analyze it, and make a decision.

And so responding to change means knowing what observations are going to help you make what decisions, and that’s something that typically your project manager and your project manager roles will do and it’s something that the rest of the team should help push them to do. We going to release this, how will we know if it’s good? Asking those simple questions can actually help a lot to keep the team focused on doing what makes sense. So in this module we talked about how the manifesto actually applies to a few key interactions. And, over the rest of the course, we’ll begin to develop the techniques that you’ll need to use to actually achieve those outcomes.