Focus on what matters, a #NoEstimates advocacy post

As I sit here with my red-wine glass and contemplate the #NoEstimates discussion on Twitter for the last few days I can’t help but think that there is a key difference in how I look at Software development when compared with some of the Agile Pioneers like @RonJeffries, or @TOtherAlistair. And I want to explain some of those differences. They are too important to our profession to go undiscussed.

Tired of the same old house

First, I’d like to state that I don’t think that the construction analogies are of use anymore. It was ok to use that in the beginning of software development. Those were the most well-researched projects at that time. However, today we have a sufficient body of knowledge to warrant research and analogies from within our domain.
Also, while I know some will claim this is a gross generalization (and it is), construction is not in the Complex domain, while software is. If you follow any of the #Cynefin discussions you know that approaches suited to the Simple domain are not suited to the Complex domain. In my view most construction projects are in the Simple domain (not all), and most software projects are in the Complex domain (again, not all).

Change the context, or your project will fail

One other thing that makes me focus on the #NoEstimates approach to software development is my realization that the existing context is not well suited to software development. The context where Estimates are mandatory, and you will be held accountable for years to come; the context where teams are asked to “commit” to a plan that they know very well may not be possible to achieve; the context where we base all of our approaches on our belief that predictability is easily achievable in long term software development efforts.
I want to promote the #NoEstimates approach because I want to change the context surrounding software development. I’ve learned enough to know that software estimates don’t work, and I know a better alternative!

It’s the customer, simply!

My approach to implementing #NoEstimates is centered on discovering value, because I assume that I don’t have all the answers up-front. Since I recognize that I don’t have all the answers, I’m ready to accept that the definition of the work to be done will change (not might, will!). So I focus my energy on discovering that most valuable work to be done. This requires that I focus on defining small increments of customer-value (instead of large chunks of “work”). I use User Stories (and Epics and Features) to help me build a vocabulary that leads to a constant dialogue around value at all levels in the company. And I’ll let you in on a secret: Sales people don’t like estimates either! Why? Because they want something out ASAP and if you tell them that they need to wait another 6 months they will hate you. Estimates or no estimates. Sales people understand something intuitively: they need value to sell. The longer they wait the more uncertain they are about that value. It is that simple.

I believe #NoEstimates is a better way to manage software projects

It is this simple. I’ve used #NoEstimates, I recommend #NoEstimates and I use #NoEstimates in my own work. Discover the value, deliver the value in the thinnest slice possible, rinse and repeat.
There are many concrete ways in which you can generate dialog around value, and ways in which you can enable very thin slices. Some have been published (Naked Planning by @arlobelshee being one example), others are just being discovered and experimented with.

Estimates have failed, are you looking for alternatives?

The Estimation approach to software development has failed us for too long. It never really worked in the projects I participated in (and I used it a lot) and we always ended up using the only available tool to us to meet our deadlines: manage scope.
So I recognize that an approach focused on helping companies and teams zero-in on the valuable parts of the their projects and delivering those first, helps in Risk Management, focuses on welcoming the changes we know are coming instead of sticking to the plan (estimates *require* a plan, otherwise what are you estimating?), and more importantly it requires customer collaboration for it to work. Unlike Estimates that focus on contract (the estimate) negotiation.
How to use #NoEstimates to manage your project? Take a look at an example I published a few months ago, and the data that supports this approach. After all, #NoEstimates is firmly grounded on empirical data collected over many (22 at last count) projects. Again, unlike estimates which by definition are not based on data. Estimates are rather guesses about future events.
Have you experimented with some form of #NoEstimates? Leave a comment below. Let's keep the conversation alive.

Strategic Product Management challenges: from idea to products in the market

Photo by Clint Gardner @ flickr (CC-BY NC SA 2.0)

I wanted to start this series by focusing on some of the challenges that we face as Product Managers. A key challenge I see repeated in many organizations is the lack of capacity to leap from idea to results, from intention to implementation.
Product Managers focus on generating product ideas, business model, revenue streams, competitor analysis, etc. But that is quite useless unless it leads to coherent action, and ultimately to delivering products to the market. In fact delivering on an idea is - in my mind - the only valid evaluation for a great Product Manager.
Do you have a great idea? Do you know the market very well? Good, but where is the product? No product, no value.

