02
Jun 17

How To Talk To Your Executives About Agile

People have asked me “How can I get my execs to support an agile transformation? They don’t like that they can’t predict anything.”

Reframe the Agile conversation around value

Graffiti on a wall spelling out the word "Value"

Orient the conversation around value, not around methodologies. (Picture credit below)

This is never going to be an easy conversation, but I recommend reframing it from the outset. Don’t talk about scrum or methodologies or the Agile Manifesto. Instead, talk about delivering value to the market and how your products and your company can be more successful.

Among the things keeping executives up at night are the following three questions:

  1. How can I get higher quality products to market faster?
  2. How can I motivate my teams and help them improve?
  3. How can I stop failing in my predictions of what we’re going to deliver?

Help your executives sleep better

If you take these questions to heart, you’ll find there are solutions. And as you implement these solutions, you end up doing agile or something that looks very much like it. (Another way to say this is that you implement agile to get good answers to those questions.)

  • To get higher quality products to market faster, you need to focus on and prioritize adding the highest value capabilities to the products. And you must stop adding low value capabilities. You get two benefits from this. First, because you aren’t working on lower value stuff, the time the team spends is intrinsically higher value. And second, your team is naturally going to be more motivated because they are working on higher value stuff. Focusing on value helps with the first question and part of the second question.
  • I’ve already talked about how to motivate your team more effectively. How do you help them get better? How do you accelerate your team’s learning cycle? You make the cycle of review and learning a lot faster. The “retrospective” is a key part of the scrum methodology for just this reason. The team does its learning as closely as possible to the action. It also helps if you can have the team accomplish things on that short cycle as well. You may need to do clever partitioning of those important things you are working on.
  • There’s only one way to stop failing in your predictions. You must stop trying to predict the future. We all know it doesn’t work. Even if you have a concrete plan, with “good” estimates, you will not hit it. (It’s never been done.) Instead of predicting what you will deliver when, use a value-based approach to talk about what’s coming. You can confidently say “Every release will have the most valuable capabilities we could deliver in the time frame.” You may not know exactly which capabilities those will be in advance. But you can be confident they are the most valuable things you could possibly deliver. So rather than focusing on hitting a schedule – which is an internal target that customers mostly don’t care about at all – you are focusing on delivering value to customers – which customers do care about, which is much more valuable.

Value and velocity – related but not the same

I’ve separated maximizing the value of the results the team delivers from continuously improving the team’s ability to deliver.

These two ideas are often munged together in agile discussions. Indeed, by focusing your team on delivering value fast, the team naturally gets more motivated and faster.
But the second half, of accelerating the learning of the team, is not necessarily about “agile.” The practice of retrospectives or debriefs gives you the other dimension of team improvement – continuous learning. To accelerate continuous learning, you need to make the pace of the retrospectives faster. It’s much better to do learning near the actual experience. And since agile methodologies have short sprints, doing a retrospective for each sprint is a natural way to accelerate learning.

From Value-focused to Agile

If you combine all these thoughts, there are four aspects that combine to make more productive teams:

  • Making sure you’re always working on the most important thing or things
  • Continuous learning
  • Not predicting the future
  • Fast paced iterations

And, if you have those four things, you get four side effects, all very valuable:

  • Agile as a side effect
  • More effective teams as a side effect
  • More revenue faster as a side effect
  • Higher value products to market faster as a side effect

And there’s one other side effect. If you are working in order of importance, you can also push that practice back to the requirements and planning stages. The product managers only need to write requirements and do planning on the next most important capabilities. Requirements for less important capabilities can be delayed until they are needed. This means the development process can start sooner. And that accelerates your time to market even more.

How you can put this into practice today

Here are three things you can do today to start putting these ideas into practice.

  1. Start thinking about value value value, all the time. Only work on the most valuable things you can. Or, to put that another way, don’t work on things that aren’t valuable, even if they are cool or fun.
  2. Make sure your development team understands the value of what they’re working on. You can use the template I mention in this article to help: This New Template Helps You Write Better Product Requirements.
  3. When you talk to your execs about agile, don’t talk about agile, but about delivering value to market faster. Which results in higher revenue and more profits. Execs are typically much more interested in higher revenues and profits than they are in development and project management methodologies.

