Using #NoEstimates when deciding which projects to take on

One of the questions (Part I, Part II) that emerged from the #NoEstimatesQuestions discussion on twitter was: “How do I choose between options or opportunities (without having estimates regarding the cost)?”

The thinking goes: I can spend some time doing A or B, but which should I do first? To answer this question we can look at it from two angles:

• 1) How much does A or B cost and how long to they take?
• 2) How much will I learn from doing A or doing B? Which knowledge is more important for me now?

The first point of view assumes that both A and B have similar value (or Return) and that the investment part (the I in ROI) is the most important factor. I happen to think that in software this is not the case. In my experience the R (Return in Return On Investment - ROI) is often more important than the Investment in defining the overall value of a certain decision. In my experience, the second approach will help you make a better decision when selecting between different options. Asking yourself "what is the value I expect to get from option A or option B?" is often a much more insightful discussion regarding the Business Model for your product or service. Here is how I would answer the question: “How do I choose between options of opportunities (without having estimates regarding cost)?”

• Step 1- Define what you expect from doing A and B. Example: A) If I implement “login in with facebook” I will expect to have more users to access the site due to the simpler registration. B) If I implement “invite a friend” I expect to have more visits to the site and ultimately more people registering than if I choose A.
• Step 2- Now, break the work down into risk-neutral chunks (i.e. chunks that don’t kill your project if you fail to reach the expected goal). This leads me to goal decomposition: given that I can’t test any of the options by tomorrow, is there something that I can test by tomorrow which would help me choose futher? Can I implement the “invite a friend” feature by tomorrow? Yes: great! lets do that. The reason is simple: by tomorrow I can start to test option B, if I had gone with Option A I would have to wait longer to be able to test my expectation.
• Step 3- Now it is time to get to work, deliver the smallest/easiest possible implementation of “invite a friend” by tomorrow, and review the impact of that feature. Once this functionality is live you can can either continue with B (if more changes are needed), or ask yourself what are the next options you need to decide on.

How to tackle Large Problems(™)

The example above will, rightfully, called a “simple” problem. So, the next question is: what if I have to decide between 2 Large Problems(tm), which can take several years of development and months of deployment? For example:

I work in the Ministry of Health and I need to decide between developing a large system to manage the health-care records of 10’s of millions of people, or maintain an existing system with potentially huge costs.

In this environment the Return part of the ROI equation is not easily accessible. In fact, one could argue that in this type of projects the I (or Investment/Cost) is the most important factor in making a decision. Most governments do that and spend considerable amounts of time estimating the costs of both options (with terrible consequences). #NoEstimates asks for a completely different approach to these problems (where cost is the key factor in deciding). In fact I would work to completely eliminate the “develop new system from scratch” option from the table. The reason is simple: we are terribly bad at estimating large software projects, so we should avoid them completely. Instead, we must use the flexibility of software to our advantage: start small and slowly grow the team as well as the final technical solution. How I would do it:

• Step 1- Determine what is the most operationally critical part of the system (e.g. by number of people assigned to work on that part of the system, or by contingency plan size -- don’t spend time estimating criticality, there is plenty information already available). Don’t start by changing this part of the system - it is far too critical (as you just determined). Select any other part of the system that you can change without any long-winded approval processes (random selection is ok, but you probably have a hunch).
• Step 2- With a small team (say 5-7 people) start a 1 week project to change this part of the system (a new version of the same software, including tests to ensure that the new implementation works as expected). Can’t do it in a week? Select a smaller part of that system component until you can. Don’t bother estimating, just ask the team until most agree it can be done. In parallel start listing, every day, other system components you will need to change next. Use the ideas in Step 1 to prioritize that list. By the end of week #1 you will have the first “changeable system component backlog” (don’t worry about the comprehensiveness of this list, you will update it every constantly).
• Step 3- By the end of week #1 you should have a small part of the system component re-implemented to the new standards (maybe a new technology? maybe a new privacy law?). Now ask, how many such components do you have to change to complete the project. 10? good, then it will take 10 weeks or so (don’t worry about being right, you will update your projections as you go)
• Step 4- Take the next part of the system and start another 1 week project. Later you may want to start more than one part of the project by adding one more team. But don’t add all teams at the same time

