Agile is great, but…
Agile is awesome. Nearly every Product Manager we know would agree. But I bet you’d be surprised by how many conversations we have with product leaders around their questions, issues and sometimes not-so-stellar experience with agile development. Questions & comments like:
- Our product managers/owners feel constantly overwhelmed working day-day with dev, we have no time for innovation!
- Anyone else have confusion over roles within their agile teams, or is it just us?
- How are others dealing with technical debt, our seems to just keep growing…
- Do you need to have both product managers and product owners?
- We can’t expect our product owners to also be strategic…can we?
Agile is so clear about roles, and ceremonies. Backlogs are groomed continuously to focus on the highest priority. Customer Value is built right into the manifesto. So, why are there so many “we love agile, but…” conversations in the product management community. What’s going wrong? We have a hypothesis on why this is happening, and a proposal for a universal fix across all agile teams. Let’s start with three assumptions that we have about how we believe products should be built.
- Before you build…You know what is important to customers. There’s a loaded sentence. We built an entire business helping companies get this right. Anyone can create epics and sets of user stories — that’s easy. That’s how exploding backlogs happen. Because it’s just so easy to create work, and agile is a well-oiled machine designed to keep churning out work in tidy increments. But, as we all know, outcomes aren’t equal to effort. And meaningful business outcomes are those that prove we’re providing value — because customers buy and continue to invest in the products we deliver. All that comes from deeply understanding your customer.
- Before you build…You can define the customer problem. That doesn’t mean being able to describe all the incredible features you’re building. It does mean being able to state the customer problem that exists, independent of your product ever being launched in the world. That means, there are lots of ways to potentially solve the problem, but you (team, company), are uniquely positioned to deliver a solution that will win in the market. And btw, the problem should be a big enough pain that the customer is willing to pay to make it go away. When you can do this, you know you’ve got an important problem to solve.
- Before you build…You have a vision and a roadmap. A roadmap is not a rolling collection of features — it’s a clear, well-thought out, logical and prioritized map to achieve a vision. Having a vision is what allows you to make tough trade-off decisions, and it’s what keeps the team (and you) energized and motivated to make it happen through all the ups & downs of development. Having a vision starts with #1 & #2 above — knowing what’s important to the customer and what problem you’re solving.
If you buy into these assumptions — then let’s talk about how you can leverage them to make a big impact on how well agile can work for you. This is based on years of experience working as a product leader with with dozens of agile teams, and from our coaching practice improving the ways that product managers and product owners can succeed working within agile development.
You have to know where you’re going. Remember the bad old days of waterfall development? If you don’t, lucky you! For those of you who shuddered when we asked the question — you had flashbacks of writing massive requirements documents. But, the one (and maybe only) good thing was that it forced you to think about where you were going. You had to think about the big picture before you could break it down to endless requirements and (depressingly) writing down every possible exception. We’re not suggesting for a second we go back to the dark ages. However, what we’ve missed in our head-first dive into agile is providing the team with the big picture in a way that’s meaningful. That doesn’t mean one flashy PowerPoint slide of a vision, or some high-level product mockups which makes your CEO happy. We’re talking about providing a real schematic that offers a picture of where you’re going, and enough details that allow the teams working with you to ask great questions, offer alternatives and help improve the overall solution.
Let’s say you were giving the job of building a house, your first step probably wouldn’t have been to assemble a building crew, and say to the foreperson — we’re going to get started and build a room at a time. Let’s see where end up! Before you had a team start to pour concrete, or put up framing, you would have worked with an architect to create a plan. The inputs to that plan are customer needs. Imagine a home for a young couple, mobile, working from home, wants amenities/access such as pool/gym…and then think about a family with 4 kids, one member is in a wheel-chair, they entertain a lot, generally home-bodies. Very different needs, very different home. Your understanding of how the home would be used, the people who live inside, what they would do within their home — all of these are critical elements in understanding the type of building we’d create. We don’t expect a building crew to start building without a plan — and the opportunity to ask questions, and maybe suggest some changes that would make it cheaper to build, or offer additional value elements for the same price. Because they understand what you’re asking them to build — they can have a voice.
The same is true for a product — we need a picture of our customer, what she cares about, her habits and attitudes — and through understanding this, we enable our teams to imagine a real person that we’re building our product for. A product manager’s job is to provide this picture. Agile wants you to know these things -it really does. It just doesn’t give you any time to make it happen. If you forgive agile for not building in a ceremony just for product management, then it changes the way you will look at your development cycle. The way to coach teams to provide this critical information is to develop and share a Product Scope. A Product Scope gives the schematic, the plan for what you’re planning to build, it provides a picture to the team so they can imagine it. They can then connect with you on the plumbing, the electrics, they may even suggest shifting rooms around, or describing a completely different approach which you never imagined. This will happen because you have everyone on the same page, then…you can begin Sprint 0, start planning and happily create epics and write user stories. You all know where you’re going.
Having a Product Scope will change your experience with Agile
We’ll talk more about how to create a Product Scope in a follow-up post and the product work needed before sprint planning. We’ll give you a hint — writing kick-ass Product Scope documents comes from deep customer understanding, which starts with setting up hypothesis, ideating, prototyping, testing — all with customers.
Before we close, just a couple of extra agile tips for kicks. Spikes are not your friend. A lot of the time, we see customer research being placed on a sprint plan as “research spikes”. A spike, technically is something that is not clear to the team, or can’t be estimated well. The whole purpose is to provide an answer or solution so that the team can get going again. Assigning points to research is meaningless — your entire product success rests on your ability to learn from your customers and build that into every sprint. That’s right — you should be learning from your customer EVERY sprint. That doesn’t mean fitting them into research spikes. btw, spikes aren’t great for the team either, it impacts velocity and timelines and all the things your scrum master cares about. Don’t use them.
Build in Time to Watch Customers. Technically this isn’t an actual way to make agile work for you, but it’s just the very best gift you can give your team. It works whatever development method you’re using. It will change the way your team work. We suggest at the very minimum once a quarter, you should provide a way for your team to spend time watching customers. It will dramatically change the customer value your team delivers.
What other agile and product management tips do you have? Share your comments and thoughts.