Image credit

  • “Value” by J.Lightning. Copyright (c) 2011 J. Lightning, Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0) 

07
Feb 14

The Right Level of Abstraction, Also Called “Chunks of Value”

For every human activity, there is an appropriate level of abstraction to talk about it. Often there’s a big picture, and there are details, and somewhere in between is the really meaningful stuff. In baseball you can talk about who won or lost the game (big picture), and you can talk about each pitch (detail), but baseball’s at its most interesting at the at-bat and innings levels. This is where the manager is putting most of his or her attention during the game, even though he or she is judged at the end of the season on the big picture of win/loss ratio.

For product managers, the big picture is the release. And the detail level is the tasks that the programmers are working on to create the functionality. But the most interesting level for product managers is the “chunks of value” level. Elsewhere I use the term “feature,” and you can also call them “requirements” or “user stories” or any term you like. But the clunky, clumsy term “chunks of value” gets to their real meaning – value that I could deliver to the customer or market.

Some of the basic facts around chunks of value:

  • There are always more than you can deliver – demand outstrips capacity
  • Any given chunk of value is more desirable for some customers than others, and is better aligned with some of your marketing goals than others.
  • Some chunks of value are very large and might take multiple releases to deliver fully, while some are very small and can be completed in a day or a week.
  • Chunks of value are related to what customers ask for or say they need, but they are not necessarily the same. A customer’s request or desire usually represents one way, and usually not the best way, to address a deeper need that the customer is not able to articulate (that’s your job).
  • Simply delivering the chunk of value in some form is no guarantee of success. You need to make sure it’s delivered in a usable, engaging, pleasing way.

 —-

This is another excerpt from my upcoming new book, a template that product management organizations can use to automate the PM process. Look for it soon from an e-book distributor near you. To be notified when it’s available, please sign up for my mailing list over in the right sidebar.


20
Aug 13

The Importance of Tools To Product Managers and Other Humans

In a seminal 1962 paper Doug Engelbart outlined a research program that came to be called “Augment,” short for “augmenting human intellect.” He illustrated the importance of tools to human progress with the following story about the pencil and how society might have evolved without it:

For one thing, the record keeping that enables the organization of commerce and government would probably have taken a form so different from what we know that our social structure would undoubtedly have evolved differently. Also, the effort in doing calculations and writing down extensive and carefully reasoned argument would dampen individual experimentation with sophisticated new concepts, to lower the rate of learning and the rate of useful output, and perhaps to discourage a good many people from even working at extending understanding. The concepts that would evolve within our culture would thus be different, and very likely the symbology to represent them would be different — much more economical of motion in their writing. It thus seems very likely that our thoughts and our language would be rather directly affected by the particular means used by our culture for externally manipulating symbols.

Why do I go on so much about tools? Better tools are key to improved productivity, and productivity is what creates value. All major transitions in human history have been related to new tools.

ABANA style treadle hammer

A treadle hammer, which multiplied the productivity of blacksmiths. When you attach it to a water wheel or to steam power, it helps usher in the Industrial Revolution (image by tmib_seattle, CC 2.0 license)

And product managers are the last group without tools of our own. Everyone else has tools that help them do a better, faster, higher quality job, and that are specific for their needs. Developers? Interactive development environments (IDEs) like Eclipse or Microsoft Visual Studio, plus source code control (SVN or Git), build tools (Jenkins), libraries (JQuery), bug trackers. Engineers? 3D cad systems, finite element modelers. Accountants and finance people? Any number of ERP and backoffice tools. Salespeople? CRM systems like Salesforce.com. I could go on.

But product managers don’t have tools. Or rather, we have a book-writing tool – Microsoft Word – and a finance tool – Microsoft Excel.

That’s why I spent seven years at Accept, working on a tool for product managers. That’s why I blog so much about tools and why we don’t have good tools (yet). And why I’m so excited to see a number of tools coming to market now and recently.

I’ll be posting soon on another batch of product management tools, all new, that I’ve heard about in the past few weeks, as a follow on to last week’s post about Aha, ProdThink, and The Skore