In this approach we try to achieve the following:

• Evolving understanding of the system in terms that can be used for data-driven progress projection (a- changeable system components backlog, b- how many system components can we change per week?)
• An evolutionary change to the system in a way that the system is always functional and the project - even if stopped prematurely - constantly delivers value to the owners of the system (in this case the taxpayer).

Conclusion

I’m sure that there are still quite many questions about the steps and approach I described here. Leave those questions below so that we can continue the dialog.

The #NoEstimates questions, Part II

Last week we did not cover all the questions on #NoEstimates. Twitter gave us a lot more questions than could be listed last week, and even more interesting ones. Read on for the questions and my take on their meaning.

How do I choose between options or opportunities (without having estimates regarding the cost)?
• Choices are hard to make. When you are deep into the development process you inevitably come up with many ideas. But how should we choose between all those ideas without a detailed estimate? I believe this question implies that we have no way to assess the opportunity cost of selecting one of the options. I propose we challenge this assumption in a later post.
How to win a government contract without estimates?
• A very common question, also present implicitly in last week’s post when a questions asked: How to practice #NoEstimates in companies where estimates are "mandatory"? When the legal framework (or contract) requires you to provide an estimate of the length of the work you just have to do it, of course. But a more interesting question to tackle will be: how do we use #NoEstimates to our own (and the customer’s) benefit even when we have to provide estimates before we can win the contract?
What visual indicators do you have in #NoEstimates to show if you deviate from the "optimum"?
• Are we going in the right direction? Are we progressing towards the goal? Do we have the right features? Will we be on time? There are many implicit questions behind this one. While exploring the answers to these questions, I hope we can generate “heuristics” that are relevant and actionable for people interested in the “end game” for a project or a delivery. Including heuristics based on visualization.
Will #NoEstimates give me better predictability even when not using estimates?
• The holy Grail: predictability. In my view, the temptation is to say: if you have time-boxes you don’t need more predictability, you already have it. However, I think this question goes beyond “delivering on time”. In fact, I believe that this question is about predicting “everything” (scope, quality, cost, length, …) We have to explore what #NoEstimates can help with, and what it can’t help with when it comes to looking into the future.
If I just "play the game" with project managers and give estimates that I know aren't right, am I already doing #NoEstimates?
• This question is perhaps related to the one above where we tackle how to use #NoEstimates in an environment where we are asked to provide estimates. It must be said that lying (providing information you know not to be true) is not right, deceiving is not right - no matter what method you use to manage your projects. I hope to clarify how my practice of #NoEstimates can help you tackle the estimation requests you get, but still benefit from the added information #NoEstimates can provide.
Is there some analogy between SQL/NoSQL and Estimates/#NoEstimates?
• Many people comment on the choice of tag (#NoEstimates) for this wider discussion on estimating and managing projects. It is true that if you look at the hash tag used and the previous SQL/NoSQL discussions there is a similarity in the surface. However, I think there are further similarities between these two movements. I’ll explore those in a later blog post.
Does #NoEstimates aim to change existing social constructs (e.g. capitalism, budgets) to remedy the need to estimate?
• As far as I understand this question explores the possible impact and consequences of #NoEstimates, including on the budgeting cycle and the business models. I don’t think #NoEstimates tries to tackle business models at all, in fact I think it aims to enable more business models. On the other hand, #NoEstimates does try to change the way we look at budgets - project budgets at least - with the aim to make those more transparent and reliable. This topic promises to be very interesting as it has generated a lot of discussion on twitter.
Is it accurate to say #NoEstimates is for projects in Cynefin's complex domain?
• For those of you that haven’t followed the Cynefin model or Complex Systems discussion, let me just clarify that Complex Systems are such that causality can only be attributed in retrospect, i.e. we cannot anticipate how the system will react to a certain stimulus, therefore we must experiment (Probe-Sense) and Respond to the results of those experiments. While I believe that #NoEstimates is a perfect fit for Complex environments, I don’t think it applies only in that domain. There are benefits to be gained in other domains: Cynefin/Complicated, Cynefin/Chaotic and even Cynefin/Simple.
If we elect not to take on the risk of predicting an uncertain future, who do we think should, and why?
• I believe this question is trying to answer: Who should take the risk for the (future) results of our actions? Obviously I think we - the people in the project - should take the responsibility for tackling the project in all its characteristics and risk. I don’t think #NoEstimates leads to a shift of the risk carried in any project, and in fact I believe #NoEstimates approaches can be much more effective at uncovering and tackling emergent project threats or risks. More on this later.
Why would we choose not to judge likely outcomes, when worthwhile human endeavors necessarily carry risk?
• My interpretation of this question is that it asks: Should we even look into the future at all? Equating #NoEstimates with #NotLookingIntoTheFuture is a red-herring in my view. I’ll try to explain in a later post how, in my view, #NoEstimates approaches can deliver a much better model of “the future” for any project.
What is and isn't 'estimating' when people form and act on expectations of an uncertain future every day?
• If I remember correctly somebody tweeted: “how can you say “don’t estimate!” when even the act of getting up in the morning requires estimating?”. Perhaps this comment comes from a misunderstanding of the domain we are talking about when we use the term #NoEstimates. It is important to state that we are using #NoEstimates in the context of estimating large software endeavors (i.e. projects), not simple tasks or even fixed/variable-costs calculations (e.g. servers, bandwidth, person-hours, etc.).

This is the list of questions that I’ve collected in the last few weeks on twitter. I hope to answer them here on the blog with your help. Please contribute to the prioritization of these (and last week’s) questions by leaving a comment below with the questions you’d like to tackle first.

Once prioritized, I’ll start answering those questions and we can have a longer discussion about each of them here. After all, twitter, is a great conversation starter, but we need blogs to develop them further ;) Photo Credit: Brad Hoc @ flickr

