Agile and product management

In this video, we’re going to walk through what Adro is and how you play it as a product manager. We talked about how if you’re that higher level of abstraction, you may interface the actual teams but not actually be a product donor, not actually be part of them. Regardless, understanding the foundations of Agile is extremely important. A friend of mine who’s a development manager once said to me about their use of Agile. You just can’t take a nine month idea, put it 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 the product manager that you’re able to take a big idea and break it into 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 enable the team, but also how do you take your own concepts and approach them in an iterative fashion? A lot of people think Agile sucks at big companies because it’s been this big standardized thing that’s kind of foisted upon them. And there’s a lot of kind of aping and stuff and they don’t like it.

So one of the things that 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 said 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 for the customer. There it is to say all right. Well, this is your deadline. 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 with the feature of the product or the company level. You produce crappy stuff. And if this sounds familiar, if this sounds like lean start up, 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 is one of the implicit assumptions here, than it is to blindly follow some plan. I would take stock of these things and bear them in mind because I think they’ll really 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 the time working on internal software for companies, where they really kind of knew who the users were and exactly how they would use it. There’s 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 hypercompetitive environment that we are able to test for value iteratively and quickly because that will help us deliver a better product. And that’s really what lean startup is about, not to mention all the design techniques you’ve learned 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 humans center design and Agile are kind of merging, or human center 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 kind of 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 working software and we see if anybody cares. Along those same lines, you’ll hear about frontloading 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. Were focused on a certain outcome that we can observe and measure. Not on doing our work, checking things off our list and generating a certain kind of output. And so charting routine, we talked about problem centric charters, when we talked about how you’re 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, designer, she’s looking at these blue buttons that are in a sketch, or she 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 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. Those are 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.