Company strategy is a first step in covering the gap from goal to action: define the goal

As I stated in the previous post, the Strategic Product Manager must focus on translating the company strategy into a coherent Product Portfolio. This is the process of transforming business objectives into concrete product goals. However, that is just the first step in covering the gap from ideas to implementation.
A common pitfall is that once the Portfolio is approved the Product Manager retires from the involvement with implementation. Later, when deciding on what projects to start the teams involved will make critical, strategic decisions. If the Product Manager is not part of the decision process, how can she make sure that her Vision for the product is implemented?
Having the best roadmap and then implementing the wrong projects is equivalent to having a bad roadmap.

Now that you have the roadmap, how will you execute on it?

Product Management must work with the line organization, with the teams that will develop the software and do what often does not happen: to transform ideas into action! For this to be possible the Strategic Product Manager must be equally capable of transforming the implementation feedback (from the teams) into information that will influence our ideas about strategy (product roadmap and product portfolio).

Ideas are nothing without execution.

A key aspect of the Strategic Product Management is to be involved and review the actual projects started and reassess the product strategy, product portfolio and product roadmap based on what is possible to implement once the rubber meets the road and the product development starts.
To effectively implement a product strategy the Strategic Product Manager must be part the decisions on team and resource allocation to certain projects. Reviewing and giving feedback on a second and important portfolio: the Project Portfolio (which projects are started, how much investment they get and when they should stop?).

Castles are built with rocks and mud, not clouds

Strategic Product Management is much more than just thinking big thoughts. Strategic Product Management is about creating the necessary relationships and information flows in the organization, that will allow the implementation teams to execute on the strategy for the company and the products. Later in this series we will take a look at some of the practices that help both the Product Manager and the Organization to transform a great Company and Product strategy into a coherent Project Portfolio. These will include organizational as well as project techniques designed to help convert ideas into real value: products in the market.

What is Strategic Product Management? - solving day to day problems with the long term in mind

Photo by Giovanni Orlando @ flickr

The release day is close. So many things to do, how to prioritize what to do next? How to discern what is really relevant from what is seemingly urgent, but with little impact in the product? How to make decisions with a cool head when faced with a looming deadline? Many teams are stuck with these questions and have little support or help to understand how to overcome these questions.
One team that I worked with at some point coined the phrase "being a slave to the backlog" to describe the feeling of powerlessness, and being imprisoned in the relentless rhythm that took them from story to story through overtime and much stress without a clear vision or direction. They truly felt slaves to the backlog.

Seat of the pants Product Management

In the best case some teams might just take the problem by the seat of the pants and soldier through the project, delivering consistently, but losing any motivation or innovation potential that a more sustainable approach might give them. After all, there’s a reason why Scrummers are constantly remind us and themselves that we should aim for "Sustainable Pace", the mythical marathon rhythm that will take you through the death march.

Some step back, understand what it is that they you trying to achieve

This is not what software development is supposed to be. We are supposed to feel confident that we know the direction we must take. We are supposed to feel secure when we make decisions on what to do, and most importantly what *not* to do. How can we achieve that feeling of purpose and serene conviction of understanding the problems we are trying to solve?

Enter Strategic Product Management.

At first Strategic Product Management may sound like a mythical god-like creature that is here to solve all our problems (and indeed for some teams it will at first feel like that). However, Strategic Product Management is something much simpler. It is the set of practices and habits of creating a more concrete Vision as you go and being able to apply it on a day-to-day basis: to avoid the Siren’s song of Urgency and Fire-Fighting; to help us re-check our purpose at every step of the development process.

Why Strategic Product Management?

All decisions we make affect the quality and the Vision-fidelity of our product. It is when we are most in a hurry that we need crystal-clear decision criteria that lead us to the Product Vision we created. It is because of these that we must always "begin with end in mind" and define our Strategic Product Goals (aka the Product Vision) and regularly review those based on the feedback we collect throughout the development of the product.
However decisions about what to focus, prioritize or remove come at unexpected times, and all throughout the project, and it is because of that Strategic Product Management must be conceived as a set of cycles, of loops of learning that guide our development work. Strategic Product Management is the act of putting your day-to-day work in the context of what you are trying to achieve and focuses on these areas of work: Strategy, Portfolio and Roadmap
In a later blog post I’ll outline the detailed practices that I have been experimenting with to put in practice what I’ve now tried to define: Strategic Product Management.

