Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

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!

Project Management

A Theory of Speculation

Herding Cats - Glen Alleman - Sun, 02/08/2015 - 16:37

Screen Shot 2015-02-07 at 9.36.52 PMJust 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?

No Estimates

Related articles Planning And Estgimating Is Required for Project Success Estimating is Risk Management Here, There Be Dragons
Categories: Project Management

What's in a Domain?

Herding Cats - Glen Alleman - Sat, 02/07/2015 - 16:42

Do Not Remove Aircraft PowerWhen 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: 

  • 􀂆 large-scale heterogeneous systems,
  • 􀂆 embedded systems for automotive applications,
  • 􀂆 telecommunications,
  • 􀂆 wireless ad hoc systems,
  • 􀂆 business applications with an emphasis on web services etc.

Our daily lives depend on complex software-intensive systems, from banking to communications to transportation to medicine.

Some Application Domains for SIS

  • Automotive
    • Characteristics
      • Hard real-time
      • Severe resource constraints (high cost pressure)
      • Highly interconnected
      • High reliability and safety requirements
      • User interface critical
      • Extreme increase in complexity (can be observed and is further expected)
    • Trends:
      • 􀂄Drive-by-wire
      • 􀂄Model-driven development
      • Test automation
      • Software architecture (AUTOSAR)
      • Safety analysis
  • 􀂄Transportation
    • Characteristics
      • Hard real-time
      • Some resource constraints
      • Large-scale systems
      • Heterogeneous systems
      • Very high safety requirements
    • Observation:
      • 􀂄Safety standards important (CENELEC, EN 50128)
      • Very long-winded certification procedures (even for small components)
      • Very conservative approach common

And more for these domains. 

  • 􀂄Avionics - my personal favorite
  • 􀂄Space missions - my second personal favorite
  • 􀂄Medicine technique - know a little about this
  • 􀂄Industrial automation - not a lot about process control systems
  • Telecommunication - don't know much about this

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
Categories: Project Management

Overarching Paradigm of Project Success

Herding Cats - Glen Alleman - Fri, 02/06/2015 - 16:22

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.

Screen Shot 2015-01-30 at 1.31.01 PM

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.

Screen Shot 2015-01-30 at 1.21.32 PM

Related articles 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"
Categories: Project Management

How to Design a Book Cover… 5 Rules

NOOP.NL - Jurgen Appelo - Thu, 02/05/2015 - 17:27
how-to-design-a-book-cover

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.

The post How to Design a Book Cover… 5 Rules appeared first on NOOP.NL.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Wed, 02/04/2015 - 15:02

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.

Driving in the darkMy favorite though is this one. Driving in the rear view mirror. 

Objects are closer3

 

Related articles We Suck At Estimating Building the Perfect Schedule Don't Manage By Quoting Dilbert
Categories: Project Management

What Model Do Your Estimates Follow?

Cone of UncertaintyFor years, we bought the cone of uncertainty for estimation—that is, our estimates were just as likely to be over as under.

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:

  1. Estimate small chunks of work that a team can complete in a day or so.
  2. Keep WIP low.
  3. Replan as you finish work.
  4. Watch your cycle time.
  5. No multitasking.

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.

Categories: Project Management

How to Write a Book: Structured or Emergent

NOOP.NL - Jurgen Appelo - Tue, 02/03/2015 - 19:29
how-to-write-a-book

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.

The post How to Write a Book: Structured or Emergent appeared first on NOOP.NL.

Categories: Project Management

What does it mean when we say 80% confidence in a number?

Herding Cats - Glen Alleman - Tue, 02/03/2015 - 17:07

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.

  • Statistics are calculated - this means the data from we are looking at, the time series of values for example in a project are used in a calculation
  • Parameters are estimated - a parameters from these numbers is then¬†estimated from the time series. This estimate has a confidence interval. From this estimate we can make inferences. ¬†

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:

  • Unbiased - the expected value of the estimator must be equal to the mean of the parameter
  • Consistent - the value of the estimator approaches the value of the parameter as the sample size increases
  • Relatively Efficient - the estimator has the smallest variance of all estimators which could be used.

