One of the things that has come out of the discussion on #NoEstimates is the notion that estimates provided by development teams are often guesses and committing to guesses is foolhardy. So I’d like to explore the difference between these terms as we know that the language we use to communicate is important.
Webster’s definition of estimate is located here. What I find interesting is that word guess is used a couple of times in the definition. Other searches also provide guess as a synonym for estimate. So I think we should cut people some slack when they use the words interchangeably. That being said, let’s agree that these dictionary definitions are just too generic and are not what are being asked for in software development. Let’s add a little bit more substance and define estimate as:
An approximation/calculation based on the observation of past behavior/performance/data, significant analysis or expertise
and guess as:
An approximation/calculation based on intuition absent of the observation of past behavior/performance/data, significant analysis or expertise
With these definitions, we can make the statement that an estimate is the product of some significant rigor while a guess, has little to no rigor to it. However, many of our guesses are influenced by past behavior, performance or data to some degree. Enter in guesstimate which lies somewhere between a guess and an estimate. (Where exactly, I’m really not sure). It’s important to note that all three can be right or wrong. All three can be useful (or not). They don’t guarantee outcomes. However, we may have more success basing decision making around a meaningful estimate over a guess or guesstimate.
Based on my experience developing software products from scratch, there are generally two classes work found in such environments:
- Work that looks like work we have done before
- Work that is different from work we have done before
If a lot of the work you do falls in the first category, then estimates are probably a perfect fit for you. You most likely have enough historical data to use for your approximations. However, the product companies (commercial and internal) that I’ve been a part of do quite a bit of the second type of work as we add new and innovative functionality to our products. Some will suggest that someone else has done the same thing somewhere, but its not the same as doing it in your own product, with your technology and with your team. No two environments are the same and this is may even be truer for knowledge work environments.
So if you happen to do the second type of work, how do you provide an estimate (not a guess or guesstimate) in the absence of relevant historical data? You will have to use analysis and/or expert judgement upfront. There are estimation books that can provide guidance on these techniques. The point is that there needs to be some rigor upfront in determining the estimate.
I’d suggest that in environments where the work is different from work done in the past, this upfront rigor may not be as beneficial as one may think, simply for the fact that the team is probably “learning as they go”. I realize “learning as we go” does not apply in some environments, but on the teams that I’ve been a part of, we’ve continued to learn about the new capabilities we were delivering even as we worked on them. The degree of learning varies but it still occurs. It’s the nature of the work we do. Your work may be different.
My observation/experience is that guesses and guesstimates are very often provided in the name of estimates for this second category of work. It’s not estimations fault but its what occurs. For example, an estimate provided on how long it will take to fix a bug when its not known what’s causing the bug is probably a guess (or at best a guesstimate). I could be out on island when it comes to this observation but I’d like to think that I’m not alone. I’ve even been guilty of asking for these estimates, um, I mean guesses in my own career.
So when you ask for an estimate, make sure you understand what it is you are actually asking for, how it’s being derived, what it is that you actually receive in return and what is being committed to. Better yet, ask yourself a #NoEstimates question: is an estimate (not guess or guesstimate) requisite to getting the work done in the first place?
This post is a followup to my tweet on possibly scrapping projects. This post is particularly aimed at those who want to engage a team in software development project work for them. It may also be of value to those who do the work.
What is a project? According to the PMI website, this is what we find:
It’s a temporary group activity designed to produce a unique product, service or result.
A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.
And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal.
I want to focus on the “temporary” and “defined scope” part of the definition as I believe this to be center to the conversation. Scope is the amount of work/features/functions/etc that we agree need to be completed in order for the project to be done. Fixing the scope inherently makes the project temporary as at some point, the scope is met and the project ends. In non-product development disciplines, the defined scope most often equates to what is required for the item to be usable. On the surface, this seems simple and straightforward enough but its important to note that in these disciplines, usable very often also means finished. For example, the scope defined for building a bridge would include the fact that bridge is usable (it can convey people from point A to point B) and to be usable, its needs to be finished . By and large, very little to no additional work will be done towards its original purpose. The product is not finished until the project is finished. There is no use for unfinished bridges except for pretty pictures.
This behavior does not necessarily hold to form in software development. In fact, (largely) unfinished software is used every day in many spheres of life and we have no problem with it at all. Think of all the software you use, personal or commercial and all the updates you or others make to it. It doesn’t matter whether its some application you created to help automate some personal activity or business software that you are involved with. It doesn’t matter whether its software for internal use or to be distributed to a mass market. Software evolves and evolves quite rapidly. We are continually adding stuff. The only time it doesn’t is if its a class assignment or the software is no longer being used.
Why does it evolve so quickly and often? It evolves because in spite of our skill and adeptness, we can only see so far into to the future as to anticipate our needs. Even when we enumerate all the user stories (if that’s what you do), we still end up discovering as we go along. Software development is by and large an exercise in discovery. It is critical to gain a true appreciation of the nature of work one engages in to fully exploit it. In addition, the software development tools available to us allow us to make changes to our systems faster than we’ve ever been able to and this only going to improve as time and technology progresses. Unfortunately, we still rely on (industrial age) methods that predate software development to manage how we actually do the work.
So why does this matter to you dear client? Because I believe that you shouldn’t be ignorant when working with those in my profession. You can decide to kick-off a project with some defined scope upfront and then lock it in but we’ll charge you for every change request you submit, tell you “it’s out of scope” or pull something out to put what you want in. When we’re done, you’ll have a product that is usable but unfinished because you’ll realize that there were things that you missed that you now want that may be even more important than what you have. Those of us who have done this for a while knew this would be the case, but you wanted a project didn’t you. Because you are human you are going to feel unsatisfied and disappointed but we’ll remind you that this is a project and that you (not us) determined (fixed) the scope. Because you really need those features, you’ll decide to kick off another project with us. You’ll make subtle changes to the contract with us to protect yourself and the cycle will just repeat itself. The cycle will most likely repeat itself a couple of times. I hope it doesn’t lead to low-trust and a contentious relationship between us but in many cases it does. But hey, you decided you wanted a project.
On the other hand, you can decide to break out of the project mold and just decide that you are going to continuously invest in your product until it no longer makes sense for you to do so. We’ll work together as partners to identify what capabilities are needed first. We’ll develop and deliver those. Then we’ll identify what’s next and repeat the same process. We’ll change priorities as we go because we didn’t lock ourselves into a plan that no longer makes sense. We won’t waste time arguing about fixed scope, we’ll just get things done. We won’t spend hours having our lawyers review the contracts so that no one feels cheated. We’re in this together and for the long haul. You’ll still have usable unfinished product(s) as we go along but I think you’ll feel differently about things, in fact my experience strongly suggests you will. But hey, you decided not to do a project.
The choice is yours, I just want you know that you have options. Choose wisely.
One of the comments to my recent post on estimation is that people want to know how much “a thing” will cost. I totally agree! They also want to know how long “a thing” will take. Once again you will find no disagreement from me there! I understand that people want to ensure that their money is being spent responsibly. I do too!
The issue is not really about what people want as much as it is about whether you can give them an honest, accurate and beneficial answer. I believe the nature of the (knowledge) work you do highly influences your ability to do so.
If you happen to provide a service/solution that is highly repetitive, for example, your organization specializes in the development of tele-medicine websites, then the odds are that after doing this for a while, you’ll have enough data and experience to pull from such that if you are asked for a cost/schedule estimate, you’ll be able to provide one with a high level confidence and probably with a narrow estimate range (this will prevent people from rolling their eyes when you give them estimates). This doesn’t guarantee that it will cost what you say (because stuff happens), it just means that because you have the requisite experience, you can confidently predict (assuming all things remain equal) the outcome. I know this first hand, as my basement certificate of occupancy inspection which should have been done in a few days has been delayed due to the polar vortex and a subsequent inspection backlog.
But what if you don’t happen to provide such a service? What if you happen to be one of the many product development companies out there that spend their days developing brand new stuff? One of the product development companies that is learning what to build based on customer interaction and feedback? How do prove that you will “spend our/their money wisely”? Of course, you can fall back on some reliable estimation techniques out there, give them the possibly outcomes and then subject your team to the burden of that. That is definitely an option. It’s just not my first (or second really). I suggest another way.
Tell them you don’t know (yet). Tell them that that you’d like to take an approach that is focused on learning, risk mitigation and building trust. Tell them you’ll focus the team on the highest priority item(s) for a few iterations and then have an inspection with everyone involved. If this is a contract type situation, they pay for those iterations only. Tell them that if they don’t like the progress, then discussions can be had around what can be done better (or even if the team should continue). Assuming the team continues, over subsequent iterations, the team will learn enough to begin “predict” cost and schedule (if that is truly needed).
I know this sounds unreasonable but progress is dependent on the unreasonable man isn’t it?
After typing this, I realized that the question of “how much” and “how long” could also be an indicator of a bigger dysfunction within an organization, low trust. In my experience, in high trust relationships, organizations trust that the team(s) is making every effort to get things done as soon as is possible. If you are in an environment of low trust, what can be done to change that?
Let’s get this out of the way from the very onset. I don’t believe estimates (and estimation) are evil and should NEVER be used. Now that we have that out of the way, let me share estimation stories about two product teams.
Product Development – Commercial
There was a software development team that did annual releases of their software product. The team size was fixed as management realized that it was hard to have more than a certain number of people working on the same codebase at the same time. Every year they’d spend a couple of weeks estimating items that were to make up the release. They would decompose big items into smaller items that they thought were easier to estimate. They would estimate by assigning hour ranges to the items assuming a sustainable development pace i.e. an individual working 35 or so hours a week. The estimators were experts in both the domain and the technology. These estimates became a commitment of sorts because the plan(s) for the year that went to upper management were based on the estimate they provided. In spite of experience of the team, they would always find themselves scrambling at the end of the year, working at an unsustainable pace and having uncomfortable discussions on what needed to be cut. After a while, the concluded that was just how software development worked.
Product Development – Internal Use
There was an internal IT software development team building a product to support a new service that the company would be providing. Even though business leaders had a “general idea” of what the product needed to do, there was uncertainty as to exact pieces of functionality that needed to be provided and the order that these features would need to be provided in. In other words, the “requirements” were fluid because everyone was still learning about the new service that was being offered. The organization determined how big the team size would be based on a set budget and then set the team off the work. For two years, this team worked without estimates, rather they would identify the work item of highest priority (note that these were the smallest slices of functionality that provided value) and would focus as many people they could (swarm) to complete the item as quickly as was possible. When the organization decided that more needed to be delivered, more individuals were added to the team. Over time, the team learned that in the worst case, in 6 weeks an item of value could be delivered. At a certain point, there was a change in leadership and the new management team wanted the development team to provide single point estimates for a long (pages) feature list to which the team obliged. This new management was uncomfortable with single point estimates returned and that led to a lot of back and forth with the development team until the team decided to give management what they wanted to hear/see. As the saying goes “nine women cannot have a baby in one month”, and the team members told themselves that it was going to take whatever it would take regardless of whatever numbers they had provided.
I realize that these two scenarios do not capture every product development scenario under the sun but that’s not the point. The question in my opinion is this: Is estimation required all the time? Should we just provide an estimate every time we’re asked to do so? Some would say yes, but I beg to differ. The act of estimation should provide value, in many cases, significant value. If it isn’t, it’s most likely a waste of time and cause of much (unnecessary) pain. It’s been suggested that professionals just provide estimates. I disagree. Professionals create/provide value and if an activity is a non-value add then it should be okay to have a discussion about the necessity of that activity.
In the first story, we see that the team, estimated all the time. But did they really need to? Both cost (team size) and schedule (yearly releases) were practically fixed and they knew the items of highest value that had to make the release. Could they have operated without estimating at all? I’d venture to say yes.
Then there is the question of when something will be done. Well, as we see in the second story, if we get into the practice of delivering working software in regular and frequent intervals, we can actually predict more effectively yet differently. The team in story two was able to predict that in the worst case, after six weeks, they would deliver something of business value. Note however that they did not predict when ALL the business value would be delivered as that’s a different game entirely.
There are those who believe that cost and schedule must be determined upfront at all times via estimates. Is this true? Are there not situations where cost and schedule are pre-determined via other methods as identified in the stories? Isn’t it a concern if decision making is solely driven off of estimates? It may surprise you to find out that this is very often the case in software development shops because its the easy (lazy) thing to do. This results in teams often working on the shortest job with the least amount of value.
If we estimate, it’s because we need this information as an additional input into our decision making process. The estimate must be of value and the more valuable the estimate needs to be, the better our estimation approach needs to be. However, this requires that we’ve already estimated the value of the initiative we are undertaking ( when we have no estimate of the value of initiative, why are we estimating how long it will take or how long it will cost? Of what value is the estimate in that particular scenario?) and are trying answer questions such as the following:
- Is the effort required to create something worth it?
- Will the job complete on time for us to realize the value we estimated on it?
- Which job should I start since I have two jobs of the same value?
If you believe that in your situation you need to answer the questions mentioned above, then I’d suggest the following:
- Read a good estimation book like How To Measure Anything before you start
- Use mature estimation techniques like Monte Carlo
- Gather a decent understanding of variation and how it applies in your context
- Realize the output of mature estimation techniques is the probability of a set of different outcomes
- Plan based on the set of outcomes (and not just one outcome)
This applies to those asking (managers) for estimates and to those providing (development teams) estimates. Unfortunately many senior managers (vice-presidents, general managers, C-level execs etc etc) that I’ve come in contact with are not as educated as they should be about estimating in knowledge work. This is extremely unfortunate as a manager with a misunderstanding of estimation, is unfortunately a very dangerous manager.
It has been suggested that any estimation is better than no estimation. Um, I don’t think so. At least, that’s not my experience. Estimation done poorly, improperly or recklessly is harmful as unrealistic commitments are often its product. Stress and de-motivation and a shoddy product follow shortly thereafter as its by-products.
Some of us have gotten very good at gaming estimates and as a result have convinced ourselves that we are good estimators i.e. we are always spot on . But let’s be honest now. How about the extra hours you made the team work by reminding them of the estimate? If your estimate is correct, how come the team did not work at a sustainable pace throughout? Why did you decide that certain features can be deferred to the next release?
If you are the business of doing projects (hard start/stop dates) then I can also understand how the idea of always estimating may be essential to you. But if you are in the business of developing and growing a strategic product over decades, then I believe there are other approaches that can be leveraged. After all, the decision about whether to build the product has already been made.
I respect the fact (and the people) that some (many probably) within my profession believe that we must always estimate but I simply disagree with them. I would hope that they could respect my opinion as well. I will suggest you take a look at your particular situation and determine if estimates are critical to being successful at what you do. Conduct an experiment of working without estimates if its possible. If estimates are crucial to your success, then I charge you to estimate responsibly and if they aren’t, well how about #noestimates?
How do you learn? Have you ever taken the time to think about that? Do you learn in large chunks or small batches? Do you think it matters? As one who cares a lot about how people learn, I believe your approach can influence the effectiveness of your (and others) ability to learn.
In the last eighteen months, I’ve had the opportunity of teaching music of comparable difficulty to a choir. (Disclaimer: I am not a music teacher). I was pretty excited about this opportunity and wanted to make sure that the choir learned the song as quickly as was possible. I figured that the best way of ensuring success was to go over as much of the song as was possible during each practice session i.e. learn in large chunks. Um, bad idea! At each practice session, it was evident that we were not making much progress as we spent significant time reviewing what we (thought) we had learned in previous practice sessions, in fact, we would find ourselves starting from the beginning again. This pattern repeated for many months until we learned the song and performed it. In spite of eventual success, I couldn’t shake the feeling that there had to have been a better (and easier) way that I could have facilitated the learning experience for the choir. Did it need to be this difficult, painful and long?
Fast forward a couple of months later and I was presented with another opportunity to teach another song to the same group. I really wanted the experience to be different but I didn’t know what to do differently. One morning, I was up early, practicing a piano piece that I was going to perform and as I practiced I began to reflect on how I was practicing. It dawned on me that I practiced the piano piece measure by measure i.e. I would repeat a measure until I was comfortable with it and then proceed to the next measure in the piece. I never really attempted to play through a new piece at once. In fact, I only played the entire piece once I was pretty comfortable with all the measures leading up to the very last measure. Could such an approach work with those learning to sing a new piece of music?
I decided to put this approach to the test. When I started teaching them the new song, we started with the first section and just practiced (repeated) it until we had mastered it. Only when we had mastered the first section did we move on to the next section. Our practice sessions started by reviewing sections we had mastered previously and then we would go on to learn a new section.
So how did things turn out? Well, in a month and a half, the choir had learned the song and was ready to perform it. It basically took half the time to learn the second song as it had the first song with the major difference being the way we had decided to learn. By learning in small batches, we had completely changed both the learning experience and the eventual outcome. What had really happened here? Without going too deep into the science of it, at least a couple of things:
- By (seemingly) learning less per session, we did not over the overload the short-term memory in the brain and made it easier for everyone to remember what we had gone over.
- “Repetition deepens the impression” – because we repeated the same (smaller) section multiple times, we kept re-entering it into short-term memory and as we did so, it was facilitated the process of having the information transferred to long-term memory as the section became more important.
My readers with a knowledge of Lean or Agile thinking will know that the concept of small batches is not something new. We talk about it all the time with regards to the flow of work in product development (and knowledge work in general). It seems quite obvious, doesn’t it? Yet, do you actually (explicitly) leverage small batches in learning?
How do you approach learning in your personal life? In your relationships? Big or small batches? For those of us that are coaches, managers or leaders, how do you encourage learning in small batches on your teams? Does a monthly retrospective with the team or a yearly performance review with an employee lend itself to learning in small batches? Does a three day course in [stick your favorite method here] facilitate learning? Do you throw ten new practices at a team and expect them to learn them all at once?
I challenge you (in a friendly way) to ask and answer these questions for yourself. The scary thing is this – if small batches are not involved in learning, it’s very possible that learning is not happening at all. As we step into 2014, maybe its time to revisit how we learn. As a former boss of mine used to say:
Remember, bite small so that you can chew fast.
I recently saw the movie, 12 Years A Slave and to say the least, it was very moving. It evoked a myriad of emotions (anger, sadness, joy, despair, elation etc etc) as I watched it. However, this post is not a movie review, rather it’s reminder (that came from seeing the movie) that slavery is still alive and well (even in the United States where it was abolished in 1865).
You may not be aware of this so I implore you to go to the following resources for more information on slavery today and how you can help:
You may have slaves in your neighborhood, your workplace, your social organizations or even your place of worship. Learn the signs for it and help end it worldwide.
Image from http://www.flickr.com/photos/nationalmuseumofamericanhistory/8362039752/
Cabin biscuit is a popular biscuit (not cookie and yes there is a difference) found in Nigeria. Truth be told, I don’t know if its anywhere else in West Africa (or the world for that matter) but I’d presume that it is.
As a child, it was the highlight of every birthday party I can remember attending. If cabin biscuit wasn’t offered, well, it wasn’t a birthday party. When I went to visit friends, it was the “kola” along with groundnut (peanuts) and mineral (soda/pop) that was offered. My parents would buy a pack every so often and then put the biscuit in a large empty powdered milk tin. (I don’t believe they were alone in this practice).
I have to confess that occasionally (or quite often as the case would be), I would sneak into their room and take a biscuit or two or three because they tasted so good to me. Somehow, I convinced myself that (a) it wasn’t stealing and (b) they didn’t know. Reflecting on this years later, I was probably wrong on both counts.
Here is the thing though, cabin biscuit taste terrible! It really does. It’s a low cost, dry, cardboard box tasting biscuit. The biscuit that led me to covert raids from parent’s bedroom was actually a bottom-of-the-barrel biscuit. But how could I have known this? It was the only biscuit I knew.
I really don’t remember when my moment of enlightenment came. It was probably some point in secondary school (post elementary) that I realized how terrible cabin biscuit actually was. But I do know that it came after being exposed to better biscuits. Once I discovered that there were much tastier (albeit more expensive) options, I gave up cabin biscuit. It was no longer my biscuit of choice. It was relegated to the bench. In fact, I became insulted whenever it was offered to me. No more raids, no more anticipation, no more anything. I had come to know and desire different.
I’ve seen my professional career traverse a similar arc. For many years, all I cared about was being the best and being in control. I developed in the classic hierarchical organizations where power was associated with your title. Many of the discussions I had with co-workers revolved were centered on how to climb the corporate ladder. The better one performed, the quicker one’s title changed and when one’s title changed, the more muscle one could flex. Generally, the more muscle-flexing capability one had, the more compensation one received. I had figured out corporate America and what my work experience needed to be like. I had discovered the cabin biscuit way – the low quality approach to knowledge work but I didn’t know it. I thought I was indulging in a high quality biscuit.
Three years ago, as a result of a cabin biscuit career change, I found myself in a difficult (severely understated) environment. The entire IT team had turned over and hostility/tension between the Operations and IT department was worse than unhealthy, it was borderline deadly. I thought that acquiring more power would put me in a position to change things. I quickly realized that this wasn’t the case and deep frustration set in. It was at this point, that I stumbled on the work of W Edwards Deming and the System of Profound Knowledge.
This led to discovery and reading the works of others such as Ackoff and Drucker. I suddenly realized that the cabin biscuit way was tasteless, cheap and no longer satisfying. There were actually more rewarding ways of approaching work and society. I discovered alternatives that have led me (in no particular order and not limited) to:
- Desire to experience true fellowship with co-workers.
- Desire to establish meaningful connections
- Focus on trying to understand the needs of others
- Empathize with others as they face challenges on the job
- Choose collaboration over control
- Take a deep interest in psychology
- Place people at the certain of knowledge work
To be fair, I had always experienced the above in bits and pieces throughout my career. The difference now is that my career is all about creating and living these experiences.
We don’t have to settle for the cabin biscuit way of interacting with one another. There are better and more fulfilling ways. Maybe the cabin biscuit way is all you know? I then challenge you to try something else. I have a feeling you’ll be glad you did.