Innovating in how we build organizations, networks and happy lives: The Happy Melly project

Photo: Fr Antunes @ flickr

It all started in a sunny Autumn day in Konstanz, Germany. With the Alps and the Bodensee lake (aka Lake Constance) in the background Jurgen presented a simple idea: there are people out there who hate their jobs and want to actively transform their workplaces to make them the kind of places where Melly would feel happy to work. This was a proposal I could not resist because it was so well aligned with my self-assigned mission: help people find workplaces that make them happy. The Melly character quickly took over the image in our minds of that person that has worked for many years in the same job, unhappy but with the sense of responsibility (and probably a mortgage) that makes her "bring home the bacon" as the phrase goes.

We've all been Melly at some point in our lives. I know I have.

Fast forward to October and our story continues in Rotterdam Utrecht, a city filled with small houses precisely aligned along the canals of the old city. Rotterdam Utrecht is a city of action, a young city with a strong positive vibe. This was the right background for the three of us (Jurgen, Maarten and myself) to have our "constitutional" or Vision-sharing reunion. As we walked through the city, enjoyed the amazing urban landscape and learned about towers we talked, brainstormed and came closer to understand where the project should focus.

As this project started I knew only Jurgen. I had never met Maarten face to face before (we had communicated on Twitter), but I felt an immediate connection. In today's world building relationships has become easier, and that is key in this project. We want to help you all make the right connections. The project starts with a simple vision: help people help each other. And we want to do it in a way that is itself an example of the changes we want to see in the world: we don't like static of slow organizations, we like connections, we like people and that is what Happy Melly is about. Happy Melly is a project that aims to help you transform your place of work, make a difference.

The Happy Melly project is one more step in my journey to help awesome people like you do amazing things. Life is too short to be a Sad Melly, I want to help you be a Happy Melly. Check out our presentation (where we explain the project further and how you can join) and let's start a conversation about how we change our world, even if only a little bit.

You are all invited!

Impact Mapping, what is it good for? A quick review

If you've paid any attention to twitter lately you know that Gojko Adzic has publihsed a new book. The book is called Impact Mapping, and describes a method to describe a system in a way that:

helps the practitioner create better plans and roadmaps that ensure alignment of business and delivery, and are easily adaptable to change

As this is a quick review, let's get straight into the meat. What I liked the most was the way that Gojko uses a simple mind-map approach to try to see the "whole" of the system.

If you have followed this blog you know that I consider myself what some people would call a Systems Thinker (although I like to call it "In search of the hidden connections"). What I see is that this practice of Impact Mapping has the potential to help many teams finally implement a systems thinking tool when describing the systems under development.

The book is also filled with suggestions on how to facilitate Impact Mapping in practice. This is a light-read section of the book, filled with detailed advice and some anecdotes that Gojko shares in the hope that it will help you get started with the method. But perhaps the key value I take out of this book is the neat way in which it fits between two tools that I've used in the past: The Business Model Canvas, and the Build-Measure-Learn cycle from #LeanStartup.

Impact Mapping fits nicely in between the Business Model Canvas and the Build-Mearsure-Learn cycle from #LeanStartup

In fact, I believe that Impact Mapping is a very interesting tool that can generate the insights from the Business Model Canvas and directly translate them into a product design and later into experiments. As I read the book, I felt intuitively more comfortable than when reading and practicing Story Mapping. However, this is only an assumption that I will have to test soon.

How about you? Have you read the book? Have you used the practice? Share your experiences with the technique in the comments. I'm interested in learning more about how the practice is used in real-life projects.

The perfect gift for a geek...

So, as you have probably noticed: winter is coming. With it come the long evenings, the rainy or snowy weather and the unstoppable need to curl up with a good book by the fire place. Perhaps even drinking Glöggi (Mulled Wine).