The Confidence Interval

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 Waiting 
1     3.600      79 
2     1.800      54 
3     3.333      74 
4     2.283      62 
5     4.533      85 
6     2.883      55

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

Screen Shot 2015-02-02 at 6.35.16 PM

 If we use R as our analysis tool, we can get a sense of what is happening statistically with Old Faithful. (R code below)

> attach(faithful)     # attach the data frame 
> eruption.lm = lm(eruptions ~ waiting)

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") 
     fit    lwr    upr 
1 4.1762 4.1048 4.2476 
> detach(faithful)     # clean up   We can see there is 95% confidence interval of the mean eruption duration for the waiting time of 80 minutes is between 4.1048 and 4.2476 minutes.   Now to a Project Example In the graph below the black line to the left is the historical data from a parameter I want to estimate from it's past value. But I need an 80% confidence and a 95% confidence interval for the customer as to what values this parameter will take on in the future. We can see from the Time Series of the past value both the 80% confidence and the 95% confidence bands for the possible value the parameter can take on the future.

Untitled

What Does The Mean?

It means two things:

  • When we say we have an 80% confidence that a parameter will assume to value, we need to know how that parameter behaved in the past.
  • When we hear that we are estimating the future from the past, we¬†MUST¬†know about the behaviours of those past values, the size of the population, and the same size, before we can determine the confidence in the possible future outcomes. Have an Average Value without this data is prettu much useless in our decision making process.

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.

Footnote

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
Categories: Project Management

Thoughts on Estimation

Mike Cohn's Blog - Tue, 02/03/2015 - 15:00

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:

  • Where have small-scale estimates actually been useful to your team?
  • What have you done to get rid of estimates if you found them troublesome?
  • If management insisted on estimates, how have you been successful in turning that around?

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.

Thanks!

You Need Feature Teams to Produce Features

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?

 

Categories: Project Management

Sources for Reference Class Forecasting

Herding Cats - Glen Alleman - Mon, 02/02/2015 - 16:19

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

Screen Shot 2015-02-01 at 12.24.18 PM

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
Categories: Project Management

How to Define Your Target Audience… with Questions

NOOP.NL - Jurgen Appelo - Mon, 02/02/2015 - 16:16
target-audience

“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.

Categories: Project Management

Start with Problem, Than Suggest The Solution - Part Deux

Herding Cats - Glen Alleman - Mon, 02/02/2015 - 03:44

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 end I want a Panel Van to deliver groceries for my door-to-door organics company.
  • I want vehicle ¬†for a purpose, to provide a capability to do something that fulfills a need or a mission, to conduct my business.
  • I've defined the need, capability, or mission up front - I ¬†know what I want to do with the outcome - I want to deliver groceries.
  • I have some idea of why I need this vehicle, what value I will receive from it, and some sense of how much I'm willing to pay to receive this value. Since my ROI for the vehicle is is simple.
    • ROI = (Value - Cost) / Cost

In the agile example below - the Like this! panel makes none of these examples

  • I don't really know what I want, otherwise I wouldn't be willing to pay for something that doesn't meet my needs.
  • I can't use a skateboard, a scooter, a bicycle, and a motorcycle to accomplish my mission. I need a Panel Van.

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. 

Agile evolution

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. 

Toyota

Related articles Your Project Needs a Budget and Other Things Building the Perfect Schedule
Categories: Project Management

Here, There Be Dragons

Herding Cats - Glen Alleman - Sun, 02/01/2015 - 19:52

Serpentsanddragons

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. 

