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!
But to do this properly we need to have a standard set of terms that can form the basis of understanding the problem and the solution.
When those terms are redefined for what ever reason, the ability to exchange ideas is lost. For example there is a popular notion that defining terms in support of an idea is useful
So what does this¬†actually mean in the project management domain?
Plans are strategies for the success of the project. Strategies are hypothesis. Hypothesis needs to be tested to determine their validity. These tests - in the project domain - comes from setting a plan, performing the work, accessing the compliance of the outcomes with the plan, that corrective actions in the next iteration of the works.
This seems obvious, but when we hear about the failures in the execution of the plans, we have to wonder what went wrong. Research has shown many Root Causes of project shortfalls. Here are four from our domain:
The root cause for each of these starts with the lack of the following
Unrealistic Performance Expectations
When we set out to define what performance is needed we must have a means of testing that this expectation can be achieved. There are several ways of doing this:
Unrealistic Cost and Schedule Estimates
Inadequate Assessment of Risk
Unanticipated Technical Issues
Each of these¬†issues can be addressed through a Systems Engineering process using Measures of Effectiveness, Measures of Performance, and Technical Performance Measures. The planning process makes use of these measures to assess the¬†credibility of the plan and the processes to test the hypothesis.¬†Related articles Want To Learn How To Estimate? Debunking Let's Stop Guessing and Start Estimating Complex, Complexity, Complicated Estimates
Check out my new lecture series, "Understanding Software Projects." In this lecture series, I explain The Four Factors Lifecycle Model and how understanding that model means understanding virtually every significant aspect of software project dynamics. Current lectures are always free. Check it out at https://cxlearn.com/catalog/22.
Here's a longer description from the website:
Steve McConnell is the author of software industry classics including Code Complete, Rapid Development, and Software Estimation. He has been recognized as one of the three most influential people in the software industry, along with Bill Gates and Linus Torvalds.
Join Steve for this Groundbreaking Lecture Series that unlocks the secrets of effective software development. These lectures distill hard-won insights from decades of research and experience. They present learnings from Steve's work with hundreds of companies and thousands of projects. Lectures are 10-20 minutes each and are easy to include in your work day.Lecture Series Focus
In this lecture series, Steve explains The Four Factors Lifecycle Model, and he explains how understanding that model means understanding virtually every significant aspect of software project dynamics. Topics include:
With the deeper understanding of software projects you gain from this lecture series, you will be able to:
Although the lectures build on each other, they may also be accessed individually. The series is planned to consist of about 50 lectures total. Lectures will be released through 2015 and 2016.
Steve's most recent lectures will be complimentary at CxLearn.com for the duration of the lecture series. The full set of archived lectures can be accessed for $99; they are also included in Construx eLearning's All Access Pass.
What‚Äôs the difference between¬†estimate¬†and¬†guess?
One way to distinguish between them is degree of care taken when we arrive at a conclusion. A conclusion about how much effort work will take. How much it will cost to perform that work. If that work will hve any risk associated with it.¬†
Estimate¬†is derived from the Latin word¬†aestimare.¬†‚ÄúTo Value.‚ÄĚ The term estimate is also the origin of¬†estimable, ¬†meaning ‚Äúcapable of being estimated‚ÄĚ or ‚Äúworthy of esteem", and of¬†esteem, which meaning ‚Äúregard."
To make an estimate means to judge - using some method - the extent, nature, or value of something, with the implication that the result is based on expertise, data, a model, or familiarity. An estimate is the resulting calculation or judgment of the outcome or result. The related term is¬†approximation, meaning ‚Äúclose or near.‚ÄĚ Estimates have a measure of¬†nearness to the actual value. We may not be able to know the actual value, but the estimate is¬†close to that value. The confidence in the estimate adds more information about the¬†nearness of the estimate to the actual value.
To guess is to believe or suppose, to form an opinion based on little or no evidence, or to be correct by chance or conjecture. A guess is a thought or idea arrived at by one of these methods. Guess¬†is a synonym for ¬†conjecture¬†and¬†surmise, which like estimate, can be used¬†as a verb or noun.
One step between a guess and an estimate is an educated guess, a more casual estimate. An idiomatic term for this conclusion is ‚Äúballpark figure.‚ÄĚ The origin of this American English idiom, which alludes to a baseball stadium, is not certain. One conclusion is is related to ‚Äúin the ballpark,‚ÄĚ meaning ‚Äúclose‚ÄĚ in the sense that one at such a location may not be in a precise location but is in the stadium.
We could have a hunch or an intuition about some outcome, some numerical value. Or we could engage in guesswork or speculation.
An interesting idea is ‚ÄúDead reckoning‚ÄĚ means the same thing as¬†guesswork, though it originally referred to navigation based on reliable information. Near synonyms describing thoughts or ideas developed with more rigor include¬†hypothesis¬†and¬†supposition, as well as¬†theory¬†and¬†thesis.
A guess is a casual, ¬†spontaneous conclusion.¬†
An estimate is based on some thought and/or data.
If those paying you can accept a Wild Ass Guess then you're probably done. If they have tolerance (risk tolerance) for loosing their¬†value at risk if you're guess is wrong, then go ahead and Guess. Otherwise some form of estimate is likely needed to inform your decision about some outcome in the future that is uncertain.Related articles How We Make Decisions is as Important as What We Decide. The Flaw of Empirical Data Used to Make Decisions About the Future Build a Risk Adjusted Project Plan in 6 Steps Want To Learn How To Estimate?
The Improv Cards game contains 52 playing cards with pictures on them. You play it with at least three people, though best is probably a table of four to six players.
Managing other people's money - our internal money, money from a customer, money from an investor - means making rational decisions based on facts. In an uncertain and emerging future, making those decisions means assessing the impact of that decision on that future in terms of money, time, and delivered value.
To make those decisions - in the presence of this uncertainty - implies we need to develop information about the variables that appear in that future. We can use past data of course. That data needs to be adjusted for several factors:
No answers to these questions? That data you collected not likely to have much value in making decisions for the future.
In last week’s blog post, I wrote about whether team members should sign up for tasks during sprint planning. I concluded that team commitment goes up when names are left off specific tasks during sprint planning, and this is a good thing.
But, starting a sprint without names on any tasks can also feel very unsettling to teams and ScrumMasters who are new to Scrum. So, I want to offer some advice on how to get comfortable with this idea.
If you’d prefer to leave sprint planning with a name on every task, go ahead; have team members sign up for tasks and make sure each task has a name next to it. Do this for perhaps a team’s first five sprints until everyone is comfortable with the process.
Then switch to having people sign up for only about half of the tasks in the sprint. This will be more than enough to get started and probably won’t feel any worse—or any better—than when everything had a name next to it at the start of the sprint.
But it’s an important first step in the direction of getting out of the habit of allocating tasks to individuals during sprint planning.
Do this for two sprints. After two sprints, have team members sign up for only one-fourth of the total tasks in the sprint. At this point, you’ll almost certainly start to see most of the benefits of a real-time sign-up strategy.
You can stop there if you’d like. Or allocate 25 percent of tasks for two sprints and then go all the way to 0.
Working over the week on a release of a critical set of project capabilities and need a break from that. This post will be somewhat scattered as I'm writing it in the lobby to get some fresh air.
Here's the¬†post asking for a conversation about estimates. Here's a long response to that request.
Let's ignore the term¬†FACT for the moment as untestable and see how to arrive at some answers for each statement. These answers are from a paradigm of¬†Software Intensive Systems, where Microeconomics of decision-making is the core paradigm used to make decisions, based on Risk and Opportunity Costs¬†from those decisions.
So if the OP is actually interested in moving from the known problem of using estimates in a dysfunction way, let's stop speaking about how to make decisions without estimates, and learn how to make good estimates needed for good decisions.
This issue of¬†Harvard Business Review is dedicated to¬†Make Better¬†Decisions. Start with reading how to make good decisions. There is a wealth of guidance how to do that. Why use¬†Dilbert-style management examples. We all now about those. How about some actionable corrective actions to the root causes of bad management. All backed up with data beyond personal anecdotes. Reminds me of eraly XP where just try it was pretty much the approach.¬†So if the OP is really interested in...
Let‚Äôs use our collective influence and intelligence to take the discussion forward to how we can cure the horrible cancer in our industry of Estimate = Date = Commitment.
Then there are nearly unlimited resources for doing that. The first is to call BS on the notion decisions can be made without estimates, without stating where this is applicable - first. Acknowledge unequivocally that estimates are needed when the value at risk reaches a level deemed important by the owners of the money, and start acting like the professionals we want to be and gain a seat at the team to improve the probability of success of our projects with credible estimates of cost, effort, risk, productivity, production of value, and all the other¬†attributes of that success.¬†
For those interested in¬†exploring further how to provide value to those paying your salary, here are some posts on Estimating Books
Full attribution to Gaping Void for this carton.¬†http://gapingvoid.com/2010/05/03/daily-bizcard-11-fred-wilson/
Wayne makes realtime estimates on every skate stroke of where he is going, where the puck is going, and where all the defensemen are going to be when he plans to take his shot on goal.
When we hear we can make decisions about the future without estimating the impact from those decision or using only small sample, non-statistically adjusted measures, or ignore the stochastic behaviors of the past and the future we'll be ion the loosing end of the¬†shot on goal.
There simply is no way out of the need to estimate the future for any non-trivial project funded by other peoples money. Trivial project? Our own money? Act as you wish. No one cares what you do. Make a suggestion it works somewhere else, better come to the table with some testable data independent of personal anecdotes.¬†Related articles Root Cause Analysis The Reason We Plan, Schedule, Measure, and Correct The Flaw of Empirical Data Used to Make Decisions About the Future The Flaw of Averages and Not Estimating
Fit for Purpose and Fit for Use
Both these terms are used to describe¬†value of an IT outcome.¬†A product or service value is defined by¬†fit to purpose¬†(utility) and¬†fit to use¬†(warranty).
Fit to purpose, or utility, means that service needs to fulfill customer needs.
Fit for use, or warranty, means that product or service is available when a user needs it.
From Phillippe Kruchten's The Frog and the Octopus we get 8 factors defining a context from which to test any¬†¬†idea that we encounter.
So when we hear something that doesn't seem to pass the smell test, think of Carl's advice
And then when we hear¬†you're¬†just¬†not willing to try out this idea, think of some more of his advice.
Then ask,¬†how is this idea of your Fit for Purpose and Fit for Use in those 8 context factors? Don't have an answer? Then maybe the personal anecdotes are ready for prime time in Enterprise domain.Related articles Root Cause Analysis The Reason We Plan, Schedule, Measure, and Correct
On just a single day, I had to deal with various activities that I can only describe as bureaucracy.
When we hear of a new and exciting approach to old and never ending problems, we need to first ask¬†in what domain is your new and¬†clever¬†solution applicable
No domain, not likely to have been tested outside you personal anecdotal experience.
Here's Mark's Scaling factors. He uses Agile as the starting point, but I'm expanding it to any suggestion that has yet to be tested outside of personal anecdotes
What's the Point?
When a new approach is being proposed, without a domain, it's a solution looking for a problem to solve.
I had the pleasure of meeting Mark Kennaley a week ago in Boulder when he attended the Denver PMI conference. I have¬†talked with Mark on several occasions on social media about the SDLC 3.0 book and concepts. And now his¬†Value Stream: Generally¬†Accepted¬†Practice¬†in Enterprise Software¬†Development,¬†which is a continuation of the first book, but focused not just in the development life cycle but the entire enterprise process.
I say all this for a simple reason. Mark's book is unique in that from the first page it resonated with the ideas I hold dear. It is not only well written, it contains powerful ideas that need to be read any anyone in the enterprise IT business. Mark signed the title page with a phrase that reflects my feelings on many modern topics in project management and software development.
This pretty much sums up my World View for those suggesting solutions to complex problems can be had with simple and many time simple minded ideas. Mosty ideas borrowed from quotes about completely different domains, or recycle words like Systems and Systems Engineering into psycho-babble terms that cannot be tested in practice.¬†
I'm going to write a review of Mark's book chapter-by- chapter. I'm on chapter 3. So far it's a breathtaking read. Mandatory for anyone claiming to work in the Enterprise IT world and be accountable for the spend of other peoples money.
I met Ron at an Agile Development Conference long ago, where I was speaking about agile in government contracting. As well Ron spoke at a local ACM meeting that included many software engineering staff from US West, now Centurylink.
It was interesting to observe the interactions between eXtreme Programming and RBOC software engineers.
I've just started this book, but thought it would be a good read just to see how far the eXtreme Programming paradigm has come. I expect I'll get something out of both books. I'll do the same chapter-by-chapter review here as I'll do for Mark's book.¬†Related articles Root Cause Analysis The Reason We Plan, Schedule, Measure, and Correct The Flaw of Empirical Data Used to Make Decisions About the Future Who Builds a House without Drawings?
Customers buy capabilities to accomplish a business goal or successfully complete a mission. Deliverables are the foundation of the ability to provide this capability. Here's how to manage a project focused on Deliverables.¬†
Deliverables Based Planning from Glen Alleman These capabilities and the deliverables that enable them do need to show up at the time they are needed for the cost necessary to support the business case. They're not the Minimal Viable Capabilities, they're the Needed Capabilities. Anything less will not meet the needs of the business.
During sprint planning, a team selects a set of product backlog items they will work on during the coming sprint. As part of doing this, most teams will also identify a list of the tasks to be performed to complete those product backlog items.
Many teams will also provide rough estimates of the effort involved in each task. Collectively, these artifacts are the sprint backlog and could be presented along the following lines:
One issue for teams to address is whether individuals should sign up for tasks during sprint planning.
If a team walks out of sprint planning with a name next to every task, individual accountability will definitely be increased. I will feel more responsibility to finish the tasks with my name or initials next to them. And you will feel the same for those with yours. But, this will come at the expense of team accountability.
My recommendation is that a team should leave sprint planning without having put names on tasks. Following a real-time sign-up strategy will allow more flexibility during the sprint.
It's popular in the agile world and even more popular in the No Estimates paradigm to use the term¬†empirical¬†data as a substitute for estimating future outcomes. And my favorite meme that further confuses the conversation.
Probabilistic¬†forecasting¬†will outperform estimation¬†every time
This of course is "It is not only not right, it is not even wrong."‚Ä†¬†Probabilistic forecasting IS estimating. Estimating is about the past, present, and future. Forecasting is estimating about the future. I'll save the embarrassment by not saying the name of the #NoEstimates person posting this.¬†
First a definition. Empirical ¬†is¬†originating in or based on observation or experience. But we all should know that that data needs to properly represent two sides of the problem, the past and the future.
Let's look at some flawed logic in this empirical data paradigm:
One more technical detail.
So Now Some Issues Of Using Just Empirical Data
The future is emergent in most development work. If it's a production line, and software development is not production, then past performance is a good indicator of future performance. So let's ask some questions before using this past¬†empirical¬†data:
Don't have the answers to these and working a non-trivial project? Our empirical data is not worth much because it doesn't actually represent the future. Might as well guess and stop using the term empirical as a substitute for you know know much of anything about the future.
With those answers we can build a credible¬†model of the future, with interdependencies between the work, probability distribution functions for the statistical behaviors of the work elements and start asking the Killer question:
What's the probability of completing on or before the need date for the work we are producing?
This answer only tells us the probability, not the exact date. So here's the most important point.
All decisions about future outcomes¬†in the¬†presence of uncertainty need estimates that are¬†placed in the model and assessed for their applicability.
This is called Closed Loop Statistical Process Control. And that's how non-trivial projects are managed. Low value at risk, no one cares if you estimate or not.¬†
‚Ä† Which by the way is the situation with most of ¬†#NoEstimates conjectures, starting with the willful ignorance of the MicroEconomics of decision making as an¬†opportunity cost process. What will is cost us if we decided by multiple choices in the presence of an uncertain future? That questions can't be answered without making an estimate of that opportunity cost.
If you work in a domain, as I do, the need to answer the question¬†when will we providing that needed capability to produce the planned value for the planned amount of money, then estimating is going to be part of answering those questions.
If you work where those paying for the work have little or no interest in asking these questions or knowing these answers, or have confidence you'll not overrun the cost, schedule, and deliver the needed capabilities as planned, then maybe estimates are needed.
Be interesting to hear from those actually paying for those outcomes to see what they need to make decisions in the presence of uncertainty.
Here's some more guidance for getting started with estimating software efforts.
And some tools to help out
So you see a trend here? There is nearly unlimited resources on how to estimate software development projects, how to manage in the presence of uncertainty, how to elicit requirements, how the plan and schedule software projects.
So if you hear¬†we're bad at estimates, that's likely the actual experience for the person making that statement, because the person saying that hasn't yet learned how to estimate. Or when we hear¬†estimates are a waste, it's likely it's not their money, so to them estimates take away from some other activity they see as more important. Why do they care of the project overruns it's budget, is late, or doesn't produce the needed value? Or my favorite¬†estimates are the smell of dysfunction, when there is no domain, root cause, or corrective actions suggested, because that's actually hard work, and it's much easier just to point out bad management than provide suggestions of good management.¬†
Estimating is hard. Anything of value is hard. All the easy problems have been solved.¬†
But if we are to ever get a handle on the root causes of software project failure modes, we do need to seek out the root causes. A that means much more than just asking the 5 Whys. That's one of many steps in RCA and far from the complete solution to removing the symptoms of our problems. So start there, but never leave it there.¬†
Here's some approach we use
Unanticipated cost growth is a symptom of failing to properly estimate in the first place, update those estimates as the project progresses, and deal with the underlying risks that drive that cost growth. Same for lateness and less than acceptable delivered capabilities. Once the estimate has been established in some credible form, adjusted as the project progresses, you of course have to execute to the plan, or change the plan. It's a closed loop system
The answer to the root causes that create the symptoms we so quickly label as¬†smells of dysfunction is NOT to stop doing something, but the learn what the actual cause is. Stopping before this knowledge is acquired leaves the symptom still in place. And that doesn't help anyone.Related articles Who Builds a House without Drawings? Decision Analysis and Software Project Management Herding Cats: Five Estimating Pathologies and Their Corrective Actions Capability Maturity Levels and Implications on Software Estimating Economics of Software Development Qui Bono Want To Learn How To Estimate? Calculating Value from Software Projects - Estimating is a Risk Reduction Process Root Cause Analysis
I have a new article up on agileconnection.com called The Case for #NoEstimates.
The idea is to produce value instead of spending time estimating. We have a vigorous “debate” going on in the comments. I have client work today, so I will be slow to answer comments. I will answer as soon as I have time to compose thoughtful replies!
This column is the follow-on to How Do Your Estimates Provide Value?
If you would like to learn to estimate better or recover from “incorrect” estimates (an oxymoron if I ever heard one), see Predicting the Unpredictable. (All estimates are guesses. If they are ever correct, it’s because we got lucky.)