It just so happens that I have found a great book for you! Edgar Daylight wrote and published this year a book about a theme that is crossing our thoughts constantly: Software Engineering. His book is called The Dawn of Software Engineering and looks at that critical time when computer programing was starting to develop. His approach is quite interesting. He revisits the language debate (which is still raging today): should languages be designed to run fast (computer-oriented) or should they be more "readable" by humans (people and readability oriented)?

Although this debate takes a different form today (interpreted vs compiled languages) it is an illustration of how some debates are still alive today in the Software Engineering community.

I had a lot of fun reading about those debates as they happened in the 70's! :) There are other interesting accounts, like why LISP became a functional language (did you know it was not supposed to be that way?)

But what I found most interesting aspect of the book was the historical account of how some programming languages got developed and led to the development of different hardware. The way Edgar Daylight describes the interplay between languages and hardware design is truly fascinating and a must-read for anyone interested in the history of our profession: Software Engineering.

Happy readings! Full reference: Edgar G. Daylight, The Dawn of Software Engineering - From Turing to Dijkstra

A better way to predict project release date!

Many people commented on my previous post about Story Points, and how there are much better ways to estimate Agile projects. In this post I'll concentrate on one project where the predictive power of counting the number of stories/items completed/iteration was a better predictor of the release date and the scope delivered than story points. As I was going around Europe and presenting my talk on Story Points Considered Harmful, I always got very interesting questions. The most common:

But aren't Story Points much better at predicting the release date and scope delivered than the method you propose?

Despite all of the other reasons not to use Story Points, I decided to tackle this question specifically. And the results are in! Story points are less accurate when predicting the release date and scope delivered, than just counting the number of stories (or items) delivered per iteration! This seems counter-intuitive because we have less "detail" when we merely count the number of stories delivered. Many asked me:

But if you don't know the size of the work how can you predict when it is going to be done?

In God we trust, all others must bring data

Before speculating, let's look at the data! The case I want to present is: a long project (24 iterations) for which we collected both Story Points and number of items completed per iteration. I had one question with two sub questions in mind:

Which metric (SP's or # of items) was a more accurate predictor for the output of the whole project?
a) When we calculated based on the averages for the first 3 iterations
b) When we calculated based on the averages for the first 5(!) iterations

Why this question is important is that, if we can predict with high accuracy the output of a project based on the first 3-5 sprints, we have a good case to stop doing up-front estimation altogether! After all, investing 3-10 weeks in actual development delivers much more information about the product then spending 2-4 weeks in Requirements/Architecture/Design discussions (not to mention that it bores people out of their minds!)

So what were the results? First of all a disclaimer: this is data from one single project; we do need more data to make a better case for not estimating at all! See below for more on how to contribute data to this project! The results are in, and counting the number of items is a better predictor than Story Points based estimations!

When we try to assess the release date and ammount of scope delivered based on only the first 3 iterations. Using Story Points overesimated the output by 20% (!) in this particular project, while counting the number of stories/items delivered underestimated the otuput by 4% (yes, four percent).

How about if we increase the sample and take into account the first 5 sprints? In this case the Story Points based prediction was more accurate, but it still overestimated the delivered scope by 13%, while counting the number of stories/items underestimated the output by 4% (yes, four percent).

In this project, the answer to the question: "which metric is more accurate when compared to the actual output of the project?" is: Counting the number of stories/items delivered at the end of each iteration is a better predictor for the output of a project than estimating based on Story Points delivered!

Final note, how to contribute data to this study

The case I presented above is based on one single project. We currently have data for more than 20 projects and 14 different teams; but we need more data to investigate the claims I make here and in the previous post.

I call upon the community to share the data they have. I have made my contribution by sharing the data I have collected over the last years in a world-accessible spread-sheet that you can see and download here.

Please share the data for your projects in a google-doc or similar world-accessible spreadsheet and leave a comment below with the link to the data. For us to learn more about how to better predict project outcomes we need to be able to look at a large data set. Only then we will be able to either verify or destroy the claim that Story Points are useful for our projects. Thank you all in advance for your contribution! Photo credit: NASA's Marshall Space Flight Center @ flickr