This is the source of Value at Risk modeling defined as the maximum possible loss at a given probability - Model uncertainty and VaR aggregation, June 24, 2013. Prof. Dr. Paul Embrechts.

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.

  • My value at risk is $27,000. I should spend some amount of time making sure I'm on the right track to produce benefit from my 6 week 2 person, database integration project. But that time should be quick and provide some sense that my efforts will work. Maybe 30 minutes looking at the possible¬†margin¬†I need to raise the confidence in completing inside that 6 week period.
  • My value at risk is in excess of $2B for a nation wide health care enrollment systems used indirectly by all 50 states and directly by a large number of states. I'd better have a deep understanding of the¬†long tail aspects of estimates for cost, schedule, and technical performance. So some type is modeling (Monte Carlo) connected with the Reference Classes I'm going to use to drive the Probability Distribution Functions for the model, a Risk Register containing the reducible and irreducible risks connected to my model, and a probabilistic critical path analysis of all the¬†blocking factors for this project. With this I can start to understand the¬†probabilities¬†of success, but will need to do the analysis again every time we have a deliverable to make sure we're in track

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
Categories: Project Management

Late Start = Late Finish

Herding Cats - Glen Alleman - Sat, 01/31/2015 - 18:31

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?

Screen Shot 2015-01-29 at 7.36.47 PM

The answer to this is simple:

  • If we have a schedule for the project, which contains the needed work efforts, in the planned sequence with an estimated duration for that effort - the Most Likely duration - then we can model the probability of a completion date with Monte Carlo Simulation.
  • The question is¬†what is the range of possible durations an activity can have, before we actually start performing that work?

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

From the Forward of Technical Risk Management, Jack V. Michaels, by Norman Augustine author of Augustine's Laws.

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.

Screen Shot 2015-01-31 at 8.22.36 AM

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


Related articles Qualitative Risk Management and Quantitative Risk Management We Suck At Estimating Building the Perfect Schedule Estimating is Risk Management Probability and Statistics of Project Work
Categories: Project Management

We Suck At Estimating

Herding Cats - Glen Alleman - Fri, 01/30/2015 - 17:40

SadeeyoreWhen I hear "we suck at estimating," or "we can't make good estimates, because people take them as commitments," I wonder what would be the answer if those statements were restated as... 

"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
Categories: Project Management

Estimating is Risk Management

Herding Cats - Glen Alleman - Thu, 01/29/2015 - 18:06

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 Projects

Related 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
Categories: Project Management

What Development & Test Managers do in Agile Organizations

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:

  • Develop trusting relationships with the people on the project team, and in their function.
  • Provide coaching and mentoring opportunities for people.
  • Provide communities of practice for the people.
  • Remove obstacles for the people and team.
  • Start and nurture the hiring effort whenever you need to hire new people.
  • Help people with career development.
  • Provide feedback to people, and help people learn how to provide feedback (meta-feedback).
  • Provide coaching and meta-coaching when people want it.
  • Help the organization understand its capacity and make decisions about the project portfolio.
  • Help influence the rest of the organization with the agile culture.

Functional managers are champions for the team, and shepherds for the process. They are servant leaders.

Here’s what functional managers do not do:

  • Have status conversations. If the team is agile, the team understands its status. If you need help seeing their board, that’s a problem the team needs to solve. If they need help seeing their status, they need to change their board¬†or their process for updating each other.
  • Move people on or off teams, once you or the team establishes itself.
  • Ask people to do something the team has not committed to, or that the product owner has not added to the kanban board. That’s right. “Your” team doesn’t work for you; the team works for the product owner.
  • Micromanage any part of the project work. Or, manage any part of the project work.

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.

Categories: Project Management

Join Me on My Private Virtual Street Team in February!

NOOP.NL - Jurgen Appelo - Thu, 01/29/2015 - 09:26
Michal Moitk

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.

Categories: Project Management

Building the Perfect Schedule

Herding Cats - Glen Alleman - Wed, 01/28/2015 - 16:30

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
Categories: Project Management