The #NoEstimates questions, Part I

There’s been a pretty active discussion on #NoEstimates over on twitter. There seems to be a fair ammount of people interested in learning more about how it is applied. Me, I’m interested in developing #NoEstimates further. How?

Last week I put out a call for action. I asked people to post questions about #NoEstimates with the #NoEstimatesQuestions hash tag. Below I list the questions I got and what I believe they mean (after all, twitter does require some parsing as you will see). Read on for the questions on #NoEstimates from the twitter community.

The #NoEstimates Questions, Part I

• How to practice NoEstimates?
• This is a question that I get quite often. At the core of this question is the need for some kind of recipe for practicing #NoEstimates. Many people getting started want to know what steps to follow (Shu-level). Unfortunately many of the #NoEstimates practitioners are beyond that level, and I do think that providing recipes to get people started, is a task that our community needs to take on. How does a Shu-level practitioner get started with #NoEstimates? I hope to write a few posts on this during the next few weeks.
• How to practice NoEstimates in companies where estimates are "mandatory"?
• This questions is related to the previous one, but it adds an interesting twist: “my boss requests estimates from our team, how do I use #NoEstimates in that case?” I’ll have a few tips on this in a later blog post. This is likely to be a very common scenario for people learning about #NoEstimates.
• How does #NoEstimates fit with GAAP accounting rules?
• In most organizations, certain standards for accounting must be followed. Stock-exchange listed companies particularly, need to follow GAAP accounting rules. It is only natural that we must provide some guidance on how #NoEstimates can fit those contexts. As I’m not an accounting expert I would really like (and need) to find someone that would help us create some guidance on how to reconcile GAAP accounting with #NoEstimates. I know it is possible, but we need an expert view on the topic. Do you know anyone? Are you a GAAP expert? Ping me on twitter and let’s talk.
• How to know when a project is finished if we don't estimate?
• This question comes in many forms, this is just one way in which I get this question asked. The thinking goes: if we don’t estimate how is it possible to know when we will be done? Additionally, this question seems logical at first blush. But it isn’t. Estimates are a very poor way to determine when projects will end. In a company where I worked, we listed all projects in a 2 year period. In this total of 17 project the average delay to estimated completion date was - are you seating down? - 67%. Yes, 67% AVERAGE delay. So, it is possible to know when the project will end by using #NoEstimates, and I’ll claim that it is far more accurate than using estimation to determine completion date. But that is content for another post. Stay tuned.
• How can we decide to start a project if we don't have an estimate for the time it will take?
• Another very common question, a fair question for people that are getting familiar with #NoEstimates. I hope to clarify that the assumptions underlying this question are not valid, and provide a set of ideas that will allow decisions to be made without going through estimation-driven cost assessments.
• How does the #NoEstimates concept fit with contract negotiation?
• Recently I’ve been getting questions regarding the use of #NoEstimates in a contracting environment. This is a questions that affects outsource or subcontracting relationships and as such, it affects a large portion of the software industry. I’ve been following what Jacopo has been doing in his application of the concept of Black Swans to contracting. I think that we can apply some of his lessons learned to the #NoEstimates concept. This will, I hope, clarify how #NoEstimates can be applied to contracting in a way that benefits both sides of the contracting relationship.
• How do I know that my budget is reasonable?
• If you are developing software with the help of a third-party you will inevitably ask yourself: Is the budget they request reasonable? As I understand this question it tries to find the “sweet spot” of project cost so that the vendor does not rip you off, but at the same time they are motivated to keep their developers in the project long enough for you to get the software you need with the right level of quality.
  I believe that this kind of trade-off is fundamentally flawed, and I hope to provide ideas on how we can find new ways to contracting software that are beneficial to both vendor and buyer, but also support the use of #NoEstimates.

