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!
Just started a new book¬†The Physics of Wall Street: Brief History of Predicting the Unpredictable. The seeds of decision making in the presence of uncertainty, started long ago with Louis Bachelier's¬†A Theory of Speculation.
This work, started in 1892, and published in 1914, lays the groundwork for the mathematics of making choices in the presence of uncertainty.¬†
March 29, 1900, is likely the day mathematical finance was born. On that day a French doctoral student, Louis Bachelier, successfully defended his thesis Theorie de la Speculation at the Sorbonne. The jury, noting ¬†the topic was far different from any of those ¬†considered by other candidates, appreciated its high degree of originality.
In the to the book left, with commentary and background, of Bachelier's seminal work is provided in English. The thesis is a remarkable document. In mathematical terms, Bachelier's achievement was to introduce many of the concepts of what is now known as stochastic analysis. His purpose of the thesis was to provide a theory for the valuation of financial options. He came up with a formula that is both correct on its own terms and surprisingly close to the Nobel Prize-winning solution to the option pricing problem by Fischer Black, Myron Scholes, and Robert Merton in 1973, the first decisive advance since 1900.
Those options theories, are the basis of Real-Options. RO are used in making decisions about future¬†values for investments - many in the IT domain - based on probabilistic outcomes for valuation of capital budgeting decisions.¬†A¬†real option¬†itself, is the right¬†‚ÄĒ but not the obligation¬†‚ÄĒ to undertake certain business initiatives, such as deferring, abandoning, expanding, staging, or contracting a capital investment project in the presence of uncertainty.¬†
Many in the anti-estimates business may want to read about how¬†making decisions in the presence of uncertainty¬†is core to all business management, investment decisions, any decision about spending money when the outcome of that decision is probabilistic, based on the underlying statistical processes that drive these outcomes. ¬†So when we read, ask¬†how can this actually be the case? Time to ask if the basis of mathematical decision making got suspended?Planning And Estgimating Is Required for Project Success Estimating is Risk Management Here, There Be Dragons
When I hear about a process, a procedure, a tool, a method, an idea, and even an anti-process like #NoEstimates, I first ask¬†in what domain is this applicable? And when the answer comes back,¬†software I suspect the speaker hasn't considered much outside his own domain.
Here's some domains I work in that are Software Intensive Systems (SIS).¬†
A software-intensive system is any system where software contributes essential¬†influences to the design, construction, deployment, and evolution of the system¬†as a whole.¬†[IEEE-Std-1471-2000]
It is observed in¬†EU-NSF-SIS 2004¬†and¬†Peter Freeman and David Hart. A science of design for software intensive systems. Commun. ACM, 47(8):19-21, 2004 (Dr. Freeman was a professor at UC Irvine, when I was a grad student in Physics, when we had to take classes outside out major).
Software has become a key feature of a rapidly growing range of products and¬†services from all sectors of economic activity. Software-intensive systems¬†include:¬†
Our daily lives depend on complex software-intensive systems, from banking to¬†communications to transportation to medicine.
Some Application Domains for SIS
And more for these domains.¬†
So when we hear about¬†the next big thing that is going to revolutionize the world of software development, in what domain is that actually going to happen, does the speaker have any experience in that world, is there any evidence that this¬†next big thinghas been applied in that world with success, and where can we read about it?Related articles We Suck At Estimating Building the Perfect Schedule Don't Manage By Quoting Dilbert
There is a tendency, and I do this as well, to focus on our own little corner of the universe. I've learned to recognize when I'm doing this and have been taught by several good Systems Engineering leaders and a senior cost leader to have a¬†touchstone¬†to test ideas against.
This is how the 5 Immutable Principles came about.
A second touchstone are the components of project performance management. In this picture, cost, schedule, and delivered capabilities are independent variables coupled with non-linear dynamic connections. When someone says¬†cost of delay, that's cost. When we hear¬†features¬†it capabilities. Time, deadlines, sequence of work, it's schedule.Building a Credible Performance Measurement Baseline The Actual Science in Management Science Your Project Needs a Budget and Other Things We Suck At Estimating Building the Perfect Schedule Don't Manage By Quoting Dilbert Qualitative Risk Management and Quantitative Risk Management The False Notion of "we haven't seen this before"
One of the hardest parts of the book writing process is the design of the cover. Some experts claim the book cover is the most important aspect of the book. If the cover doesn’t appeal to your audience, neither a great description nor fantastic content are going to help you sell the book, because most of your audience won’t be taking notice. This leads to my first rule for book cover design: don’t do the design yourself.
Ensure Good Data gets to the Bad Decision Makers
This quote is from a DOD Contracting surveillance officer on the inability of some managers to use data for decision making.
Making good decisions requires good data. Data about the future. The confidence in that data starts with gathering good data. It then moves to understanding the naturally occurring and event based uncertainties in that data. With this understanding the decisions can then be based on risk informed, statistically adjusted impacts to cost, schedule, and technical performance for future outcomes.
No Data? Driving in the Dark with Your Headlights Off. Hoping you don't run off the road.
¬†Related articles We Suck At Estimating Building the Perfect Schedule Don't Manage By Quoting Dilbert
Laurent Bossavit, in The Leprechauns of Software Engineering, shows us how that assumption is wrong. (It was an assumption that some people, including me, assumed was real.)
This is a Gaussian (normal) distribution. It’s what we expect. But, it’s almost never right. As Laurent says,
“Many projects stay in 90% done for a long time.”
What curve do our estimates follow¬†if they don’t follow a Gaussian distribution?
Troy Magennis, in “The Economic Impact of Software Development Process Choice – Cycle Time Analysis and Monte Carlo Simulation Results,” suggests we should look at the Power-Law (Weibull) distribution.
What this distribution says with respect to estimation is this: We are¬†good at estimating small things. We get much worse with our estimation quickly, and for the long tail ¬†(larger and larger chunks of work), we are quite bad.
Why? Because creating software is innovation.¬†Building software is about learning. We better our learning as we proceed, assuming we finish features.
We rarely, if ever, do the same thing again. We can’t apply precise estimation approaches to something we don’t know.
You should read Troy’s paper¬†because it’s fascinating. It’s well-written, so don’t worry about not being able to understand it. You will understand it. It’s only 10 pages long.
The question is this: What effect does understanding an estimation model have on our estimates?
If we know that the normal distribution is wrong, then we won’t apply it. Right, why would you do something you know to be wrong? You would not estimate large chunks and expect to have a +/- 10% estimate. It doesn’t make sense to do that.
But what can we do? On the printed paper, what the proceedings will show p. 5061, Troy has a table that is telling. In it, he says that if you have large unique work items or you have large WIP, you will have poor predictability. (He has suggestions for what to do for¬†your process.)
My suggestions for your estimation:
What should you do when people ask you for estimates? What kind of requirements do you have? If you have large requirements, follow my advice and use the percentage confidence, as in¬†We Need Planning; Do We Need Estimation?¬†Read the estimation series or get Essays on Estimation.
You can predict a little for estimates. You can better your prediction. And, you may have to predict a large effort. In that case, it helps to know what distribution model might reflect your estimate.
I believe most authors apply the hybrid approach to writing. They start anywhere they want, either with a logical outline or with some random writing, but then they bounce up and down continuously to ensure that their writing has both structure and surprise.
Confidence intervals are the means to measure population parameters. A concern in inferential statistics (making a prediction from a sample of data or from a model of that data) is the estimation of the population parameter from the sample statistic.
The sample statistic is calculated from the sampled data and the population parameter is estimated from this sample statistic.
One issue in inference making - estimating - is sample size determination. How large of a sample do we ¬†to make an accurate estimation? This is why small sample sizes produce very unreliable inferences. For example sampling 27¬†stories¬†in an agile project and making in inference about how the remaining¬†stories are going to behave is Very sporty business.
To have a¬†good estimator, that is to make good estimates from sampled or simulated data the estimator must be:
The point estimate differs from the population parameter due to the sampling error, since there is no way to know who close it is to the actual parameter. Because of this, statisticians give an interval estimate as a range of values used to estimate the parameter.
What's the cost of this project going to be when we're done with all our efforts, given we done some work so far?
The confidence interval is an interval estimate with a specific level of confidence. A level of confidence is the probability that the interval estimate will contain the parameter. The level of confidence is 1 ‚ÄĒ őĪ. Where 1‚ÄĒ őĪ ¬†area lies within the confidence interval.¬†The maximum error of the estimate, E,¬†is ¬Ĺ the width of the confidence interval.
The ¬†confidence interval for a symmetric distribution is the point estimate minus the maximum error of the estimate is less than the true population parameter which is less than the point estimate plus the maximum error of the estimate.
An Example from Actual Observations
While staying at the Yellowstone Lodge during the Millennium (year 2000), our kids got sick with some type of flu going around the lodge. My wife lay in bed, tending them all night long and passed the time recording data about¬†Old Faithful¬†erupting outside our bedroom window.¬†
The data looked something like this:
Eruptions is the duration of the eruption of Old Faithful¬†and¬†Waiting is the waiting time before the next eruption. There is a correlation between these pieces of data. This is due to the physical processes of expelling water at high temperature and the refilling processes of the caverns below the surface
¬†If we use R as our analysis tool, we can get a sense of what is happening statistically with¬†Old Faithful. (R code below)
Then we create a new¬†data frame¬†that set the waiting time value.>¬†newdata¬†=¬†data.frame(waiting=80)
We now apply the¬†predict¬†function and set the predictor variable in the¬†newdata¬†argument. We also set the interval type as¬†"confidence", and use the default 0.95 confidence level.>¬†predict(eruption.lm,¬†newdata,¬†interval="confidence")¬†
What Does The Mean?
It means two things:
What Does This Really Mean?
Anyone suggesting we can make decisions about future outcomes in the presence of uncertainty and at the same time in the absence of estimating those outcomes is pretty much clueless about basic probability and statistics random processes.¬†
Since all project variables - the statistical parameters - are random variables, driven by underlying process that we must¬†estimate¬†using statistical process available in R and our High School Stats book.
When it is mentioned¬†I use bayesian statistics, or¬†I use Real Options,¬†ask if they are using something like the¬†R Tutorial Resource with Bayesian Statistics. And of course the source code for the statistical processes described above.¬†Then ask to see their data. There seems to be a lot of people tossing around words, like Bayesian, Real Options, Monte Carlo, and other¬†buzz words without actually being able to show their work or the result that an be tested outside their personal ancedotes. Sad but true.Related articles Taxonomy of Logical Fallacies Building a Credible Performance Measurement Baseline Late Start = Late Finish
Ron Jeffries has a new book out, "The Nature of Software Development". I highly recommend everyone read it--in fact, Ron is one of the few people whose every word I recommend people read. I love how he always gives me something to think about. I don't always agree with him--but that's why I like reading what he has to say. If I always agreed, I'd never learn anything and there'd be no point in that.
To celebrate Ron's new book, I asked him to write a guest post for us, which I'm happy to share below. I know you'll enjoy it. Be sure to check out his offer to win one of the great drawings from the book! --Mike
My new book, The Nature of Software Development, will hit the streets in final form any minute now. The book is "long-awaited", at least by me, as it has been percolating in my mind and computer for years. In Nature, I try to share my view that under all the complications and complexity of software development, there is an essential simplicity. I believe that if we keep that simplicity in mind, we can find our way out of the twisty little passages that make up the software business. The pictures in this article are taken from the book. It's full of pictures, hand-drawn by the author (that's me), in the manner of a chalk-talk or illustrated keynote talk.
Did I say "final form"? How silly of me. For example, Nature talks about estimation in its chapter on planning, and elsewhere, including a bonus chapter on the "Five-Card Method" of quickly getting a handle on the scope of the project. But the topic of estimation rages on, and my thinking continues to change, not in direction so much as in refined understanding. I've probably published four or five articles on estimation since the book was finished, and here come some more thoughts for you.Large Scale: Budgeting over estimation
At the overall project level, I favor a quick estimate if you must, and prefer a budget. Not a multi-million dollar ten year budget but a week, a month, maybe three months for a small team to get a real handle on what the product is and how long it will take until we can have something of use.
We build high-value items first, and continue that so long as the product shows itself to be worth investing in. If we need faster progress, maybe we add people, or even teams. Let's move into the unknown with exploration, not with a huge commitment that may be misplaced.Small Scale: Maybe no estimates at all
Starting a large project with a small one is controversial enough. At the level of the next few weeks' work, the Scrum Sprint, I have begun to recommend against estimating stories at all, be it in points, hours, or gummi bears.
As Eisenhower said, "Plans are useless, but planning is essential." It's commonly believed that a key part of planning a Sprint is to have estimates for all the backlog items, and the Scrum Guide even tells us that we should track our performance against those estimates.We might drop or defer a story
One possible advantage of this is that the Product Owner might decide differently what to do if something is going to cost four days instead of two. It could happen: I've seen it happen. In the case I saw, the team scribbled estimates beside stories on the white board, and erased them at the end of the meeting. They found it useful to decide how much work to take on, and at least once, their Product Owner withdrew a story because it was a couple of days more costly than she thought.
This might happen, and it might even happen often enough to matter. Still, I've only seen it once. Even so, if we're doing Scrum as we're supposed to, the stories are in priority order, we forecast how many we can take on, and we work through them. That works so nearly perfectly that the estimates at the Sprint level are generally wasteful.Estimates will make us learn about the story
Another often-quoted value to small-scale estimates is that it causes the developers to learn enough about the story to really understand it, resulting in better implementations, fewer mistakes, and so on. Yes, it's true that if you will actually think about what's being asked for, you'll do better. It's not clear that estimates are an ideal way to do that.
That said, someone pointed out a value to doing Planning Poker: it quickly identifies stories on which there is mixed understanding, and it provides a ritual where someone who might otherwise be quiet has an occasion to speak. That could be useful. Like my friends with the white board, you might want to consider throwing away any estimates that come out.Commonly misused
More pernicious -- I used that word in Nature, a copy editor suggested that I change it, and I refused -- is the common practice of comparing estimates to actual "so we can improve our estimates". Hello!?!? How about we improve almost anything rather than estimates? The cleanness of our code, the coordination among our team, the communication between Product Owner and developers? Surely there's something more important to do than focus on the cost of things and guessing the cost correctly. Maybe we could focus on the value?Value rather than cost
In Nature, I take the position that "Value is what you want," and I mean that literally. Maybe you want revenue. Maybe your product saves lives. Maybe it organizes meetings. Whatever the point of your product is, it is almost certainly not "let's make our actuals match our estimates".
As the picture above suggests, backlog items offer various levels of value, and come with varying costs. What the picture does not show is that value had better be many times larger than cost, or the feature isn't worth doing. If that picture were drawn to scale, the cost dimension would be so narrow we could hardly see it. The picture shows us that what matters most is building high-value items first. Almost any other consideration is far secondary to that one.
I could go on. In fact I have gone on. Beyond the estimation topics discussed in *Nature*, which are just a tiny part of a small book, I've already published quite a few more detailed articles about the topic. And I need your help.Valuable prizes. Well, prizes.
I certainly hope you'll read, enjoy, and promote Nature. But I have another little proposal in mind for you here.
I'd like to write a few more articles about estimation, mostly about how to get rid of it, but also about what it's good for and how to do it well, if I can find out. To do that, I'd like to hear from you on topics like these:
Write me an email at ronjeffries at acm dot org, telling me a bit about your discoveries.
I'll pick at least two emails and dig into them, maybe more. Probably we'll exchange a few notes or talk on the phone. Maybe you'll write an article for my web site or your own. I'll certainly write about your ideas on ronjeffries.com.Wait, don't answer yet!
If I use your idea, I'll send you a signed print of one of the drawings from the book, printed on the very best paper that will go into my printer. Your choice of drawing if you wish, or I'll pick one.
In addition, I'll draw an equal number of entries randomly. If I use two emails for articles, two more random pictures. If three, three. And so on.
As you'll see when you read the book -- and I hope you do -- these pictures are suitable for framing and for display in any small dark room in your house, such as a closet or pantry. And quite likely, if your cat is like mine, your cat will sit on the drawing if you put it on the floor.
What a fantastic opportunity! Let's see if we can begin to build a community understanding of when estimates are good and when they aren't, and how to work with them, and to work without them.
Oh, and do please consider getting a copy of the book. The pictures are in color, so you might prefer the paper version, or to read it on your color e-reader.
Many organizations create teams by their architectural part: front end, back end, middleware. That may have worked back in the waterfall days. It doesn’t work well when you want to implement by feature. (For better images, see¬†Managing the Stream of Features in an Agile Program.)
Pierce Wetter wrote this great article on LinkedIn, There is no “front end” or “back end.”¬†Notice how he says, referring to the yin/yang picture,
Your product isn’t just the white part or the black part above. It’s the whole circle.
That has implications for how you structure your teams.
If you have front end, back end, or middleware teams, you lose the holistic way of looking at features. You can’t produce features—you produce components, parts of features that work across the architecture. Even if everyone does their job perfectly, they still have to knit those pieces together to create features. Too often, the testers find the problems that prevent features.
Instead, you want a product development team, a feature team. That team has someone from the back end, someone from the front end, someone from middleware, and a tester, at minimum. Your team may have more people, but you need those people to be able to create a feature.
You might call these teams product development teams, because they produce product chunks. You can call them feature teams because they can create features.
Whatever you call them, make sure—regardless of your life cycle—that you have feature teams. You can have feature teams in any approach: serial, iterative, incremental, or agile. What differentiates these teams from functional or component teams is that feature teams can produce features.
Features are what you offer to your customers. Doesn’t it make sense that you have teams that create features?
Reference Class Forecasting is a useful source of data for making estimates in a variety of domains.
And some databases used for RCF
Then there are tools for parametric estimating
A sample of the nearly endless materials on how to apply Reference Class Forecasting
So when you here¬†we can't possibly estimate this piece of software. It's never been done before.¬†Look around a bit to see if Someone has done it, then look so more, maybe they have a source for a Reference Class you can use.¬†Related articles Good Project and Bad Project Building a Credible Performance Measurement Baseline Your Project Needs a Budget and Other Things We Suck At Estimating
“Can our organization be a little bit more like Pixar, Spotify, Netflix, Zappos, Virgin, Valve or IDEO? Is there something I can do to get a better company culture? Better collaboration? Better management?”
There is a reason why I started the book description of my #Workout book on Amazon with this question. For me, it defines the target audience of the book.
The post How to Define Your Target Audience… with Questions appeared first on NOOP.NL.
A metaphor in agile development of building a transportation device in the picture below. There were a few tweets about stretching the metaphor, or my favorite¬†of course you could build a car, if that's what you wanted.
If You Don't Know What Done Looks Like in Units of Measure Meaningful to the Decision Makers, You're On a Death March Project To Nowhere
Starting a project without the end in mind has been a bad idea for a long time
Suppose one of you wants to build a tower. Will he not first sit down and estimate the cost to see if he has enough money to complete it? For if he lays the foundation and is not able to finish it, everyone who sees it will ridicule him saying, "This fellow began to build and was not able to finish."¬†- Luke 14:28-30
The logic of the picture goes like this:
In the agile example below - the¬†Like this! panel makes none of these examples
So when it is suggested that the second path to the car (the bottom picture) is the way to produce a¬†capability -¬†in the absence of a domain and a context of that domain, I'd suggest
This is a¬†Solution¬†Looking for a Problem to Solve
In that condition there are not many people willing to spend money for vehicles they're not interested in using for their final purpose. And simply saying¬†not this, but¬†this¬†has little value to someone needed to Panel Van and without the Panel Van, can't do their business. So it's going to be hard to get a¬†seat at the table until the connection with the Needed Capabilities, fulfilling the business case, or accomplishing the mission are the starting point, rather than the suggested solution.¬†
In the bottom picture, if those outcomes can't be used, re-used, or resold, the Car in #5 is then burdened with a¬†unrecoverable¬†sunk¬†cost of all the vehicles that come before it. This rarely seems to be discussed in the agile paradigm where this picture is common.¬†
Not Knowing What You Want - in terms of a Capability - is a good way to waste money
Imagine a Toyota production line where the assembly of the car takes place incrementally. The car dealer sells you the car AFTER it comes off the assembly line. You'd not want to pay for a¬†partially completed car. You want a¬†Whole car. A car that meets your needs. In the bottom picture you may in fact want to own the skateboard, scooter, bicycle, motorcycle and then the car. We have a garage full of skateboards, scooters, bicycles, no motorcycle, a 4 cars. But those vehicles,¬†each with a purpose, a cost and a value.¬†
Jorion (2007) wrote that ‚ÄúWestern Europe conquered the world because of a technological¬†revolution that started from the attempts to measure the world.‚ÄĚ In the same way, attempts¬†to measure risk - (and its related project performance impacts) - more definitively, realistically, and accurately will surely lead to better¬†project management. - thanks to: "Here, There Be Dragons: Considering the Right Tail¬†in Risk Management,"¬†Christan B. Smart,¬†Missile Defense Agency, Redstone Arsenal, Alabama,¬†Journal of Cost Analysis and Parametrics, 5:65‚Äď86, 2012.
Making estimates of cost, schedule, and technical performance outcomes and their impacts to programmatic and technical risk in the absence of¬†long tails is venturing into waters where Dragons live.
In the insurance business - and other financial domains -¬†conditional tail expectations¬†is applied to mitigate risk.¬†
When questioning to perform or not perform some method of managing a project, select from a variety of features, or make any decision involving cost, schedule, or performance, ask first¬†what's the value at risk? The answer is the basis of your decision. And making decisions without estimating these impacts creates even more food for the Dragon.
And for all projects in between, ask¬†what am I willing to¬†lose¬†if I'm seriously wrong about the cost and¬†schedule?¬†What should I invest to¬†decrease¬†the probability to an acceptable level that I'm wrong about my estimates? That's one of the basis of¬†Value at Risk.
When you hear¬†we can make decisions about future outcomes in the absence of estimates -¬†think how tasty you'll be to that Dragon when he eats you alive.Related articles Qualitative Risk Management and Quantitative Risk Management Probability and Statistics of Project Work Good Project and Bad Project Estimating is Risk Management
In a CrossTalk article Risk Management for Dummies, Tom DeMarco speaks about late software projects and the approaches for the solution. The notion of¬†early start as the solution for¬†late finish needs to address the core question, but fails to address the root cause of¬†lateness - no schedule margin.
How soon should we have started to finish¬†on or before¬†the needed finish time?
The answer to this is simple:
Good question. And of course like all questions about some future activity we'll need to¬†Estimate those values. We can't actually manage - in any credible manner - without estimating. Anyone suggesting otherwise has likely only encountered trivial projects where the¬†Value at Risk¬†was low enough that no one cared is you were late or over budget.
An Example of Managing In The Presence of Uncertainty
Columbus proposed a voyage to Ferdinand and Isabella in 1486. The monarchs promptly set up a special commission of¬†learned men to study the proposal, which they found vague and arcane. After four years of unsatisfactory discussions with the master mariner, the commission's finally rejected the proposal.
To their credit they did not abandon Columbus and soon¬†recalled Columbus not to plan again, but to name his price for carrying out the voyage. The price was enormous. Columbus insisted on being knighted, appointed a grand admiral and viceroy, and given the unwillingness to compromise, the king and queen dismissed Columbus. Eventually, they relented and accepted all of Columbus's demand.
I (Norm Augustine) put forth this example because all parties involved could have benefited from risk management. Columbus could have presented his proposal containing each element of risk, but consider the payoff, well worth the investment.
Ferdinand and Isabella could have assessed the "price of doing nothing." The commission of experts could have have a framework in which they could evaluate the¬†technical¬†feasibility of the proposal. If the parties had studied the technical risk management, perhaps we'd be celebrating 1486, not 1492
For an simple schedule, like the Wright Brothers meeting their contractual data to the U.S. Army of August 31 1908 for the delivery of the Wright Flyer, they needed a confidence level of 80% for the¬†on or before¬†date. The schedule margin of 10 days provided the¬†protection for that date.
What Does This Mean?
The first meaning, missing from the CrossTalk article is.
Schedules without margin are late on day one
It means¬†Estimating is Risk Management. No estimates, no risk management. No risk management, lower probability of project success. For schedule risk we need¬†irreducible and¬†reducible¬†uncertainties that drive the schedule. The for the¬†reducible uncertainties, we need activities to reduce the risk from that uncertainty. For¬†irreducible¬†uncertainties, we need margin to protect each major deliverable.
Risk Management is How Adults Manage Projects - Tim Lister
Remember that next time you hear¬†we can't estimate, we don't want to estimate, estimates are a waste.
Here's How to Manage in the Presence of Uncertainty
"We suck at designing good database schemas." "I can never figure out how to configure the IIS VPN tunneling server." "This Sharepoint Server UI in SP 2012 is so much different than 2007, I can't possibly figure out how to help my customer."
Or, this 401(k) calculation for estimating my retirement is just beyond my ability to comprehend." Or, I can't possibly figure out how much money I need for my summer vacation with my family on a European trip, with relatives I haven't even met, and hotels and rental cars, train tickets, and meals, and other expenses, and airline reservations, and all the unknown and may be unknowable stuff. I'm just going to sit here and mope. Yep, that's me, Eeyore, woo is me. ¬†
What is it in some software domains that allows well educated, experienced developers to simply give up, walk way, allow themselves the be subjected to Dilbert Bosses? When they'd never talk that way about something they are skilled, experienced, and capable of doing?
It's a repeating theme in the #NoEstimates domain. You'd never hear a Flight Avionics engineer at a major space and defense company here in Denver say "we suck at estimating, we suck at testing, we suck at systems integration." Those engineers are asked all the time to "invent new physics to solve a problem." Or other colleagues literally inventing solutions of complex oil & gas software based process control algorithms. Or other colleagues at a major consulting firms deploying ERP and encountering legacy systems they've never seen or integrated before, saying "we can't figure this out, it's too hard and our managers will take our estimates as commitments, so we're simply not going to estimate our work."
Is it missing the engineering discipline taught in college. Where a probability and statistics class is mandatory for all 4 years to be called an engineer. Or even in the business and finance discipline estimating, using complex approaches - time series analysis, principle component analysis, bayesian statistics - is mandatory to be called a finance major. Or in the sciences in general. I say this from direct experience with our children and their significant others who are in finance, bio-sciences, and mechanical engineering all writing software for money as part of their actual profession.
And this whole notion that somehow writing software is not engineering is simply BS. It is engineering in many business domains. So maybe it's a domain issue. Maybe non-engineering cultures can't figure this out.¬†
Or is it maturity? Many appear to be very mature developers? Or is it culture, not geographic culture, but lack of having experienced a development culture where business and engineering work together to determine risks, corrective actions, increasing maturity of the deliverables development processes that allow for growth in both technical and business capabilities - all using agile by the way.
Everything is Uncertain
Business operates on risk taking. Risk taking is about making decisions in the presence of uncertainty. Uncertainty is about probable outcomes - positive or negative - in the future. To make decisions about uncertain outcomes in the future, we need to estimate those outcomes, the cost to achieve them, and the possible benefits from that cost.
No credible business person fails to understand this.
If they do, they won't be in business for long. It's taught in school - business school. Same for engineering and computer science school.
What is it that brings smart, capable, intelligent people to say "we suck," when the facilities (classes, books, articles, tools, external advisors) for learning how to estimate for the required reasons of making decisions about other peoples money for future outcomes, is the very basis of all business - is at hand, with simple learning and practice. These facilities are also the basis of all learning. "We suck" says "we're not capable of learning."
Are those of the #NoEstimate ilk saying "I can't learn?" or are they saying "I don't want to learn?" Because those providing them the money have a vested interest in knowing how much money is needed to produce that treasured¬†Value they claim to be producing.¬†
Just like learning a programming language. Moving from SP 2007 to SP 2012 (that actually sucks), dealing with cyber security. We don‚Äôt say ‚Äúwe suck‚ÄĚ and give up. What is actually going on here? Is some portion of the development community become Eeyore?Related articles Your Project Needs a Budget and Other Things Building the Perfect Schedule Don't Manage By Quoting Dilbert Qualitative Risk Management and Quantitative Risk Management Estimating is Risk Management
Risk Management is about many things - but it is first and foremost about estimating future outcomes.¬†
Suppose one of you wants to build a tower. Will he not first sit down and estimate the cost to see if he has enough money to complete it? For if he lays the foundation and is not able to finish it, everyone who sees it will ridicule him saying, "This fellow began to build and was not able to finish." - Luke 14:28-30
To manage the risk of¬†not enough money, not enough time, the probability of unacceptable outcomes we need to estimate. It's as simple as that and as complex as that.
Risk management is essential for development and production of products and services because key information about cost schedule, and technical performance are uncertain and many times unknown until later in the project.
Proceeding to spend other peoples money in the presence of these uncertainties is not only bad management, it's bad economics - the microeconomics of decision making requires estimating the impacts of any decision - the¬†opportunity cost¬†of that decision.
Risk management is concerned with the outcome of future events, whose exact outcome is unknown, and with how to deal with these uncertainties as a range of possible outcomes. -¬†Effective Risk Management: Some Keys to Success, 2nd Edition, Edmund H. Conrow.
So when you here¬†we can make decisions about the future without estimating ask yourself, did that speaker ever read about risk management. And as Tim Lister says
Risk Management is How Adults Manage ProjectsRelated articles Probability and Statistics of Project Work Qualitative Risk Management and Quantitative Risk Management Decision Making in the Presence of Uncertainty All The World's A Random Process Your Project Needs a Budget and Other Things
Is there room for functional managers, such as development and test managers, in agile organizations? Maybe. It depends on whether they take the role of an agile manager.
If you have organized as a feature teams-based organization, the functional managers (development, test, analysis, whatever) can take these responsibilities:
Functional managers are champions for the team, and shepherds for the process. They are servant leaders.
Here’s what functional managers do not do:
What does this mean? It means that the team members are leaders. Agile pushes responsibility into the teams, and away from traditional management. Agile requires leadership at all levels.
Agile challenges managers to recreate their jobs. An agile transformation requires managers work in an agile way, and work differently than before.
If you want to learn more about the role of leaders and managers in agile, join Gil Broza and me at The Influential Agile Leader, either in San Francisco or London this year. We still have an early bird price until mid-February. Don’t miss this opportunity to help your agile transition and your career.
Do you want to join me on my Virtual Street Team in February?
As my Virtual Street Team member you get:
Exclusive access to me via a private channel
Several exclusive on-line chats with me
A free Kindle or ePub copy of the #Workout book
Free signed copies of the book and my previous two books
The post Join Me on My Private Virtual Street Team in February! appeared first on NOOP.NL.
Plans are critical, a schedule to implement that plan comes next. With the Plan, the sequence of the work is needed to assure the value to the customer is delivered in the proper order. That order is an order because the business (or the mission) usually can't accept¬†all the features and functions at once. So the Plan is the top level sequence, and the schedule is the next level down.
Building the perfect schedule (v6) from Glen Alleman Related articles Your Project Needs a Budget and Other Things Qualitative Risk Management and Quantitative Risk Management