13
Aug 12

The Best Way To Understand Agile

I was chatting with Jason Tanner of Enthiosys the other day, and he asked me how I defined “Agile Product Management.” What follows is more or less my answer, formatted a bit for the purposes of the blog.

First, what is agile?

All my discussions of “agile” anything start from how I describe agile at the 30,000 foot level, with the following rules:

Sprinting! (A sprint car at Eastbay Raceway in Florida, by jokerswild1963, CC 2.0 licensed)

  1. Figure out what you want to do
  2. Figure out which of those things is the most important (“predicting the future” step)
  3. Do the most important thing until it’s done (“done-done“)
  4. Go back to #1

Each time through that set of steps is an iteration or sprint, and you’re likely to have a lot of sprints before you get to a release.

I contrast this explicitly with the comparable rules for “waterfall”:

  1. Figure out what you want to do
  2. Figure out how to those things in #1 most efficiently (predicting the future step)
  3. Do those things in the most efficient order

It’s a subtle difference when shown this way, but the difference is critical, and for a number of reasons:

  • Each time through the agile process (each iteration) you have the option to define a new set of “things to do” – this means you can respond to the market, or realize that your original idea was wrong, or realize that you can’t actually accomplish your original idea, or refine the idea or design to be better, whatever it might be.
  • All management disciplines suffer from the fundamental problem that predicting the future is hard or impossible. No matter how much you know, your predictions are likely to be wrong, and to get wronger as your prediction horizon extends. The benefit of agile is that your horizon for predicting the future is very short – what’s the most important thing to do right now? – while it’s very long in the waterfall case – “what’s the optimal way to do all these things?” As a result, the damage to the project from incorrectly predicting the future is much more contained with agile – to a single sprint or at most a few sprints. In lean, it might be contained to an even smaller increment.
    • (Sidebar: Why is predicting the future so hard? Three reasons – one is that things change, so what seems important today might not be important tomorrow; second, you might need working code to understand what you really want; finally, development estimates are never over estimates – everything always takes more time than estimated, never less time.)
  • Agile explicitly supports the Pareto Principle (or the 80/20 Rule), while waterfall doesn’t have a good way to do that. In other words, in any set of things I want to do, 20% of them will give me 80% of the benefit, and in agile I make sure to do that 20% first.

Applying these ideas to product management

Given this, how do I define agile product management? The steps for agile product management are no different than they are for other agile activities (like agile project management, what we usually mean when we say “agile”). Figure out all the things you want to do, prioritize the list, and do the most important thing on the list, then repeat.

What does that mean in practice? It means don’t spend time on unimportant things. Always know what’s most important (how I determine that is covered in another post), and focus on getting that to “done done” before doing something less important. And then when you’re ready to start again, redo the list, and reprioritize. As a product manager, I make a list of the features needed by the customer or the market, prioritize it, and write detailed requirements for the handful of the most important ones. Those I then socialize with the engineering team, both to get their rough estimates, as well as qualitative feedback on the feasibility of the features, open a conversation on what the feature really is, get ideas and innovations from engineering that might make the feature more valuable, and so on. That’s one iteration – then I do it all again for the next iteration.

Contrast this with a non-agile approach to product management. I’d start with the same list of features for the system, then write all the requirements, in enough detail for engineering to estimate them all. Then, after a lot of discussions, covering all the requirements (let’s hope we don’t miss an important one!) I got the (wrong) estimates from engineering, I’d then lay out the tasks in an optimal way to get all those requirements delivered, balancing a desire to get full functionality with a need to meet certain market milestones. Because I’m predicting the future, the resulting schedule is guaranteed to be wrong, and it will always be wrong in the undesirable direction.

But there’s some stuff missing!

At first glance my definition of agile may seem simplistic, and even missing something – where is all the stuff that people usually think of when they hear “agile”, like Scrum, sprints, retrospectives, velocity, and all that?

My point is that agile is not about specific tools or techniques (although agile methodologies may define or specific tools or techniques) – it’s a mindset about getting the most important stuff done-done as quickly as possible.

But let’s expand it a bit more and talk about where all that “agile stuff” is – or rather, where it arises from given my definition. For example, there’s a claim that agile teams keep getting faster, and they work more collaboratively and generally are superior to teams that aren’t using agile. But what’s really happening is that if you run a project based on my definition of agile – whose primary output is to get the most important things done first – you get lots of additional desirable side effects. You not only have a much better approach to the project management side, but you get to take advantage from a management perspective.

If people are always working on important stuff, then they are going to be more motivated to do a good job – this will improve quality over time. And if we’re getting insight – and corrective action – into how things are going on a very short timeframe, like a two week sprint, then we can apply changes directly when they are needed, and over time we can apply a LOT of changes. Simply doing a retrospective every sprint, rather than every project, gives you a lot more leverage, for three reasons:

  1. The problems are still fresh so it’s easier to see solutions
  2. The solutions you apply early on benefit the entire rest of the project
  3. You end up getting to apply a lot more solutions.

If you only do a retrospective at the end of the project, as in waterfall, then you’re going to forget some of the problems you had, you’re not going to be able to fix all the problems you do remember because the change will be too big to do at one shot, and only the next project will benefit, not the one that just finished. All in all, a nearly complete waste.

In fact, you might want to think of my rule #3 as having a sub-step – “3.5. Take advantage of your new experience to improve your process.” That will happen every iteration, and you’ll get better a lot faster.