What's next?

These are some of the questions that I’ve collected from twitter, but there are plenty more to come.

In the next blog post I will cover the second part of the list of questions received. After that I would like to engage with you here on the blog to try and answer each of these questions from the #NoEstimates point of view.

Stay tuned and be active, asking further questions as well as providing your insights and challenges to the answers I’ll provide.

To Be Continued...

A Big Thanks to...

I want to give big thanks to all those who engaged on twitter and helped collect the key questions that we need to answer:

• Agustin Villena
• Ari Tanninen
• Geert Bollen
• Henri Karhatsu
• J. B. Rainsberger
• Kevin Sivic
• Lennon Shimokawa
• Marko Taipale
• Sven
• Wanja Krah

Photo credit: Sebastian Alvarez @ Flickr

How Agile is disrupting the Manufacturing Industry #DisruptAllTheThings

When you have spent a few years researching and practicing Agile software development you tend to not be surprised by new developments. I know I wasn't... until I saw Joe Justice at #ALE13.

Joe is working on a project to build a car that will disrupt the automotive industry. You don't believe me? Well, what if I told you that they are building a car that costs (with profit) USD25000, has a 5-star equivalent rating and achieves 1.25ltr/100km (or 100 MPG)? Still don't believe me? What if this car could have any part changed as quickly as you change a tyre on a normal car? Yes, even changing the engine is that quick!!

All about this car is revolutionary, but the most revolutionary part in this project is how they are building the car. Joe presented Xtreme Manufacturing as a method that puts together what we have learned in the software industry through Extreme Programming, Scrum, Test Driven Development and other methods.

You see, the thing that will be the most disrupted by Joe's work is how cars are built. Cars are built in Billion Dollar/Euro factories. Every time some part changes it costs millions to change the machinery necessary to produce that part. Not in Joe's project - Wikispeed! The Wikispeed car has a carbon fiber body. They can change the whole body with a few 100's of Euros worth of investment and in about 1 day. That's how fast it is.

Joe and the Wikispeed team have been able to take a 7+ year process (design + manufacturing) and turned into a few weeks. There is no doubt in my mind, Wikispeed will forever change the car industry. Now if you excuse me I have to go meet some car industry executives...

Check out Joe's presentation at TEDx Rainier

And here is a tv show explaining some of the cool details of the Wikispeed car itself

Photo credit: brewbooks @ flickr