Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
I've¬†started reading Vasco's book #NoEstimates and will write a detailed¬†deconstruction. I got the Kindle version, so I have a $10 investment at risk. Let's start with some graphs that have been around and their misinformation that forms the basis of the book.
The Chaos Report graph,is the¬†1st one. This graph is from old 2004 numbers. That's 12 year old numbers. Many times the books uses 12, 16, even 25 year old reports as the basis of the suggestion that Not Estimating fixes the problems in the reports. The Chaos reports have been thoroughly debunked as¬†self selected samples using¬†uncalibrated¬†surveys for the units of measure for¬†project¬†failure.¬†Here's a few comments on the Standish reporting process. But first remember, Standish does not say what the units of measure are for Success, Challenged, or Failure. Without the units of measure, the actual statistics of the projects and the statistical ranges of those projects for each of the three¬†categories, the units as essentially bogus. Good fodder for selling consulting services or for use by those with an idea to sell, but worthless for decision making about the root cause of Failure, Challenged, or even Success. Any undergraduate¬†design of¬†experiments class would have all that information in the public.¬†
So the 1st thing to read when you encounter data like this is Project Success:¬†A Multidimensional Strategic¬†Concept,¬†Aaron J. Shenhar, Dov Dvir, Ofer Levy and Alan C. Maltz. Only then start to assess the numbers. Most likely, like the numbers in the book, they're not credible to support the hypothesis. Which by the way there is no hypothesis for¬†you can make¬†decisions¬†in the presence of uncertanty without estimating
So let's look further at the difficulties with Standish and why NOT to use it as the basis of a conjecture
A simple google search would have found all this research and many many more. I get the sense V didn't do his homework. The bibliography has very few references to actually estimating, no actual estimating books, papers, or research sites. Just personal anecdotes from a ¬†set of experiences as a developer.
The Standish Report failure mode is described in¬†Darrell Huff's¬†How to Lie With Statistics -¬†self select the samples from the survey. Standish does not provide any population statistics for their survey.
None of these questions are answered in Standish reports. No Estimate picks these serious statistical sampling error up and uses the, as the basis of the pure-conjecture that Not Estimating is going to fix the problems. This would garner a high school D is the Stats class.
Next comes a chart that makes¬†a similar error. This reference is from Steve McConnell's book, but is¬†actually from another source. The No Estimates book does a poor job of keeping the references straight. It is common to¬†misattribute a report, a graph, even a phrase. The book needs a professional editor.
The graph below is used to show that estimates are usually wrong. But there is a critical misunderstanding about the data.
I'm in the early parts of the book and already have a half dozen pages of notes for either fallacies, incorrect principles, 30 year old references, and other serious mistakes on¬†understanding on how decisions are made in the presence of uncertainty. My short assessment is¬†
It's a concept built on sand.Related articles Myth's Abound All Project Numbers are Random Numbers - Act Accordingly The Failure of Open Loop Thinking How to "Lie" with Statistics Statistical Significance How to Estimate Software Development Capabilities Based Planning IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes
If you specify deliverables in your big picture and small picture roadmaps, you have already done a gross form of ranking. You have already made the big decisions: which feature/parts of features do you want when? You made those decisions based on value to someone.
I see many POs try to use estimation as their only input into ranking¬†stories. How long will something take to complete? If you have a team who can estimate well, that might be helpful. It’s also helpful to see some quick wins¬†if you can. See my most recent series of posts on Estimation for more discussion on ranking by estimation.
Estimation talks about cost. What about value? In agile, we want to work (and deliver) the most valuable work first.
Once you start to think about value, you might even think about value to all your different somebodies. (Jerry Weinberg said, “Quality is value to someone.”) ¬†Now, you can start considering defects, technical debt, and features.
The PO must rank all three possibilities for a team: features, defects, and technical debt. If you are a PO who has feature-itis, you don’t serve the team, the customer, or the product. Difficult as it is, you have to think about all three to be an effective PO.
The features move the product forward on its roadmap. The defects prevent customers from being happy and prevent movement forward on the roadmap. Technical debt prevents easy releasing and might affect the ease of the team to deliver. Your customers might not see technical debt. They will feel the effects of technical debt in the form of longer release times.
Long ago, I suggested that a specific client consider¬†three backlogs to store the work and then use pair-wise comparison with each item at the top of each queue. (They stored their product backlog, defects, and technical debt in an electronic tool. It was difficult to see all of the possible work.)¬†That way, they could see the work they needed to do (and not forget), and they could look at the value of doing each chunk of work. I’m not suggesting keeping three backlogs is a good idea in all cases.¬†They needed to see—to make visible—all the possible work. Then, they could assess the value of each chunk of work.
You have many ways to see value. You might look at what causes delays in your organization:
You might see value in features for immediate revenue. I have worked in organizations where, if we released some specific feature, we could gain revenue right away. You might look at waste (one way to consider defects and technical debt).
Especially in programs, I see the need for the PO to say, “I need these three stories from this feature set and two stories from that other feature set.” The more the PO can decompose feature sets into small stories, the more flexibility they have for ranking each story on its own.
Here are questions to ask:
You might need to rearrange those questions for your context. The more your PO works by value, the more progress the team will make.
The next post will be about when the PO realizes he/she needs to change stories.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
Last week in London, I wanted to shoot a video, but it appeared that I had left my camera’s memory cards at home. On my previous trip, it had been my Android tablet that I had forgotten to bring with me. The trip before that, it was my stack of local currency, my power adapters, my sunglasses, or whatever, which I hadn’t properly packed.
Sure, I have a travel checklist. But clearly, it had turned into a checklost. With at least 50 confirmed upcoming events around the world, it was time for me to redesign it.
Four Preferred Places
My original checklist was one large unorganized list of reminders. This regularly led to problems because, by scanning the list too quickly, I easily overlooked an item that was buried among all the other things that I only knew too well. So I divided the checklist into four parts:
Each travel item on my improved checklist now has a preferred place. This not only helps to keep the individual lists smaller, and easier to check more carefully, but it also helps me keep things in the right bag. I don’t want to have that situation again where I thought I had my universal adapters or chargers packed in the other bag (but found out later that I hadn’t).
(And preferred means that items can change places depending on context. For example, my keys will have moved to my shoulder bag before I arrive at the airport, while my passport may temporarily move to my pocket while suffering the security and customs rituals.)
Standard versus Extra
Another thing I noticed messing up my packing efforts was that some standard items are by default in my bags (such as passports and adapters), other extra things are by default out of my bags (such as clothes and toiletries), and some items had a Schr√∂dinger-kind of existence, not clearly being in or out, until I opened my bags to have a look (such as device chargers and headphones).
After the reorganization, packing my bags with my improved checklist now consists of two distinct activities:
Hopefully, this will save me some stress and headaches in the future.
For example, I once had to interrupt my trip to the airport because my passport was not in my bag: it was still under the scanner next to my computer. I always know that my passports are in my shoulder bag, except for the one or two times when, apparently, I was wrong. And thus, I made it a separate activity to check that I am not deceiving myself, thinking that the standard items are where they should be before adding all extra items. And a Schr√∂dinger-kind of existence is not part of the improved design.
And then, of course, there are the optional items that mainly depend on the weather forecasts. I remember once nearly freezing to death in Helsinki because I had no warm coat or gloves. I was once drying my clothes in my hotel room in London because, stupidly, I had brought no umbrella. And more than once, I have been sweating in the sun because I was silly enough to bring only dark blue jeans and long-sleeve shirts.
Short versus Long trips
Finally, things can always change a bit depending on context.
On short trips (one or two nights), I don’t need to take the larger bag with me. But this means I must jam any books, running gear, and clean clothes into my hand luggage, which is not always possible, or else just leave some of it at home. And on long trips (ten or more nights), the large bag magically changes into an extra large suitcase, and this also changes what I can bring with me (usually a lot more clothes).
Well, there you have it: the philosophy behind my new-and-improved travel checklist. I include the full list below (as it is now).
Is there anything missing that you have on your travel checklist, and that may be useful for me as well?
Shoulder bag – standard items
Credit cards and bank cards
Travel cards and loyalty cards
Pens and markers
Shoulder bag – extra items
Tablet + charger
Handbag – standard items
Spare underwear, socks, and shirt
Spare medicine, contact lenses
Handbag – extra items
Notebook + charger
Gloves, scarf, ear muffs [IF forecast = cold]
Umbrella [IF forecast = wet]
Travel clothes [IF distance = long]
Large bag – standard items
Large bag – extra items
Running shoes and clothes
Book / giveaway
Fleece jacket [IF forecast = cold]
Warm socks and sweater [IF forecast = cold]
Raincoat [IF forecast = wet]
Short pants [IF forecast = hot]
photo (c) 2013 Chris Lott, Creative Commons 2.0
My new book Managing for Happiness is available from June 2016. PRE-ORDER NOW!
When I work with clients, they often have a “problem” with product ownership. The product owners want tons of features, don’t want to address technical debt, and can’t quite believe how long features will take. ¬†Oh, and the POs want to change things as soon as they see them.
I don’t see this as problems.To me, this is all about learning. The team learns about a feature as they develop it. The PO learns about the feature once the PO sees it. The team and the PO can learn about the implications of this feature as they proceed. To me, this is a significant value of what agile brings to the organization. (I’ll talk about technical debt a little later.)
One of the problems I see is that the PO sees the big picture. Often, the Very Big Picture. The roadmap here is a 6-quarter roadmap. I see roadmaps this big more often in programs, but if you have frequent customer releases, you might have it for a project, also.
I like knowing where the product is headed. I like knowing when we think we might want releases. (Unless you can do continuous delivery. Most of my clients are not there. They might not ever get there, either. Different post.)
Here’s the problem with the big picture. No team can deliver according to the big picture. It’s too big. Teams need the roadmap (which I liken to a wish list) and they need a ranked backlog of small stories they can work on now.
In Agile and Lean Program Management, I have this picture of what an example roadmap might look like.
This particular roadmap works in iteration-based agile. It works in flow-based agile, too. I don’t care what a team uses to deliver value. I care that a team delivers value often. This image uses the idea that a team will release internally at least once a month. I like more often¬†if you can manage it.
Releasing often (internally or externally) is a function of small stories and the ability to move finished work through your release system. For now, let’s imagine you have a frictionless release system. (Let me know if you want a blog post about how to create a frictionless release system. I keep thinking people know what they need to do, but maybe it’s as clear as mud to ¬†you.)
The smaller the story, the easier it is for the team to deliver. Smaller stories also make it easier for the PO to adapt. Small stories allow discovery along with delivery (yes, that’s a link to Ellen Gottesdiener’s book). And, many POs have trouble writing small stories.
That’s because the PO is thinking in terms of feature sets, not features. I gave an example for secure login in How to Use Continuous Planning. It’s not wrong to think in feature sets. Feature sets help us create the big picture roadmap. And, the feature set is insufficient for the frequent planning and delivery we want in agile.
I see these problems in creating feature sets:
I’ll address these issues in the next posts.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories.¬†See the wikipedia page about user stories. Notice that they are a promise for a conversation.
I talked about feature sets in the first post, so let me explain that here. A feature set is several related stories. (You might think of a feature set as a theme or an epic.) Since I like stories the team can complete in one day or less, I like those stories to be small, say one day or less. I have found that the smaller the story, the more feedback the team gets earlier from the product owner. The more often the PO sees the feature set evolving, the better the PO can refine the future stories. The more often the feedback, the easier it is for everyone to change:
I realize that if you commit to an entire feature set or a good chunk for an iteration, you might not want to change what you do in this iteration. If you have an evolving feature set, where the PO needs to see some part before the rest, I recommend you use flow-based agile (kanban). A kanban with WIP limits will allow you to change more often. (Let me know if that part was unclear.)
Now, not everyone shares my love of one-day stories. I have a client whose team regularly takes stories of size 20 or something like that. The key is that the entire team swarms on the story and they finish the story in two days, maybe three. When I asked him for more information, he explained this it in this way.
“Yes, we have feature sets. And, our PO just can’t see partial finishing. Well, he can see it, but he can’t use it. Since he can’t use it, he doesn’t want to see anything until it’s all done.”
I asked him if he ever had problems where they had to redo the entire feature. He smiled and said,
“Yes. Just last week we had this problem. Since I’m the coach, I explained to the PO that the team had effectively lost those three days when they did the “entire” feature instead of just a couple of stories. The PO looked at me and said, “Well, I didn’t lose that time. I got to learn along with the team. My learning was about flow and what I really wanted. It wasn’t a waste of time for me.”
“I learned then about the different rates of learning. The team and the PO might learn differently. Wow, that was a big thing for me. I decided to ask the PO if he wanted me to help him learn faster. He said yes, and we’ve been doing that. I’m not sure I’ll ever get him to define more feature sets or smaller stories, but that’s not my goal. My goal is to help him learn faster.”
Remember that PO is learning along with the developers and testers. This is why having conversations about stories works. As the PO explains the story, the team learns. In my experience, the PO also learns. It’s also why paper prototypes work well. Instead of someone (PO or BA or anyone) developing the flow, when the team develops the flow in paper with the PO/BA, everyone learns together.
Small stories and conversations help the entire team learn together.
Small features are about learning faster. If you, too, have the problem where the team is learning at a different rate than the PO, ask yourself these questions:
I’ve written about how to make small stories in these posts:
The smaller the story, the more likely everyone will learn from the team finishing it.
I’ll address ranking in the next post.
If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.
I recently emailed everyone who subscribes to my weekly tips a list of suggestions for ways to motivate team members to arrive on time to the daily scrum. For example, many teams have a rule that if you arrive late, you put a dollar in a jar as punishment for being late. Ideally the collected money is donated to a charity at the end of a project or after it reaches a certain amount.
I included a number of other techniques I’ve seen Scrum Masters use. Many were similar to paying a dollar in that they were punishments for being late. Wow, did I get called out for that. The general argument was that a Scrum Master should use an incentive for being on time rather than a punishment for being late.
That’s a really good point. But I have to say that in the vast majority of teams I’ve seen, they use a punishment rather than an incentive. Many of the punishments involve at least the potential for embarrassing the offender--sing a song, do a pushup, tell a joke, etc.
I’ve thought about why this is. It may be because it’s more natural (for many of us?) to harass the one rule-breaker than reward everyone else. Or maybe it’s because embarrassing the late arriver by making that person sing (for example) is more fun for everyone else.Incentives Rather than Punishments
I do think, though, that it’s a great suggestion that we look for incentives rather than punishments. Besides, punishment may be too strong of a term. I was told by a couple of people that deterrent might be the better term.
In fact, Rob Dull pointed out an underlying benefit to using a deterrent, saying, “It's sooo healthy for people to be able to be silly/awkward in front of their teammates.”
Others considered the entire idea “stupid,” as one email I received succinctly put it. While others pointed out that the only real fix is to tap into an intrinsic motivation to get latecomers to arrive on time.
Isaias Fritsch took that type of approach by preparing a 30-minute presentation for the team on the importance of the daily scrum. He said that after that presentation, the team decided to come up with some changes to their daily scrum approach. The result of this has been that “the daily scrum is now way more interesting to everyone because relevant information is shared and everyone understands its importance/why we are doing it.”
Ted Morris Dawson had an interesting take on the punishment vs. incentive idea. One technique he has used was if all team members are on time for all daily scrums, then it’s the Scrum Master who does the embarrassing thing like sing, tell a joke or so on. Yikes!
So with the idea that we can help teams overcome the problem through either deterrents or incentives, I’ve split the suggestions I was emailed into lists of each.Deterrents
So, there are many ways you can go about this. And, as I said in my emailed weekly tip, I love getting the chance to learn from all of you. I definitely learned some good techniques from this. Also, I’ve learned that I really should think more about incentives rather than deterrents.
Whatever you choose to do, you really need to make sure the entire team buys into it. The last thing you want is for someone to go to human resources complaining that you’re making him do a pushup for every minute he arrives late to a meeting.
But, for a team on which being late is a problem, these approaches can help address the problem. A common thread in many replies I received was that many of these incentives and deterrents work especially well because the entire team starts holding each other accountable. This is a huge benefit over just a Scrum Master holding people accountable.What Do You Think?
What’s missing? What other techniques have you tried to encourage people to be on time for daily scrums? Please share your thoughts in the comments below.
When riding a¬†single track like this¬†one behind our neighborhood, I came to an understand of the tradeoffs between stability and control. In our conference sessions, we speak about how the Wright Brothers learned this concept as well.Here's another trail being ridden by our son at Nationals in 2013. who's¬†massively better than I will ever be. But same tradeoff between stability and control is needed¬†to be ranked 33rd Cross Country and 23rd Short Track at DII in¬†the nation, with team taking¬†2nd overall.
In both cases, nationally ranked and rank amaetur, control of bike is the key. Stability is a relative term, depending on speed, terrain, skill, risk taking tolerance, ¬†experience, technical equipment, and other intangible factors.
We speak at conference where program planning and controls is the topic. Starting 2 years ago, our foundation for speaking about managing in the presence of ¬†uncertanty is the Wright Brothers.
Most earlier experimenters in powered flight focused only on one or two¬†of the primary problems - (a) A set of lifting surfaces, or wings, (b) A method of balancing and controlling the aircraft, and (c) A means of propulsion -¬†¬†and did not consider the final design from the outset. The Wrights recognized that each of these areas had to be successfully addressed to build a working airplane. They believed that the aerodynamic and propulsion problems would be comparatively easier to solve, so they first concentrated on how to maintain balance and control.
Many believed that air currents were too swift and unpredictable for human reflexes. Therefore, an aircraft had to be inherently stable for the pilot to be able to maintain control.¬†Because of the Wrights‚Äô extensive experience with the bicycle‚ÄĒa highly unstable but controllable machine (just like the mountain bike)‚ÄĒthey saw no reason why an airplane could not be unstable yet controllable as well.
The notion of¬†Control is missed used in software development projects. Misused and misunderstood. Control inside the upper and lower control bounds is a critical success factor. What are those upper and lower control bounds? Good question. They have to be estimated in the start. They become cleared as the project progresses. They have to be adjusted as new information emerges.
In projects, the question for Stability¬†is a false quest. All project work is uncertain. Stability is short lived. New inputs arrive every day. Just like new inputs arrive while riding down the flat trail for cruising around the open space in the neighborhood or more so¬†on the bumpy high speed trail of collegiate racing.
Even if the trail is defined in from of you, the small disruptions and many times big distributions input your control of the bike. The key is¬†Control over Stability. Staying in control will get you across the finish line, down the trail, and home again to ride another day.
Skills of Maintaining Control on the Mountain Bike and the Project
Starting from our house there is a nice loop Left Hand Trail, that is easy, has a few climbs, and a few descents, uncrowded, and provides a nice view of the small hills before the real mountains start . Combine that with the Eagle Trail, Sage Trail, and North Rim Trail and it's a nice 7 mile loop
There's lots of misinformation going around again in the #NoEstimates community
Here's the starting point¬†to clarify and debunk those concepts
Here's some more details, once it's been confirmed you have domain experience
In the end it's simple. Anyone speaking about the difficulties or the waste of estimating is likely on the spend side of the software development equation. Those on the¬†pay side know (or should know) they needed estimates. They can get the estimates from those most qualified to provide them - the developes. Or they can just make them up. Probably better to have a bottom up estimate.Related articles Humpty Dumpty and #NoEstimates Want To Learn How To Estimate? Let's Stop Guessing and Start Estimating
¬†When we hear about all the suggested ways to improve the effectiveness of our development effort, if we're to going work on improvements, let's go where the REAL money is.¬†
Here's the IT budget for the Federal Government. This is larger than¬†all the IT systems found everywhere else in the world, plus all their custom built IT stuff. This is not the embedded systems. These are business systems.
So if we're going to make improvements in the spend of IT for better value, let's start here.
¬†Related articles Estimating and Making Decisions in Presence of Uncertainty Intentional Disregard for Good Engineering Practices? What's in a Domain?
The latest thread in agile is ...
the continued paradigm of deadline-driven development is killing the benefits that Agile Software Development can bring.
It is suggested¬†by Neil Killick¬†that ...
...¬†using genuine time constraints as a factor in the prioritisation of work rather than as a focus for its execution, the odds of meeting those "deadlines" are actually improved.
Not sure what a¬†genuine time constraint is versus any time constraint. But the conjecture that¬†Executives of software product and service companies always want stuff delivered faster, cheaper and better. Agile principles and methods are believed to be a way to achieve this ignores several fundamental principles of all work and especially software development work.
¬†All project work has uncertanty. Reducible uncertanty and irreducible uncertanty.
Agile does not remove this uncertanty. Agile is NOT a risk management process.¬†Genuine¬†constraints don't remove this uncertanty., I've spoken many times in the past about how to¬†Manage in the Presence of¬†Uncertainty.
These¬†principles are¬†always in place. More so on Agile projects, where emergent requirements are encouraged, which in turn drive uncertanty further to the right in the Probability Distribution Function of the possible range of durations, costs, and technical performance shortfalls.
When those uncertainties are not considered and handled, any project is going to have an increased chance of being late, over budget, and have technical issues.¬†
Setting¬†genuine¬†constraints may make this issue visible, but does not remove the¬†risk to the project's probability of success. Only active risk management and the necessary margin can increase this probability.
The only protection for irreducible uncertanty is¬†Margin and the only protection¬†for reducible uncertainty is¬†active risk management. Both of these activities require careful planning and execution of the¬†plan, along with the estimate of the probability of occurrence of a reducible event and the statistical distribution of the naturally occurring variances¬†and the probabilistic¬†impact on the success of the project.
This is the Reason for Planning
It's been suggested I work in a unique domain, where deadlines and need dates are themselves unique. This is False.
No credible business, no matter the size, Doesn't have a need date for the Value produced by the software project. If there was no¬†need date, the developers would show up whenever they wanted after spending whatever they wanted, with whatever they thought the customer needed.
Ignoring the simple¬†time cost of money and the time phased Return of Investment of (Value-Cost)/Cost, any business that intends to stay in business is spending money for software - either developed or purchased - to provide some value to the business. Not having a¬†need date for the production of that Value means the business is ignoring the core principle of retained¬†earnings. Even non-profits and not-for-profit business (and I've worked there as well) have a¬†time value of money¬†economic model.
So if you're going to produce¬†value for your customer, that value is most always time sensitive other wise it's de minimis value. If it's time sensitive, there is a deadline. If there's a deadline, reducible and irreducible uncertanty and the risk it produces must be handled.¬†
Risk Management is How Adults Manage Projects -¬†Tim Lister
‚Ä† The naive notion that scrum teams are self contained and need no external support is only the case when there is little at risk for the resulting code. Cyber security, Database integrity, performance validation, operational integrity are external surveillance roles on any Software Intensive System of Systems. This is called Governance and guided by documents like ISO 12207, ITIL V3.1, COBIT, DoDAF, ToGAF.Related articles Risk Management is How Adults Manage Projects Essential Reading List for Managing Other People's Money Agile Software Development in the DOD The Art of Systems Architecting Seven Principles of Agile Software Development in the US DOD Deadlines Always Matter
Here's some thoughts on the economics of software development using other people's money, after 3¬†weeks of working a proposal for a major software intensive system of systems using Agile.
So to come full circle¬†
Why Do We Need Estimates?
It can't be any clearer than this - if you¬†¬†don't know what something costs or is going to cost in the future, you¬†can't make a business decision about it's value
When you read¬†estimates are a waste, estimates are non-transferable, estimates are wrong, estimates are temporary think again. Go ask those paying if they need estimates to make decisions for the business. If they don't, then continue to spend your customers money. If they do, they may consider looking for someone who knows the difference between willful ignorance of how to estimate software development and someone who can provide that information needed to stay in business. On our proposal team, this would get you a¬†2nd¬†place prize in the¬†estimating¬†capabilities¬†contest - which is a¬†one way¬†trip home with weekends off.Related articles Capabilities Based Planning First Then Requirements Incremental Delivery of Features May Not Be Desirable Quantifying the Value of Information Essential Reading List for Managing Other People's Money Decision Making Without Estimates? Economics of Software Development Risk Management is How Adults Manage Projects Process is King Deadlines Always Matter
If you’ve been following the conversation, I discussed in Part 1 how I like agile roadmaps and gross estimation and/or targets for projects and programs. In Part 2, I discussed when estimates might not be useful. In Part 3, I discussed how estimates can be useful. In Part 4, I discussed #noestimates. ¬†Let me summarize my thinking and what I do here.
This series started because Marcus Blankenship and I wrote two articles: Stay Agile With Discovery, which is how to help your client see benefit and value early from a small project first, before you have to estimate the whole darn thing; and Use Demos to Build Trust, how to help your client see how they might benefit from agile in their projects, even if they want an upfront estimate of “all” the work.
Let me clarify my position: I am talking about agile projects. I am not talking about waterfall, iterative, or even incremental approaches. I have used all those approaches, and my position in these posts are about agile projects and programs.
In addition, I have a ton of experience in commercial, for-profit organizations. I have that experience in IT, Engineering, R&D. I have very little experience in non-profit or government work.¬†Yes, I have some, but those clients are not the bulk of my consulting business. As with everything I write (or anyone else does), you need to take your context into account. I¬†see wide project and program variation in each client, never mind among clients.
That said,¬†in agile, we want to work according to the agile principles (look past the manifesto at the principles). How can we welcome change? How can we show value? How can we work with our customer?
Many people compare software to construction. I don’t buy it. Here’s a little story.
In my neighborhood, the gas utility is replacing gas mains.The project is supposed to about three months or so. We received a letter in May, saying which streets they expected to work on and when. The reality is quite different.
They work on one street, and have to go around the corner to another street? Why? Because the mains and lines (water, gas, electric) are not where the drawings said they would be. Instead of a nice grid, they go off at 45-degree angles, cross the street, come back, etc. Nothing is as the plans suggested it should be. During the day, I have no idea what streets will be open for me to drive on. The nice folks put everything back to some semblance of normal each night. They patch the roads they work on during each day.
And yet, they are on budget. Why? Because they accounted for the unknowns in the estimate. They padded the estimate enough so that the contractor would make money. They accounted for almost everything in their estimate. How could they do this? The company doing the work has seen these circumstances before. They knew the 50-year-old plans were wrong. They didn’t know how, but they’ve seen it all before, so they can manage their risks.
The learning potential in their work is small. They are not discovering new risks every day. Yes, they are working around¬†local technical debt. They knew what to expect and they are managing their risks.
Here’s another story of a software project. This is also a three-to-four month project (order of magnitude estimate). The product hasn’t been touched in several years, much to the software team’s dismay. They have wanted to attack this project for a couple of years and they finally got the go-ahead.
Much has changed since they last touched this product. The build system, the automated testing system, the compiler—all of those tools have changed. The people doing the work have changed. The other products that interact with this product have changed.
The team is now working in an agile way. They deliver demonstrable product almost every day. They show the working product every week to senior management.
They are learning much more than they thought they would. When they created the estimate, they had assumptions about underlying services from other products. Well, some of those assumptions were not quite valid. They asked what was driving the project? They were told the date to release. Well, that changed to feature set. (See Estimating the Unknown, Part 1 for why that is a problem.)
They feel as if the project is a moving target. In some ways, it is. The changes arose partly because of what the team was able to demonstrate. The PO decided that because they could do those features over there and release those features earlier, they could reduce their Cost of Delay. Because they show value early and often, they are managing the moving target changes in an agile way. I think they will be able to settle down and work towards a target date once they get a few more features done and released.
Why is this team in such project turmoil? Here are some reasons:
The team is taking one problem at a time, working that problem to resolution and going on to the next. They work in very small chunks. Will they make their estimate of 3-4 months? They are almost 3 months in. I don’t think so, and that’s okay. It’s okay because they are doing more work than they or their management envisioned when the project started. In this case, the feature set grew. It partly grew because the team discovered more work. It partly grew because the PO realized there was more value in other features not included in the original estimate.
In agile, the PO can take advantage of learning about features of more value. This PO works with the team every day. (The team works in kanban, demos in iterations.)
The more often we deliver value, the more often we can reflect on what the next chunk of value should be. You don’t have to work in kanban. This team likes to do so.
The kinds of learning this team gains for the software project is different that what the gas main people are learning in my neighborhood. Yes, the tools have changed since the gas mains were first installed. The scope of those changes are much less than even the tools changes for the software project.
The gas main project does “finish” something small every day, in the sense that the roads are safe for us to drive on when they go home at night. However, the patches are just that—patches for the road, not real paving. The software team finishes demonstrable value every day. If they had to stop the project at any time, they could. The software team is finishing. (To be fair to the gas people, it probably doesn’t make monetary sense to pave a little every day to done. And, we can get to done, totally done, in software.)
The software team didn’t pad the estimate. They said, “It’s possible to be done in 3 months. It’s more likely to be done in 4 months. At the outside, we think it will take 5 months.” And, here’s what’s interesting. If they had completed just what was in their original estimate, they might well be done by now. And, because it’s software, and because they deliver something almost every day, everyone—the PO, management, the team—see where there is more value and less value.
The software team’s roadmap has changed. The product vision hasn’t changed. Their release criteria have changed a little, but not a lot. They have changed what features they finish and the order in which they finish them. That’s because people see the product every day.
Because the software team, the PO and the management are learning every day, they can make the software product more valuable every day. The gas main people don’t make the project more valuable every day.
Is estimation right for you? Some estimation is almost always a good decision. If nothing else, the act of saying, “What will it take us to do this thing?” helps you see the risks and if/how you want to decompose that thing into smaller chunks.
Should you use Cost of Delay in making decisions about what feature to do first and what project to do first? I like it because it’s a measure of value, not cost. When I started to think about value, I made different decisions. Did I still want a gross estimate? Sure. I managed projects and ran departments where we delivered by feature. I had a ton of flexibility about what to do next.
Are #noestimates right for you? It depends on what your organization needs. I don’t need estimates in my daily work. If you work small and deliver value every day and have transparency for what you’re doing, maybe you don’t need them either.
Estimates are difficult. I find estimation useful, the estimates not so much. I find that looking at the cost and risks are one way to look at a project. Looking at value is another way.
I like asking if what my management wants is commitment or resilience. See When You Need to Commit. Many organizations want to use agile for resilience, and then they ask for long commitments. It’s worthwhile asking questions to see what your organization wants.
Here are my books that deal with managing projects, estimation, Cost of Delay and program management:
For me, estimates are not inherently good or bad. They are more or less useful. For agile projects, I don’t see the point of doing a lot of estimation. Why? Because we can change the backlog and finish different work. Do I like doing some estimation to understand the risks? Yes.
I don’t use cost as a way to evaluate projects in the project portfolio. I¬†prefer to look at some form of value rather than only use an estimate. For agile projects, this works, because we can see demonstrable product soon. We can change the project portfolio once we have seen delivered value.
Remember. my context is not yours. These ideas have worked for me on at least three projects. They might not work for you. On the other hand, maybe there is something you can use from here in ¬†your next agile project or program.
Please do ask more questions in the comments. I might not do a post in a while. I have other writing to finish and these posts are way too long!
“We made a mistake. They are going to hate me tomorrow,” he said.
Imagine a room with 28 EU diplomats, twice that many specialists, dozens of translators, and one chairman who needs to tell everyone that his team has made a planning mistake and that everyone will suffer for it.
Needless to say, the chairman wasn’t looking forward to the next day. “I need them in a cooperative mode,” he said. “It is hard enough already to get agreements out of 28 countries. They will be very annoyed with us screwing up the planning. We’re not going to make much progress tomorrow.”
The Failure Hat
This problem made me think of people management in agile environments. Agile teams often have creative solutions to social problems, and one of those solutions immediately came to mind.
I told the chairman that, on some agile teams, if anyone has made a mistake for which the entire team has to suffer, that person wears the failure hat for a whole day. If someone accidentally destabilizes the product or “breaks the build” he or she is visually identified as the scapegoat, in a playful manner, so that everyone knows who did it. With a failure hat, people change from pointing fingers to poking fun.
Resentment and Vengeance
It is a human tendency to be resentful when other people make mistakes for which we have to suffer. In fact, vengeance is one of the sixteen basic desires of human beings, says behavioral psychologist Professor Steven Reiss. Even if there’s no immediate urge to hit back and retaliate for any (accidental) wrongdoings, we certainly feel it’s in our right to be pissed off and remain uncooperative, until the feelings of irritation have worn off. And this can take a while.
That’s why it’s rarely enough just to say, “I’m sorry”, however sincerely these words are spoken. The apology takes just one second of communication. But it can take hours for an annoyed person to say sincerely, “OK, I forgive you.” And on an agile team, or with a group of 28 diplomats, these can be costly uncooperative hours.
The Failure Shirt
I advised the chairman, “After you told them that you’re sorry, wear a silly hat, or a stupid shirt, for the rest of the day. Explain to them the meaning of the failure hat or failure shirt: You openly admit the mistake, and you allow everyone to point at you and laugh at you for a whole day, on the condition that you can immediately switch back into a collaborative mode.”
The next day, the chairman, who is well-known for his expensive suits and crisply tailored shirts, did exactly what I said. For the sake of the meeting, he sacrificed his dignity, admitted the mistake of his team, took off his jacket and stark white shirt in front of 80+ diplomats, specialists, and translators, and revealed the most ridiculous colored T-shirt that anyone had ever worn during an EU negotiation.
It was a huge success.
He received great applause, and laughs and cheers from everyone in the room. During the coffee breaks, half of the attendees took pictures and selfies with him and some congratulated him on his smart management move.
Most importantly, the rest of the day, the group enjoyed a cooperative and maybe even somewhat festive mood. People’s feelings of resentment and vengeance were satisfied: They could all see the chairman sitting there, suffering, in his silly shirt. Who wouldn’t smile at that? Let’s take another picture! The rest of the meeting was conducted in the failure shirt.
Afterward, the chairman said to me, “We made significant progress today, and I am now ridiculously popular. You’re my secret weapon!”
I felt extremely pleased that better management practices can work in any context. And also happy that I had an opportunity to assist in the career of my husband.
p.s. Make sure that wearing the shirt or hat feels somewhat embarrassing to the guilty person. I wouldn’t feel guilty in a colorful T-shirt. In fact, it was my shirt.
My new book Managing for Happiness is available from June 2016. PRE-ORDER NOW!
I have two online workshops starting in late August:
If you have been reading the estimations posts and are wondering, “How do I help my project deliver something every day or more often,” you should register for the workshop. We’ll discuss what your role is, how to plan for the future and the present, how to decide what features to do when, how to know when a feature is done, and tips and traps. See¬†Practical Product Owner Workshop: Deliver What Your Customers Need¬†for more details.
If you like the way I write (regardless of whether you agree with me), and you need to write more for your job or to help your business, take my¬†Non-Fiction Writing Workshop: Write Non-Fiction to Enhance Your Business and Reputation. That workshop is about building a writing habit, learning the separate parts of pre-writing, writing, editing, and publishing. We’ll address your specific writing challenges, concerns, and fears. I’m the only one who will read your work, so no worries about other people seeing your writing.
Super-early-bird registration for both workshops ends June 17, 2016. I hope you decide to join us.
When we think about the discussion about estimates and #noestimates, I have one big question:
Where do you want to spend your time?
In projects, we need to decide where to spend our time. In agile and lean projects, we limit the work in progress. We prefer to spend our time delivering, not estimating. That’s because we want to be able to change what we do, as often as we can. That is not appropriate for all projects. (See When is Agile Wrong for You?)
In some projects, as in the domain that Glen Alleman has commented on in the first post in this series, it might well be worth spending enough time to generate reasonable estimates and to have an idea about how much the estimate might be off.¬†
In some projects, as in the gather-a-bunch-of-people-across-the-universe that David Gordon discusses in Part 2 of this series, you might need the exercise more of “who will deliver what” first, and then ask “when.”¬†
For both of those kinds of projects (I might call them programs), the cost of people going open-loop is too high. Of course, I would do an everyone-in-the-room planning session for the first month to iron out our deliverables. (When people tell me the cost of that is too high, I remind them about the cost of not delivering.) It’s possible¬†if people understand how to use agile and lean to deliver at least as often as once a month, we don’t need more planning sessions. (If you want to run a program in an agile and lean way, see my program management book.)
In my experience, many people work on one- or two-team projects. The organization has decided on those projects. If you use agile and lean, ¬†you might not need to estimate, if you deliver something every day. The delivery builds trust and provides sufficient feedback and the ability to change.
Here’s the way I like to think about #noestimates:
Noestimates is not about not estimating. It’s about delivering value often enough so you don’t have to estimate. You can spend time on different activities, all leading to delivering product.
I don’t buy what some #noestimates people say, that estimation is a sign of dysfunction. I have found the estimation process useful, as I explained in part 3 of this series.
In both Glen’s and Dave’s examples, it’s quite difficult to deliver value often, especially at the beginning of a program. Sure, you might decide to limit work in progress, or work in one- or two-week iterations. But the value you can deliver? Wow, the projects are so large and dispersed, it’s quite difficult to see value that often. You might see pieces of value. One vendor produces a proof of concept. Maybe another integrates two small chunks. That’s probably not enough value for people to see the product evolve.
On the other hand, when I can use an agile and lean approach for programs, I have been successful in delivering working product across the program every day. If you have SaaS, you can do this. I have done this with the software part of the program for a software/hardware product. That was valuable for everyone on the program.
When I think in #noestimate terms, I think of showing value for the entire product.
Here’s an example from my work. I write in small chunks. Okay, these blog posts have been massive. Not what I normally do on a daily basis. Because I write in small chunks, I can make progress on several books in the same week. That’s because I only have to finish a few paragraphs and I can be done with that part.
When I develop new workshops, I often start with the simulation(s). Once I know the activities, it’s even easier to design the debriefs and the material. I might take several days to develop a simulation. I call them drafts. I can do a draft in about an hour. The draft has value because I can ask people to review it. It’s a small deliverable.
In general, I timebox my work to finish something valuable in an hour. That’s because I make my deliverable small enough to show value in an hour. That’s the same idea as having a size “one” story. For you, a 1 might be a morning, but it’s probably not an entire day.
Back when I wrote code for a living, I was not good enough to deliver in ¬†hour-long chunks. Maybe if I’d used TDD, I could have. I found estimation helpful. That’s why I worked in inch-pebbles. I could still show value, and it might not be several times a day. It was always at least every other day.
When I was a tester, I was good enough to write very small code chunks to test the product. That’s when I realized I’d been working in too-large chunks as a developer. When I was a manager, I tried to timebox all meetings to 50 or 55 minutes. I didn’t always succeed, but I was successful more often than not. Some meetings, such as one-on-ones, I timeboxed to 20 minutes.
In my work, I want to show value as early and as often as possible. ¬†When I work with teams and managers, that’s part of my work with them. ¬†Not because delivering something in an hour is the goal. It’s because the faster you deliver something, the more value you show. The faster you can get feedback and know if you are on the right track.
I have found it helpful to create an¬†order of magnitude estimate for a project, so we all understand the general size/cost/duration of the project. Then, I start to deliver. Or, if I’m leading the team in some way, the team delivers.
The smaller the deliverable, the more often ¬†you can get feedback and show value. I have seen these benefits from working this way:
To me, the idea of #noestimates is tied up in small chunks of value.
#Noestimates is not for everyone. Just as detailed estimation is not for everyone. Think about what is right for your context: your team, your project, and yes, your management.
The posts to now:
I’ll do a summary post, including a pointer to the original article in part 5.
One of my previous Practical Product Owner students said, “We use story size to know when to swarm or mob on a story.” People tackle stories up to 5. (They use Fibonacci¬†series for story size.) They might pair or swarm on stories starting at size 8. Even if they have a 21 (or larger) size story, they swarm on it and finish it in a couple of days, as opposed to splitting the story.
They use estimates to understand the size and complexity of the feature. (I would call their features “feature-sets,” but they like to call that one big thing a feature.)
You might not like that approach. I think it’s a¬†fine way of not fighting with the PO to split stories. It’s also helpful to work together to solve a problem. Working together spreads knowledge throughout the team, as a team.
My experience with estimation is that it’s easy for me to not understand the magnitude of the work. We manage this problem in agile/lean by estimating together, or working together, or with timeboxing in some way.
The first time we solve a particular problem, it takes longer. The first time I worked on a control system (embedded software), I had to learn how things worked together. Where did the software interact with the hardware? What were the general risks with this kind of a product? The first time I self-published a book, everything took longer. What were the steps I needed to finish, in what order?
I worked on many control systems as a developer. Once I understood the general risks, my estimates were better. They were not sufficiently accurate until I applied the rules of deliverable-based planning. What deliverables did I need to deliver? (I delivered something at least once a week, even if it was data from what I now know is a spike.) What inch-pebbles did I need to create that deliverable?
The more I broke the work down into deliverables, the better the estimate was. The smaller the chunks, the better my estimate was. The more I broke the problem down, the more I understood what I had to do and what the risks were.
One of the things I like about agile and lean is the insistence on small chunks of value. The smaller my chunk is, the more accurate my estimate is.Estimates can help people understand risks.
You’ll notice I talked a lot about risks in the above section. There are general project risks, such as what is driving the project? (See Manage It! or Predicting the Unpredictable, or a series I wrote a few years ago, Estimating the Unknown.) We optimize different work when we know what is driving the project. That’s the project view.
We have possible risks in many deliverables. We have the general risks: people get sick, they need to talk the duck, they multitask. But, each deliverable has its own risk.
I’ve said before software is learning, innovation. You may have done something like this project before, so you have domain expertise. But, you have probably not done this new thing here.
When I estimate, I start thinking about what I need to do, how to solve this problem. Then, I start thinking about the problems I might encounter in solving those problems.
I can’t get to the problems unless I have inch-pebbles. I am a big-picture person. I see the whole problem, possibly even the whole solution, and I skip some of the steps in my head. I estimate top-down as a start. Unless I create my inch-pebbles, I am likely to gloss over some of the risks because I start top-down.
You might not be like me. You might estimate bottom-up. You might see all the details. You might not miss any steps in solving the problem as you think about it. (I wonder about people like you: do you see the big picture at the beginning, or does it evolve for you?)
I have met some people who estimate inside out. They tell me they see part of the big picture and part of the small steps. They iterate on both parts until they see and can estimate the whole thing.
I have taught a number of estimation workshops. Most of my participants are top-down people. They see the result they want and then envision the steps to get there. I have met some small number who start bottom up. I have met two people who are inside-out. I don’t know if that’s a normal distribution, or just the people who participate in my workshops.Estimates can help people understand possible first steps.
When people think about the first thing that can provide value, and they think about how to make that first thing small (either inch-pebbles or agile stories), they can more easily see what the first deliverable could be. They can discuss the deliverable progression (in agile with a product owner and in a more traditional life cycle with a project manager or a product manager).
I have found the discussion of deliverable progression very helpful. Many years ago, I was the lead developer for a gauge inspection system (machine vision on an assembly line). I asked the customer what he wanted to see first. “Can you see the gauge enough to give us some kind of an answer as to whether it’s a good gauge?” was his answer.
Notice he said “enough,” not “a perfect inspection.” We did a proof of concept in a couple of days. In the lab, with the right lighting, we had an algorithm that worked well enough. You might think of this as a discovery project. Based on that deliverable, we got the contract for the rest of the project. If I remember correctly, it took us close to 6 months to deliver a final system.
For that project, I acted as a cross between a project manager and what we now call a product owner. We had release criteria for the project, so I knew where we were headed. I worked with the customer to define deliverables every two weeks, after showing a demo of what we had finished every two weeks. (This was staged delivery, not agile. We worked in week-long timeboxes with demos to the customer every two weeks.)
This is in the days before we had project scheduling software. I drew PERT diagrams for the customer, showing date ranges and expected deliverables.
A few years ago, I coached a project manager. She was the Queen of the Gantt. She could make the Gantt chart do anything. I was in awe of her.
However, her projects were always late—by many months. She would work with a team. They would think it was a six-month project. She would put tasks into the Gantt that were two-, three-, and four weeks long. That’s when I understood the problem of the estimation unit. “If you measure in weeks, you’ll be off by weeks.” Her people were top-down thinkers, as I am. They glossed over some of the steps they needed to make the product work.
I explained how to do deliverable-based planning with yellow stickies. The people could generate their tasks and see their intersections and what they had to deliver. She and the team realized they didn’t have a 6-month project. They had a project of at least a year, and that was if the requirements didn’t change.
When they started thinking about estimating the bits, as opposed to a gross estimate and applying a fudge factor, they realized they had to spend much more time on estimating and that their estimate would be useful. For them, the estimation time was the exploration time. (Yes, I had suggested they do spikes instead. They didn’t like that idea. Every project has its own culture.)How do your estimates help you?
Maybe your estimates help you in some specific way that I haven’t mentioned. If so, great.
The problem I have with using estimates¬†is that they are quite difficult to get right. See Pawel Brodzinski’s post,¬†Estimation? It‚Äôs Complicated‚Ä¶¬†In
In Predicting the Unpredictable, I have a chart of how my estimates work. See the Power Law Distribution: Example for Estimation. (In that book, I also have plenty of advice about how to get reasonable estimates and what to do if your estimate is wrong.)
In my measurements with my clients and over time, I no longer buy the cone of estimation. I can’t make it work for agile or incremental approaches. In my experience, my estimates are either off by hundreds of %, or I am very close. We discover how much I am off when the customer sees the first deliverable. (In Bossavit’s Leprechauns of Software Engineering, (or on leanpub)¬†he says the cone of estimation was never correct.)
For me, deliverables are key to understanding the estimate. If, by estimating, you learn about more deliverables, maybe your estimation time is useful.
Since I use agile and lean, estimating time for me is not necessarily useful. It’s much more important to get a ranked backlog, learn if I have constraints on the project, and deliver. When I deliver, we discover: changes in requirements, that we have done enough, something. My delivery incorporates feedback. The more feedback I get, the more I can help my customer understand what is actually required and what is not required. (I often work on projects where requirements change. Maybe you don’t.)
I realized that I need a part 4, that specifically talks about noestimates and how you decide if you want to use noestimates. Enough for this post.
In the first part of this series, I said I liked order-of-magnitude estimates. I also like targets in lieu of estimates. I’ll say more about how estimates can be useful in part 3.
In this part, I’ll discuss when I don’t like estimates.
I find estimates not useful under these conditions:
There are more possibilities for using estimates in not-so-hot ways. These are my “favorite” examples.
Let me take each of these in turn and explain how agile specifically helps these. That’s not because I think agile is the One and Only Answer. No, it’s because of the #noestimates discussion. I have used #noestimates in a staged-delivery project and on agile projects. I have not been able to do so on iterative or serial (waterfall/phase gate) projects. Of course, with my inch-pebble philosophy, I have almost always turned an iterative or serial project into some sort of incremental project.People Estimate on Behalf of the Project Team
We each have some form of estimation bias. I have a pretty good idea of what it takes me to finish my work. When I pair with people, sometimes it takes longer as we learn how to work with each other. Sometimes, it takes much less time than we expected. I expect a superior product when I pair, and I don’t always know how long it will take us to deliver that product. (I pair-write with any number of people during the course of the year.) Even with that lack of knowledge, we can pair for a short time and project to a reasonable estimate. (Do a little work and then re-estimate.)
When people who are not part of the project team estimate on behalf of other people, they don’t know at least these things: what it will take the real project team to deliver, how the people will work together, and how/if/when the requirements will change. I have my estimation bias. You have yours. We might learn to agree if we work together. But, if we are “experts” of some sort, we don’t know what the team will encounter and how they will handle it.
I too often see experts ignore requirements risks and the potential for requirements changes. I don’t trust these kinds of software estimates.
Now, when you talk to me about construction, I might answer that we know more about construction. We have dollars per sq. foot for houses. We have dollars per road mile for roads. And, I live in Boston, the home of the Big Dig.¬†Every time we remodeled/rebuilt our house, it came in at just 10% over the original number. We worked hard with the builder to manage that cost.
Those projects, including the Big Dig, were worth it.
How do we make software projects worth it? By delivering value as often as possible and asking these questions:
Software is not a hard product. It is infinitely malleable. What we deliver on Monday can change the estimate for what we want to deliver on Tuesday, Wednesday and Thursday. We can’t do that with hard products.
When other people estimate, we can’t use what we learn by working together and what we have learned already about this domain. Agile helps this specifically, because we deliver often and can re-estimate the backlog if we need to do so. We understand more about the remaining risks because we deliver.Managers Use (Old) Estimates for the Project Portfolio
I have seen managers use estimates to value projects in the project portfolio. I wrote a post about that years ago: Why Cost is the Wrong Question for Evaluating Projects in Your Project Portfolio.
Here’s the problem with old estimates. Estimates expire. Estimates are good for some time period. Not forever, but for some number of weeks. Depending on how you work, maybe the estimate is good for a couple of months. Estimates expire because things change: the team might change. The codebase and the requirements have certainly changed.
However, project¬†cost is only one part of the equation. Value has to be another part when you think about the project portfolio. Otherwise, you fall prey to the Sunk Cost Fallacy.
You might say, “We use¬†ROI (return on investment) as a way to value projects in the project portfolio.” Now you depend on two guesses: what it will take for you to complete the project and the sales/adoption rate for the release.
ROI is a surrogate measure of value. When I have measured the actuals (what it actually took us to finish the project and the actual revenue at three, six, nine and twelve months out, we almost always did not meet the projected ROI. And, because we chose that project with great-looking ROI, we incurred a cost of delay for other projects. “If we don’t release this project because we are doing something else, what is the effect on our revenue/adoption/etc?” (See Diving for Hidden Treasures to read about the different costs of delay.)
People often say, “These two projects are equal in terms of project cost. If I don’t use ROI, how can I decide between these projects?”
I have never seen this to be true, and it’s quite difficult to predict which project will be shorter. Here are some options:
Agile helps the entire project portfolio problem because we can all see progress on an agile project: demos, product backlog burnup chart, and retrospective results. We know a lot more about what we finish and where we are headed. We can stop working on one project because we don’t leave work in an unfinished state.Management Wants the Comfort of a Single Estimation Date
I supply a range of dates for my projects: possible, likely, pessimistic. I sometimes supply a confidence range. I have met many managers who do not want the reality of estimation. They want a single date: September 1, 2pm.
The problem is that an estimate is a guess. I can only know the exact duration or cost when I’m done with the project. I can get closer as we finish work, but I can’t know for sure months in advance. For a year-long project, I can guess as to which quarter/three month period. As we finish the project, I can spiral in on a date. By the last quarter, I can be within a couple of weeks of knowing.
Managers get paid the big bucks to manage the organization with assumptions, risks, and unknowns that we explain to them. When we work on projects, it’s our job to manage our risks and deliver value. The more value we deliver, the fewer unknowns our managers have.
Agile (and incremental approaches) help us manage those unknowns. Nothing is perfect, but they are better than other approaches.
I’ve worked with several managers who wanted one date. I gave them the pessimistic date. Sometimes, I provided the 90% confidence date. Even then, there were times we had more problems than we anticipated. Meeting that date became impossible.
A single-point estimate is something we like. Unfortunately, a single-point date is often wrong. Management wants it for any number of reasons.
If one of those reasons is assurance that the team can deliver, agile provides us numerous ways to get this result without a single-point estimate: set a target, see demos, see the product backlog burnup chart.
I have nothing against estimation when used properly. These are just three examples of improper estimate use. Estimates are guesses. In Part 3, I’ll talk¬†when estimates might be useful.
(Sorry for the length of this post. I’ll stop writing because otherwise I’ll keep adding. Sigh.)
As a public speaker, I get the weirdest requests.
Sometimes, event organizers want me to provide some “seed questions” that a moderator can ask me after a presentation. Usually, they use these when audience members do not immediately raise their hands when asked if they have any questions. In such a case, the moderator switches to a prearranged seed question after which the audience has usually awakened from its coma.
I don’t like giving organizers seed questions. Why should I be the one to tell them which questions they must ask me? It makes me think of a not-to-be-named family member who asked kids to pull on one of his fingers when he felt some gas coming up. And when they innocently pulled a finger, guess what happened? He thought it was hilarious.
Event organizers know their audiences better than I do. There’s no need to be lazy or to defer the bootstrapping of the Q&A to me. It is their job to make sure that we answer the important questions of their audience. And they shouldn’t care about anything that I most urgently want to get out of me.
When moderators do their job well, they generate a question or two on behalf of their audiences. And when they do, it happens often enough that they pose me questions I would never have imagined, and I need to think and offer an answer fast!
That prevents me from being lazy too.
I’m not going to let anyone pull my fingers. So don’t ask. If I have something relevant to say, I’ll say it. I don’t need to have it pulled out of me. Instead, I look forward to getting surprising questions that will challenge me!
(c) 2008 Derek Bridges, Creative Commons 2.0
My new book Managing for Happiness is available from June 2016. PRE-ORDER NOW!