That’s the primary way you get better as an agile team, although there are a few other well-known practices you can apply that will immediately start to give you benefits, like team programming and other collaboration approaches, making sure that everyone on the team takes responsibility for getting to done-done (meaning that developers sometimes do a lot of testing, and testers contribute a lot to development), and always having a deliverable product.

What do you think?

Does this definition of agile resonate for you? Do you use another formulation that captures the key driving benefit of the agile approach? Do you have additional questions about agile and how all the benefits of agile arise from this simple set of rules? Let me know in the comments.

I’ll post again soon about agile, specifically answering why these rules result in getting better quality products to market faster. That’s another promise from the agile camp, and it’s interesting to think through how it happens. And we’ll touch on how to talk to management about agile. Management has historically liked the waterfall approach, because people it appears to be predictable – although the predictions are always wrong (way wrong). Agile seems suspect to management, on the other hand, because you can only say “we’ll get the most important stuff done first,” but you usually can’t commit to when that will happen.


07
Jun 12

How to Prioritize: Top 6 Techniques

Too much to do

As a product manager, one of the fundamental issues you will have in your life is that you will have a lot of things to do, and you won’t be able to do them all. Whether it’s the list of features and capabilities you want to implement in your product, or the customers you want to visit and get insights from, or the anthropological studies you should be doing with prospects in your market or the market you want to get into, you will not be able to do everything you want. This means you have to prioritize your activities, and what you ask from your developers (i.e., in terms of features), but you also have to be able to defend and justify your priorities to your supervisors, to the business, and to the people who are executing the work you have specified.

Priority!

Prioritization is a critical capability for product managers

In this post I outline some of the basic concepts of prioritization, which we will explore in more detail in future posts. I’m not going to cover everything there is to know about prioritization, but give a number of techniques that (typically in combination) you can use to help you make better decisions about what to do. Better, at any rate, than simply flipping a coin. Of course, nothing is guaranteed – as many a product manager has discovered before me, you can make the best decisions in the world and your product may still fail for reasons beyond your control. But if you want to have the best shot, here are some of the things you should think about.

Techniques of prioritization

I’m going to write this as though the priorities were new features for your product, but the same ideas work for other things you might need to prioritize:

  1. Trust your instinct – more on this in a future post, but remember that one of the reasons you are a product manager is that you have specific expertise about the product, or the space, or about decision-making per se. So your gut feelings are likely to be decent. On the other hand, if you’re like me, you want something more concrete to backup your decisions.
  2. Analytics – either qualitative or quantitative. The types of analytics you can use to support your decisions varies widely. For example, if you have talked to several customers about a new feature, and they’ve all said it would be highly valuable to them, and your gut says most customers would get value from it, that might be enough “analytics” to move forward. Analytics can get a lot more sophisticated, of course – people use spreadsheets comparing the revenue outcomes for different combinations of features, and tools that graphically illustrate how well a set of requirements satisfies a set of prioritization criteria based on a market model, to tools that use “option pricing” and other advanced financial techniques to give you a numeric priority value. Analytics are the best tool in your toolbox for defending and justifying your decisions.
  3. Stack ranking, and ignoring things at the bottom of the stack. Part of being a good prioritizer is not getting weighed down by the stuff you’re not going to be able to do, no matter how desirable it is. One way to help you achieve this clarity of mind is to stack rank your new features, with the most important ones – determined, perhaps using your gut instincts backed up with some analytics – and then ignore everything in that list after the first ten items. This is a fundamental technique from agile software development – once you have decided what is the most important feature to deliver, concentrate on delivering that feature and ignore anything else that’s lower in priority. Once the most important feature is delivered (or complete and ready for delivery), then you can revisit the stack-ranked list, review the ranking, make any changes necessary, and then focus again just on the top items.
  4. Doing tests with a “minimum viable product” or MVP – sometimes you have an idea of whether a feature or a tactic will be valuable, but you need validation from the market that your instinct – which we can call a hypothesis in this case – is correct. As in real science, you test a hypothesis with an experiment, which in the world of lean software development has come to be called an MVP – a minimum viable product. The phrase “minimum viable” means “the minimum amount of development needed to test the hypothesis.” Sometimes an MVP is as simple as a webpage, while sometimes it can be a complete development project in itself – it completely depends on the hypothesis you’re testing. The point is that you are not doing any more work than you have to in order to find out if your hypothesis is correct or not.
  5. What’s the worst thing that could possibly happen? The process of prioritization always has winners and losers, and one way to test whether your prioritization is correct is to do a thought experiment. For each of the candidate features, ask yourself, what is the worst thing that can possibly happen if we don’t deliver the feature? You can use the answers to this question for each feature to minimize the worst possible outcome. Of course, it’s very possible that not delivering a new feature won’t have a bad outcome, but delivering it would have an very positive outcome, so you can’t use this as your sole decision-making criterion.
  6. Make sure that your boss’s pet feature is handled. This may sound a bit cynical, but remember that you’re not just optimizing your development team’s efforts to deliver value, but you’re also optimizing your own career – your success depends on you delivering good products and on staying employed and keeping your boss happy. If your boss has a feature that he or she really wants to see in the product, then that feature has extra weight in your prioritization – you might still cut it, but you need to have an especially strong story for why that had to happen.

What prioritization techniques do you use?

That’s a few quick ideas on how to do effective prioritization of features into a release, or in general how to prioritize anything in your career (or life). Let me know in the comments if you make use of these techniques or if you have other prioritization tools you like to use.