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

My Zero-Tolerance to Bureaucracy Policy

NOOP.NL - Jurgen Appelo - Fri, 07/18/2014 - 14:19
Zero-Tolerance to Bureaucracy

Sometimes, event organizers ask me to fill out a form asking me for my company name, address, bank account number, bank name, tax number, and much more. They tell me they need this information in order to make their payment to me later. But I think this is a bit silly.

The post My Zero-Tolerance to Bureaucracy Policy appeared first on NOOP.NL.

Categories: Project Management

Do Teams Gel or Jell?

In my role as technical editor for agileconnection.com, I have the opportunity to read many terrific articles. I also have the opportunity to review and comment on those articles.

One such comment is what do teams do? Do they “gel” or do they “jell”?

Gel is what you put in hair. When you “gel” things, you create a thick goo, like concrete. Teams are not a thick goo. Teams are flexible and responsive.

Jell is what you want teams to do. You want them firm, but not set in concrete. When teams jell, they might even jiggle a little. They wave. They adapt. They might even do a little dance, zigging here, zapping there.

You want to keep the people in the teams as much as possible, so you flow work through the teams. But you want the people in the teams to reconsider what they do on a regular basis. That’s called retrospecting. People who have their feet in concrete don’t retrospect. They are stuck. People who are flexible and responsive do.

So, think about whether you have a gelled or a jelled team. Maybe I’m being a nitpicker. I probably am. Our words mean something.

If you have an article you’d like to publish, send it to me. You and I will craft it into something great. Whether or not your team jells.

 

Categories: Project Management

The Myth of Incremental Development

Herding Cats - Glen Alleman - Thu, 07/17/2014 - 17:07

Screen Shot 2014-07-13 at 6.27.34 PMIn the agile world there is a common notion that incremental delivery is a desired approach. Many taught rapid release, even multiple releases a day.

The question is two fold. Can the customer accept the release into use and the other does the customer have the ability to make use of the incremental capabilities of these releases?

Let's start with the incremental release. I know the picture to the left is  considered a metaphor by some. But as a metaphor it's a weak. Let's look a a few previous posts. Another Bad Agile Analogy, Use, Misuse, and Danger of Metaphor. Each of these presents some issues with using Metaphors.

But let's be crystal clear here. Incremental development in the style of the bottom picture may be a preferred method, once the customer agrees. Much of the reterotic around agile assumes the customer can behave in this way, without looking outside the ancedotal and many times narrow experiences of the those making that suggestion. For agile to succeed in the enterprise and mission critical product and project domain, testing the applicability of both pictures is needed.

Ask the customer if they are willing to use the skateboard while waiting for the car? Otherwise you have a solution looking for a problem to solve.

Now to the bigger issue. In the picture above, the top series is a linear development and the bottom an iterative or incremental depending on where you work. Iterating on the needed capabilities to arrive at the car. Or incrementally delivering a mode of transporatation.

The bottom's increment shows 5 vehicles produced by the project. The core question that is unanswered is does the customer want a skate board, scooter, bicycle, motorcycle, and then a car for transportation. If yes, no problem. But if the customer actually needs a car to conduct business, drive the kids to school, or arrive at the airport for your vacation trip.

The failure of the metaphor and most metaphors is they don't address the reason for writing software for money

Provide capabilities for the business to accomplish something - Capabilities Based Planning

The customer didn't buy requirements, software, hardware, stories, features, or even the agile development process. They bought a capability to do something. Here's how to start that process.

Capabilities Based Planning

Here's the outcome and an insurnace provider network enrollemtn ERP system.

Capabilities Map

Producing skateboards, then scooters, then bicycles and then finally the car isn't going to meet the needs of the customer if they want a car or a fleet of cars. In the figure above the Minimal Viable Features, aren't features they are capabilities. For example this statement is a minimal viable product is likey a good description of a Beta Feature. Could be connected to a business capability, but without a Capabilities Based Plan as in above, can't really tell.

Screen Shot 2014-07-16 at 12.16.26 PM

So How Did We Get In This Situation?

Here's a biased opinion informed by my several decades of experience writing code and managing others who write code - we're missing the systems engineering paradigm in commercial software development. That is for software development of mission critical systems, and Enterprise IT is an example of mission critical systems.

Here's some posts:

The patradigm of Systems Engineering fills 1,000's pages and dozen's of books, but it is boiled down to this.

You need to know what DONE looks like in units of measure meaningful to the decision makers. Those units start with Measures of Effectiveness and Measures of Performance.

Each of those measures is probabilistic, driven by the underlying statistical processes of the system. These mean you must be able to estimate not only cost and schedule, but how that cost and schedule will deliver the needed system capabilities measured in MOE's and MOP's.

SE in One Page

Related articles Do It Right or Do It Twice Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Agile vs Waterfall: Introduction Lean Startup, Innovation, #NoEstimates, and Minimal Viable Features
Categories: Project Management

What About Cleaning Toilets?

NOOP.NL - Jurgen Appelo - Thu, 07/17/2014 - 16:00
Cleaning toilets

I often promote work-life fusion, quitting jobs that are not fulfilling, and seeking work that is a calling instead of just a career. But, I hear some people think, can this be true for everyone? Is there a great job, somewhere, for every person in the world?

What about cleaning toilets?

How can this work be fulfilling to anyone?

Well, that depends…

The post What About Cleaning Toilets? appeared first on NOOP.NL.

Categories: Project Management

Control Systems - Their Misuse and Abuse

Herding Cats - Glen Alleman - Wed, 07/16/2014 - 03:23

Modern Contrrol EngineeringProject Management is a control system, subject to the theory and practice of control systems. The Project Management Control System provides for the management of systems and processes - cost estimating, work scope structuring and authorization, scheduling, performance measurement, reporting, for assessing the progress of spending other peoples money.

The level of formality for these processes varies according to domain and context. From sticky notes on the wall for a 3 person internal warehouse locator website of a plastic shoe manufacture -  to a full DCMA ANSI-748C validated Earned Value Management System (EVMS) on a $1B software development project and everything in between.

The key here is if we're going to say we have a control system it needs to be a Closed Loop control system, not an Open Loop control system. On Open Loop system is called train watching, we sit by the side of the tracks and count the trains going by and report that number. How many trains should go by, could go by? We don't know. That's what's shown in the first picture. We sample the data, we apply that data to the process and it generates an output. There is no corrective action, it's just a signal based on the past performance of the system. Some examples of Open Loop control implemented in the first picture:

  • A light switch. Turn it on the light goes on. Turn it off the light goes off. Turn it on and the light doesn't go on, don't know why. Could be the switch, could be the¬†blub is burned out, could be the power is out in the neighborhood.
  • Same for a faucet, the burned on the stove, a simple cloths dryer when you use the timer rather than the¬†sense cloths are dry feature.
  • The really cool shade we just installed for the upper deck. Push the button and it lowers to a present position, push it again and it goes back to the storage position.

The key attribute of Open Loop Control 

  • It is a non-feedback system, is a type of continuous control system in which the output has no influence or effect on the control action of the input signal.
  • In an open-loop control system the output is neither measured nor fed back for comparison with the input.
  • An open-loop system is expected to faithfully follow its input command or set point regardless of the final result.
  • An open-loop system has no knowledge of the output condition so cannot self-correct any errors it could make when the preset value drifts, even if this results in large deviations from the preset value.

The key disadvantage of open-loop systems is it is poorly equipped to handle disturbances or changes in the conditions which that reduce its ability to complete the desired task. 

A close loop system behaves differently. Here's some example of controllers used in the second picture

  • Thermostat for the furnace or air conditioner - Set a target temperature and it holds that temperature pretty much constant¬†
  • Refrigerator cold/hot setting - keeps the food in the refrigerator at a preset temperature¬†
  • Same for the temperature setting for oven.

The key attributes of  Close Loop Control, shown in the second picture

  • Closed-loop systems are designed to automatically achieve and maintain the desired output condition by comparing it with the actual condition.
  • This is done by generating an error signal which is the difference between the output and the reference input.
  • A ‚Äúclosed-loop system‚ÄĚ is a fully automatic control system in which its control action being dependent on the output in some way.

Because the closed-loop system has  knowledge of the output condition - in the case of projects the desired cost, schedule, and technical performance, it is  equipped to handle  system disturbances or changes in the conditions which may reduce its ability to complete the desired task.

When we have a target cost - defined on day one by the target budget, a planned need date, and some technical performance target, closed loop control provides the needed feedback to make decisions along the when, when the actual performance is not meeting our planned or needed performance

Open Closed Loop

In the end it comes back to the immutable principle of microeconomics. When we are spending money to produce a value, we need to make decisions about which is the best path to take, which are the best of multiple options to choose. In our to do this we need to know something about the cost, schedule, and performance forecasts from each of the choices. Then we need feedback from the actual performance to compare with our planned performance to create an error signal. With this error signal, we can then DECIDE what corrective actions to take.

Without this error signal, derived from the planned values compared with the actual values there is no information needed to decide. Sure we can measure what happened in the past and decide, just like we can count trains and make some decision. But that decision is not based on a planned outcome, a stated need, or an Estimated Arrival time for example. 

Without that estimated arrival time, we can't tell if the train is late or early, just that it arrived. Same with the project measurements.

  • We need on average 4.5 stories per iteration. How many stories did you need to do to finish the project on the planned day with the planned capabilities.

Open Loop provides no feedback, so you're essentially driving in the rear view mirror, when you should be looking out the windshield deciding where to go next to escape the problem.

Objects are closer3

Related articles Can We Make Decisions Without Feedback? Seven Immutable Activities of Project Success Agile Requires Discipline, In Fact Successful Projects Require Discipline The DCMA 14 Point Schedule Assessment Control system and its classification The Failure of Open Loop Thinking First Comes Theory, Then Comes Practice All Project Numbers are Random Numbers - Act Accordingly
Categories: Project Management

Quote of the Day - Writing SW For Money Is Micro-Economics

Herding Cats - Glen Alleman - Wed, 07/16/2014 - 03:12

We find no sense in talking about something unless we specify how we measure it. A definition by the method of measuring a quantity is the one sure way of avoiding talking nonsense¬†‚ÄĒ Sir Hermann Bondi

So when we hear a suggested approach to solving any problem, what are the units of measure of the discussion elements, the inputs to that discussion, and the outcomes?

Micro-economics is defined as

A branch of economics that studies the behavior of individuals and small impacting players in making decisions on the allocation of limited resources. Typically, it applies to markets where goods or services are bought and sold.

Certainly in the software development business, goods are bought and sold. Software is developed in exchange for money. The resulting product is then put to work to generate some monetized value for the buyer. The value exchanged for the cost of that value is usually assessed as the Return on Investment

ROI = (Value - Cost of the Value) / Cost of the Value

Economics of Iterative DevelopmentLet's start with some basic concepts of writing software for money. I'd suggest these are immutable concepts in a for proft business world. The book on the left is a ggod start, but there are other materials about the economics of software development. The one that comes to mind is Software Engineering Economics, Barry Boehm, Prentice Hall. While some has suggested this book is dated and no longer applicable to our modern software development paradigm, that could only be true if our modern paradigm is not subject to the principles of micro-economics. And that is unlikely, so let's proceed with applying the principles of micro-economics to the problem at hand. That problem is

How can we know the cost, schedule, and performance of a software product with sufficient confidence into order to make business (micro-economic) decisions about how to manage the limited resources of the project?

Those resources are of course the variables we are trying to determine. Cost, Schedule, and Performance. Each of which contains resources. Cost in software development is primarily driven by staff. Schedule is driven by the efficacy of that staff's ability to write code. And the performance of the resulting outcomes are driven by the skills and experience of the staff, who is consuming the funds (cost) provided to the project.

So if we look at the basics of the economics of writing software for money, we'll see some simple principles.

If it's a product development effort, someone in the marketing and sales department has a planned release date. This date and the projected revenue from that release is in the sales plan. These are random numbers of course -  so I won't repeat that, but all numbers in business are random numnbers until they get entered into the General Ledger.

  • These projected revenue numbers are based on releasing the product with the features needed for customers to buy it.
  • The cost to develop that product is subtracted from the revenue - usually in some complex manner - to produce the retained earnings¬†attributed to the product.¬†
  • This of course is the simple formula
    • Earnings = Revenue - Cost¬†
    • Where cost is categorized in many ways, some attributable to the development of the product, some to overhead, benefits, fringe, and other indirect costs (ODC).
    • Revenue recognition is a continuously evolving issue with taxes and performance reporting in actual firms
    • But for the purposes here, the simple formula will do.¬†Managerial Finance, Brigham and Weston is a good place to look for the details.

If it's a service effort, the customer has engaged the firm to perform some work in writing software, doing consulting around that software, integrating existing software or some combination of these and other software related services. Managing the Professional Services Firm, was mandatory reading along wioth other internal company written books when I worked for a large Professional Services (PS) firm. With our small firm now, we still refer to that book.

  • Some type of problem needs to be solved involving a solution that uses software (and maybe hardware), processes, and people.
  • The cost, schedule, and capabilities of the solution need to be worked out in some way in order to know what¬†DONE looks like. Any one subscribing to this Blog know the¬†Knowing What Done Looks Like is a critical success factor for any effort.
  • But in the case of a services solution, this¬†knowing is a bit more difficult than the product solution, since the¬†customer may not know themselves.¬†
  • This is the golden opportunity for incremental and itertaive development.
  • But in the end the PS customer still needs to know the cost, schedule, and what will be delivered, because that person has a similar ROI calculation to do for those funding the PS work.
Related articles Earning Value from Earned Value How To Assure Your Project Will Fail Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices The Value of Information
Categories: Project Management

The Power of Misattributed and Misquoted Quotes

Herding Cats - Glen Alleman - Tue, 07/15/2014 - 15:30

Warning this is an Opinion Piece.

In a conversation this week the quote Insanity is doing everything the same way and expecting a different outcome. Or some variant of that. Attributed to Einstein. As if attributing it to Einstein makes it somehow more credible, than attributing it to Dagwood Bumstead.

Well it turns out it is not a quote from dear olde Albert. It is also mis-attributed to Ben Franklin, Confucius, and a Chinese proverb.

The first printed record of this quote is in the 1981 Narcotics Anonymous approval version of their handbook. No other printed record is found. 

Why is this Seemingly Trival Point Important

We toss around platitudes, quotes, and similar phrases in the weak and useless attempt to establish credibility of an idea by referencing some other work. Like quoting a 34 year old software report from NATO, when only mainframes and FORTRAN 77 were used, to show the software crisis and try to convince people it's the same today. Or use un-vetted, un-reviewed, charts and graphs from an opinion piece in popular techncial magazine as the basis of statistical analysis of self-selected data

Is it world shaking news? No. Is the balanced of the universe disrupted? Hardly. 

But is shows a lack of mental discipline that leaks into the next level of thought process. It's always the little things that count, get those right and the big things follow. That is a quote from somewhere. But it also shows laziness of thought, use of platitudes in place of the hard work to solve nearly intractable problems, and all around disdain for working on those hard problems. It's a sign of our modern world - look for the fun stuff, the easy stuff, and the stuff we don't really want to be held accountable for if it goes wrong

I will use the Edwin Land quote though, that is properly attributed to him

Don't undertake a project unless it is manifestly important and nearly impossible. 

That doesn't sound like much fun, let's work on small, simple, and easy projects and tell everyone how those successful processes we developed can be scaled to the manifestly important and nearly impossible ones.

Related articles Resources for Moving Beyond the "Estimating Fallacy" How to Deal With Complexity In Software Projects? 50 Common Misquotations, but no Howard Thurman Fake quotes flood social media 31 Famous Quotations You've Been Getting Wrong 6 Famous Misquotes & Where They Came From (Mis)quoting Neil Armstrong
Categories: Project Management

Simplify Prioritization into ‚ÄúNow‚ÄĚ and ‚ÄúNot Now‚ÄĚ

Mike Cohn's Blog - Tue, 07/15/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.

I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason, this doesn’t bother my wife, Laura, but it annoys me. So I’d like to replace the dishwasher.

The clothes washer is doing fine, but the dryer isn’t working too well. I think we’ve had it 14 years, and I sometimes have to run the drying cycle three times before clothes are fully dried. So, I’ll probably want to buy a clothes dryer, too. I’ve also lately become irritated by the toaster. It’s great and works well, but bread doesn’t fit. I have to angle the bread, with part sticking out of the toaster – so, I get partially toasted bread. Or, I flip the bread midway and then get the middle of the bread overly toasted. So, add a new toaster to the list.

After all that, a new car might be nice.

What is this list? Well, my personal Things to Buy Backlog, of course. It’s a prioritized sequenced list of things I plan to buy. To facilitate long-term planning it includes everything I plan to buy for the next 12 months:

  1. Groceries
  2. Tickets to movies that haven’t been released yet
  3. A magazine that I’ll buy in Newark airport next October because I’ll find a cover story intriguing
  4. A new pair of shoes
  5. Big-screen plasma TV
  6. Home theater amplifier
  7. Dishwasher
  8. Clothes dryer
  9. Toaster
  10. Car

Don’t you have a list like this, with that level of detail? Of course not. Neither do I. We don’t make lists like this because such a list is unnecessary. In everyday life, we don’t map out the equivalent of a product backlog.

Instead, we make our purchase decisions in a much simpler fashion: “Now” or “not now.” Do I want that big television now, or not now? And this amount of prioritization is good enough.

In many cases, it is also good enough for our product development projects.

Sure, you’ll always need to know what you’re going to build this sprint. But what you build next sprint will likely depend on what the team delivers this sprint, and on how customers respond to it.

That means you might want to forgo prioritizing any further ahead unless you are in an environment that requires it, such as contract development.

Prioritizing features in a “now/not now” manner streamlines your planning process, allows learning to be incorporated into the planning process, and better matches how we prioritize outside the workplace.

Many projects will find this a very valuable shift.

In this post I write about how to do this within the context of establishing a longer-term vision for a product.

Simplify Prioritization into ‚ÄúNow‚ÄĚ and ‚ÄúNot Now‚ÄĚ

Mike Cohn's Blog - Tue, 07/15/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.

I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason, this doesn’t bother my wife, Laura, but it annoys me. So I’d like to replace the dishwasher.

The clothes washer is doing fine, but the dryer isn’t working too well. I think we’ve had it 14 years, and I sometimes have to run the drying cycle three times before clothes are fully dried. So, I’ll probably want to buy a clothes dryer, too. I’ve also lately become irritated by the toaster. It’s great and works well, but bread doesn’t fit. I have to angle the bread, with part sticking out of the toaster – so, I get partially toasted bread. Or, I flip the bread midway and then get the middle of the bread overly toasted. So, add a new toaster to the list.

After all that, a new car might be nice.

What is this list? Well, my personal Things to Buy Backlog, of course. It’s a prioritized sequenced list of things I plan to buy. To facilitate long-term planning it includes everything I plan to buy for the next 12 months:

  1. Groceries
  2. Tickets to movies that haven’t been released yet
  3. A magazine that I’ll buy in Newark airport next October because I’ll find a cover story intriguing
  4. A new pair of shoes
  5. Big-screen plasma TV
  6. Home theater amplifier
  7. Dishwasher
  8. Clothes dryer
  9. Toaster
  10. Car

Don’t you have a list like this, with that level of detail? Of course not. Neither do I. We don’t make lists like this because such a list is unnecessary. In everyday life, we don’t map out the equivalent of a product backlog.

Instead, we make our purchase decisions in a much simpler fashion: “Now” or “not now.” Do I want that big television now, or not now? And this amount of prioritization is good enough.

In many cases, it is also good enough for our product development projects.

Sure, you’ll always need to know what you’re going to build this sprint. But what you build next sprint will likely depend on what the team delivers this sprint, and on how customers respond to it.

That means you might want to forgo prioritizing any further ahead unless you are in an environment that requires it, such as contract development.

Prioritizing features in a “now/not now” manner streamlines your planning process, allows learning to be incorporated into the planning process, and better matches how we prioritize outside the workplace.

Many projects will find this a very valuable shift.

In next month’s newsletter, I’ll write about how to do this within the context of establishing a longer-term vision for a product.

Simplify Prioritization into ‚ÄúNow‚ÄĚ and ‚ÄúNot Now‚ÄĚ

Mike Cohn's Blog - Tue, 07/15/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.

I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason, this doesn’t bother my wife, Laura, but it annoys me. So I’d like to replace the dishwasher.

The clothes washer is doing fine, but the dryer isn’t working too well. I think we’ve had it 14 years, and I sometimes have to run the drying cycle three times before clothes are fully dried. So, I’ll probably want to buy a clothes dryer, too. I’ve also lately become irritated by the toaster. It’s great and works well, but bread doesn’t fit. I have to angle the bread, with part sticking out of the toaster – so, I get partially toasted bread. Or, I flip the bread midway and then get the middle of the bread overly toasted. So, add a new toaster to the list.

After all that, a new car might be nice.

What is this list? Well, my personal Things to Buy Backlog, of course. It’s a prioritized sequenced list of things I plan to buy. To facilitate long-term planning it includes everything I plan to buy for the next 12 months:

  1. Groceries
  2. Tickets to movies that haven’t been released yet
  3. A magazine that I’ll buy in Newark airport next October because I’ll find a cover story intriguing
  4. A new pair of shoes
  5. Big-screen plasma TV
  6. Home theater amplifier
  7. Dishwasher
  8. Clothes dryer
  9. Toaster
  10. Car

Don’t you have a list like this, with that level of detail? Of course not. Neither do I. We don’t make lists like this because such a list is unnecessary. In everyday life, we don’t map out the equivalent of a product backlog.

Instead, we make our purchase decisions in a much simpler fashion: “Now” or “not now.” Do I want that big television now, or not now? And this amount of prioritization is good enough.

In many cases, it is also good enough for our product development projects.

Sure, you’ll always need to know what you’re going to build this sprint. But what you build next sprint will likely depend on what the team delivers this sprint, and on how customers respond to it.

That means you might want to forgo prioritizing any further ahead unless you are in an environment that requires it, such as contract development.

Prioritizing features in a “now/not now” manner streamlines your planning process, allows learning to be incorporated into the planning process, and better matches how we prioritize outside the workplace.

Many projects will find this a very valuable shift.

In this post I write about how to do this within the context of establishing a longer-term vision for a product.

Work-Life Fusion, not Work-Life Balance

NOOP.NL - Jurgen Appelo - Mon, 07/14/2014 - 14:44
Work-Life Fusion

Sometimes people ask me, ‚ÄúWhat do you mean with work-life fusion? How is that different from work-life balance?‚ÄĚ

Well…

Work-life balance means using Twitter for your work-life and Facebook for your private life. Instead, I have friends, family, and business contacts everywhere! My 13th happy anniverselfie on Facebook was liked by 86 people, half of them were friends and family, and the other half were business contacts. I call that work-life fusion.

The post Work-Life Fusion, not Work-Life Balance appeared first on NOOP.NL.

Categories: Project Management

The Failure of Open Loop Thinking

Herding Cats - Glen Alleman - Mon, 07/14/2014 - 14:12

Screen Shot 2014-07-13 at 9.18.12 PMWhen there are charts showing an Ideal line or a chart of samples of past performance - say software delivered - in the absence of a baseline for what the performance of the work effort or duration should have been, was planned to be, or even better could have, this is called Open Loop control.

The issue of forecasting the Should, Will, Must cost problem has been around for a long time. This work continues in DOD, NASA, Heavy Construction, BioPharma, and other high risk, software intensive domains.

When we see graphs where the baseline to which the delays or cost overages are compared and those baselines are labeled Ideal, (like the chart below), it's a prime example of How to LIe With Statistics, Darrell Huff, 1954. This can be over looked in an un-refereed opinion paper in a IEEE magazine, or a self-published presentation, but a bit of homework will reveal that charts like the one below are simply bad statistics.

Screen Shot 2014-07-13 at 9.26.15 PM

This chart is now being used as the basis of several #NoEstimates presentations, which further propagates the misunderstandings of how to do statistics properly.

Todd does have other papers that are useful Context Adaptive Agility is one example from his site. But this often used and misused chart is not an example of how to properly identify problems with estimates,

Here's some core issues:

  • If we want to determine something about a statistical process, we of course need to collect data about that process. This data is¬†empirical - much misused term itself - to show what happened over time. A time series of samples.
  • To computer a trend, we can of course draw a line through population of data, like above.
  • Then we can compare this data with some¬†reference data to determine the¬†variances between the reference data and the data under measurement.

Here's where the process goes in the ditch - literally.

  • The reference data has no basis of reference. It's just labeled¬†ideal.¬†Meaning a number that was established with no¬†basis of estimate. Just¬†this is what was estimated, now let's compare actuals to it and if actuals matched the estimate' let's call it ideal.
  • Was that¬†ideal credible? Was it properly constructed? What's the confidence level of that estimate? What's the allowable variance of that estimate that can still be considered OK (within the upper and lower limites of OK)? Questions and their answers are there. It's just a line.

We can use the ne plus ultra put-down of theoretical physicist Wolfgang Pauli's "This isn't right. It's not even wrong."  As well the projects were self-selected, and like the Standish Report, self-selected statistics can be found in the How to Lie book

It's time to look at these sort of conjectures in the proper light. They are Bad Statisics, and we can't draw any conclusion from any of the data, since the baseline to which the sampled values are compared Aren't right. They're not even wrong."  We have no way of knowing why the sampled data has a variance from the ideal the bogus ideal

  • Was the original estimate simple na√Įve?
  • Was the project poorly managed?
  • Did the project change direction and the¬†ideal estimate never updated?
  • Were the requirements, productivity, risks, funding stability, and all the other project variables held constant, while assessing the completion date? if not the fundamental principles¬†of experiment desgin was violated. These principles are taught in every¬†design of experiments class in every university on the planet.¬†Statistics for Experimenters is still on my shelf. George Box as one of the authors, whose often misused and hugely misunderstood statement¬†all models are wrong, some are useful.

So time to stop using these charts and start looking for the Root Causes for the estimating problem.

  • No reference classes
  • No past performance
  • No parametric models
  • No skills or experience constructing credible estimates
  • No experience with estimating tools, processes, databases (and there are many for both commerical and government software intensive programs).
  • Political pressure to come up with the¬†right number
  • Misunderstanding of the purpose of estimating - provide information to make decisions.

A colleague (former NASA cost director) has three reasons for cost, schedule, and technical shortfalls

  1. They didn't know
  2. They couldn't know
  3. They didn't want to know

Only the 2nd is a credible reason for project shortfalls in performance.

Without a credible, calibrated, statistically sound baseline, the measurements and the decisions based on those measurements are Open Loop.

You're driving your car with no feedback other than knowing you ran off the road after you ran off the road, or you arrived at your destination after you arrived at your destination.

Just like this post Control Systems - Their Misuse and Abuse

 

Related articles How to "Lie" with Statistics How to Fib With Statistics Control Systems - Their Misuse and Abuse Seven Immutable Activities of Project Success
Categories: Project Management

Software Development is Like Play Writing

Herding Cats - Glen Alleman - Sun, 07/13/2014 - 23:23

WaitingForGodotI stole this idea of this blog from Stephen Wilson's post of a similar name. And like all good borrows I've added, subtracted, and made some changes, because everything is a remix.

I don't know Stephen, but his post is provacutative. I'm assigned to a client outside my normal Defense Department and NASA comfort zone. The client needs a Release Management System integrated with a Change Control Board. Both are the basis of our defense and space software world. This client is trying to use agile, but has little in the way of the discipline needed to actually make it work.

The SWDev is like play writing is a beautiful concept that can be applied to the choas of the new client and also connected back to our process driven space and defense, which by the way makes heavy use of agile, but without all the drama of the it's all about me developer community.

Let's start here:

In both software and play writing, structure is almost entirely arbitrary. Because neither obey the laws of physics, the structure of software and plays comes from the act of composition. A good software engineer will know their composition from end to end. But another programmer can always come along and edit the work, inserting their own code as they see fit. It is received wisdom in programming that most bugs arise from imprudent changes made to old code.

It turns out of course neither of those statements is correct in the sense we may think. There is the act of composition, but that composition needs a framework in which to be developed. Otherwise we wouldn't know what we're watching or know what we're developing until it is over. And neither is actually how plays are written or software is written. It may be an act of composition, but it is not an act of spontaneous creation.

Let's start with play writing. It may be that the act of writing a play where the structure is entirely arbitrary is possible, but it's unlikely that would be a play you'd pay money to see. A Harold Pinter play may be unstructured Waiting for Gadot may be unstructured, but that's not really how plays are written. They follow a structured approach - there is a law of physics for play writing.

  • You need characters - a protagonist and the supporting cast
  • You need a setting - where are we and what's going on that supports the story
  • You need some sort of imbalance between the characters, the setting
  • You need some way to restore the imbalance or leaving it hanging
  • You need to engage your audience in some way that will resonant with the personal feelings

That's about the story of the play. To actually write a play, here's a well traveled path to success. These guidelines are for the outcome of the writing effort starting in the beginning.

  • A rough title is needed to anchor the play in the readers mind.
  • An action statement, describing what ¬†the characters are going to do in the play, as a group, as individual. How are they going to change and who changes
  • The form of the play describing the organization of the characters, the situation, the environment. How does the play's action relate to the emotional qualities of the characters and most importantly to the audience.
  • The circumstances of the time and place of the action and other important conditions.
  • The subject as an informational platform.
  • The characters of course, describing what are the forces driving them and their relationships with each other, the circumstance, and the environment.
  • The conflict. It's boring watching a play that is boring. What are the obstacles that have to be overcome by the characters?
  • The meaning for the play. What is the point of view? What are the key thoughts for the play as a whole and the characters in the play?
  • The style of the dialogue, the composition and manner of this dialogue?
  • And finally a schedule for writing the play. When will it be done?

When we talk about writing software there is a similar story line

  • Who are the protagonist? - they're the end users of the software.
  • What is the setting? - there is a stated need for something new.
  • What is the imbalance? - something is not getting done and it needs to be improved.
  • How do we restore the balance? - by closing the gaps between the imbalance and the balance with a software solution.

The story line is the basis of Capabilities Based Planning. With the capabilities, the requirements can be elicited. From those requirements, decisions can be made for what order to deliver them to produce the best value for the business or the mission. 

This process is about decision making. And decision making uses information about the future. This future information comes many times from estimates about the future. 

 

 

 

Related articles Agile Requires Discipline, In Fact Successful Projects Require Discipline People, Process, or Tools
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Fri, 07/11/2014 - 23:44

Gentlemen, we have run out of money; now we have to think - Winston Churchill

The role of estimating in project and product development is many fold...

  • For product, the cost of development must recouped ¬† over the life cycle of the product. Knowing the sunk cost of the product provides decision making information to the business if the¬†target margin will be achieved and on what day.
  • For projects, the cost of development is part of the ROI equation. ROI = (Value - Cost) / Cost
  • For day to day business operations¬†cash flow is the actual cost of producing outcomes. Budget is not the same as cost. We have define a budget for our work, but some forecast of the cost of that work, gathered from current operations or past performance, let's us know if we have sufficient budget.
  • For products when marginal cost exceeds marginal profit, we're going go out of business if we don't do something about controlling the cost. But our cost forecast and revenue forecast are the¬†steering points to provide feedback for making choices.
  • For projects, the marginal cost and the marginal benefits obey the same rules of microeconomics.

In both cases the future cost and future monetized value are probabilistic numbers.

  • This project or product will cost $257,000 or less with an 80% confidence
  • This project or product will complete on or before May 2015 with a 75% confidence

With both these numbers and their Probability Distribution Function, decisions can be made about options - choices that can be made to influence the probability of project or product success.

Without this information, the microeconomics of writing software for money is not possible and the foundation of business processes abandoned.

In order to make these estimates of cost, schedule, and the technical performance of the project or product, some  model is needed and the underlying uncertainty of the elements of the model. These uncertainties come in two forms

  • Reducible (epistemic uncertainty) - money can be spent to reduce this uncertainty. Testing, prototypes, incremental development.¬†
  • Irreducible (aleatory uncertainty) - this is the normal variance in the process or technical components. The Deming uncertainty. The only action to reduce this uncertainty is¬†margin, Cost margin, schedule, and technical margin. The cost margin is then part of the total project or product budget and the schedule margin part of the total period of performance for the project or the planned release date for the product.

To suggest decisions can be made without knowing this future information violates the principles of microeconomics of business 

Related articles Both Aleatory and Epistemic Uncertainty Create Risk Uncertainty is the Source of Risk Elements of Project Success More Uncertainty and Risk
Categories: Project Management

Registration Opens for More Workshops

NOOP.NL - Jurgen Appelo - Thu, 07/10/2014 - 09:51
open-registration

I’m very happy to say that the Management 3.0 Workout sessions so far have been well received, and they’re getting better every time! I’m almost ready for the summer break, but registration has opened for the remaining workshops this year. Please remember, I will personally visit each city only once!
It was a very joyful and insightful workshop

The post Registration Opens for More Workshops appeared first on NOOP.NL.

Categories: Project Management

A Typical Conversation on Twitter

NOOP.NL - Jurgen Appelo - Wed, 07/09/2014 - 15:58
mouths

writer: “I believe that A is true.”

reader: That’s stupid. Everyone knows that A’ is true.”
writer: “I wasn’t referring to A’. I was talking about A.”

reader: There’s nothing wrong with A’.”

The post A Typical Conversation on Twitter appeared first on NOOP.NL.

Categories: Project Management

It's Not Bottoms Up or Top Down, It's Capabilities Based Delivery

Herding Cats - Glen Alleman - Tue, 07/08/2014 - 21:36

There is a popular notion that agile is bottoms up and tradititional is top down. Neither is actually effective in deliverying value to the customer based on the needd capabilties, time phased to match the business or mission need. 

The traditional - read PMI and an over generalization - project life cycle is requirements elicitaton based. Go gather the requirements, arrange them in some order that makes sense and start implementing them. The agile approach (this is another over generlaizaiton) is to let the requirements emerge, implement them in the priority the customer says - or discovers.

Both these approaches have serious problems as evidenced by the staistics of software development

  • Traditional approaches take too long
  • Agile approach ignore the underlying architectural impacts of¬†mashing up the requirements
Categories: Project Management

Critical Thinking Skills Needed for Any Change To Be Effective

Herding Cats - Glen Alleman - Tue, 07/08/2014 - 15:40

Why is it hard to think beyond our short term vision? Rapid delivery of incremental value is common sense, no one would object to that - within the ability of the business to absorb this value of course. This is called the Business Rhythm. 

But that rapid redelivery of incremental value is only a means to an end. The end is a set of capabilities of the business that allows that business to accomplish their Mission. To do something as a whole with those incremental features. That is turn the features into a capability.

Think about a voice over IP system, who's feature set was incrementally delivered to 5,000 users at a nation wide firm. This week we can call people, receive calls from people, but we don't have the Hold feature yet. Are you really interested in taking that product and putting it to use? 

How about an insurance enrollment system, where you can sign up, provide your financial and health background, choose between policies, but can't see which doctors in your town take the insurance, because the Provider Network piece isn't complete yet.

These are not notional examples, they're real projects I work on. For these type projects - most projects in the enterprise IT world -  an All In feature set is needed. Not the Minimum Viable Product (MVP). But the set of Required Capabilities to meet the business case goals of providing a service or product to customers. No half baked release with missing market features.

You might say, that incremental release of features could be a market strategy, but looking at actual products or integrated services, it seems there is little room for partial capabilities in anything, let alone Enterprise class products. Either the target market gets the set of needed capabilities to capture market share or provide the business service or it doesn't and someone else does.

An internal system may have different behaviours, I can't say since I don't work in that domain. But we've heard loud and strident voices telling us deliver fast and deliver often when there is no consideration for the Business Rhythm of the market or user community for those incremental - which is a code word for partially working - capabilities.

Of course the big bang, design, code test, paradigm was nonsense to start with. That's not what I talking about here. I'm talking about the lack of critical assessment of what is the value flow of the business and only then applying a specific set of processes to deliver that value. Outcome first, then method.

So Now The Hard Part

The conversation around software delivery seems to be dominated by those writing software, rather than by those paying for the software to be written. Where are the critical thinking skills to ask those hard nosed business questions:

  • When will you be done with all the features I need to implement my business strategy?
  • How much will it cost for all those features I to provide those capabilities that fulfill my business plan?

Questions like that have been replaced with platitudes and simple and many times simple minded phrases.

  • Deliver early and often - without consideration of the business needs
  • Unit testing is a waste - because those tests like the internal documentation that provides a long term maintainability platform, aren't what the customer bought
  • We can decide about all kinds of things in the software business without having to estimate anything - a completion violation of the principle of microeconomics, which requires we know the impact of our choices in some unit of measure meaningful to the decision maker. You know something like¬†Money.
Related articles Is There Such a Thing As Making Decisions Without Knowing the Cost? Capabilities Based Planning and Development Business Rhythm Drives Process Do It Right or Do It Twice What Does It Mean To Be DONE? How To Estimate Almost Any Software Deliverable Alan Kay: The pitfalls of incrementalism Don't Start With Requirements Start With Capabilities How To Create Confusion About Root Causes
Categories: Project Management

Choose Backlog Items That Serve Two Purposes

Mike Cohn's Blog - Tue, 07/08/2014 - 15:00

I've been playing a fair amount of Go lately. If you're not familiar with Go, it's a strategy game that originated in China 2,500 years ago. It's along the lines of chess, but it's about marking territory with black and white pieces played on the intersections of a grid of 19x19 lines.

Like Scrum, there are very few rules in Go. Also like Scrum, there are a fair number of principles, often called proverbs in the Go world. One of these Go principles is that a move that does two things is better than a move that does one. For example, a single move may defend a group of the player's stones while threatening the opponent's stones.

Even if you don't know Go, I think this proverb is understandable--after all, something that does two things sounds like it would be better than something that achieves only one goal. But this isn't hard-and-fast advice. It's a principle or proverb because sometimes a move that does one thing--but does that thing very well--will be the better choice.

In addition to playing more Go over the past week or two, I've also spent a lot of time thinking about approaches to prioritizing product backlogs. I hope to share some new thoughts on that here in the coming months.

One thing that has become increasingly clear is that when prioritizing product backlog items, an item that can achieve two goals should often be higher priority.

Let’s see how a product backlog item can help achieve two goals.

Normally, product backlog items are prioritized based on how desirable the new functionality is. This is often, of course, adjusted by how long that functionality will take to develop. That is, a product owner wants something pretty badly until finding out that feature will take the entire next quarter. So, desirability often tempered by cost (usually in development team time) determines priorities.

But there can be other important considerations. And prioritizing highly a product backlog item that is moderately desirable (given its cost) but that also achieves one of these secondary goals may make that item a better first choice overall.

One such consideration is how much learning will occur if the product backlog item is developed. If the team or product owner is going to learn from developing a feature, do it sooner.

Learning can occur in a variety of ways. Developers may learn from doing a product backlog item that the new technology they’d counted on being easy isn’t. A product owner may learn by showing a new user interface built for a specific product backlog item is not something users are excited about as the product owner thought.

Another consideration is how much risk will be reduced or eliminated by developing a product backlog item. If a certain product backlog item needs to be developed and doing so will be risky, my preference is to do that product backlog item early so that I have time to recover from the risk if it hits.

Selecting product backlog items to work on that achieve two (or all three!) of these goals can be a very powerful prioritization strategy. Adding value while simultaneously reducing risk or accelerating learning is just as good as playing a Go stone that achieves two goals.

Choose Backlog Items That Serve Two Purposes

Mike Cohn's Blog - Tue, 07/08/2014 - 15:00

I've been playing a fair amount of Go lately. If you're not familiar with Go, it's a strategy game that originated in China 2,500 years ago. It's along the lines of chess, but it's about marking territory with black and white pieces played on the intersections of a grid of 19x19 lines.

Like Scrum, there are very few rules in Go. Also like Scrum, there are a fair number of principles, often called proverbs in the Go world. One of these Go principles is that a move that does two things is better than a move that does one. For example, a single move may defend a group of the player's stones while threatening the opponent's stones.

Even if you don't know Go, I think this proverb is understandable--after all, something that does two things sounds like it would be better than something that achieves only one goal. But this isn't hard-and-fast advice. It's a principle or proverb because sometimes a move that does one thing--but does that thing very well--will be the better choice.

In addition to playing more Go over the past week or two, I've also spent a lot of time thinking about approaches to prioritizing product backlogs. I hope to share some new thoughts on that here in the coming months.

One thing that has become increasingly clear is that when prioritizing product backlog items, an item that can achieve two goals should often be higher priority.

Let’s see how a product backlog item can help achieve two goals.

Normally, product backlog items are prioritized based on how desirable the new functionality is. This is often, of course, adjusted by how long that functionality will take to develop. That is, a product owner wants something pretty badly until finding out that feature will take the entire next quarter. So, desirability often tempered by cost (usually in development team time) determines priorities.

But there can be other important considerations. And prioritizing highly a product backlog item that is moderately desirable (given its cost) but that also achieves one of these secondary goals may make that item a better first choice overall.

One such consideration is how much learning will occur if the product backlog item is developed. If the team or product owner is going to learn from developing a feature, do it sooner.

Learning can occur in a variety of ways. Developers may learn from doing a product backlog item that the new technology they’d counted on being easy isn’t. A product owner may learn by showing a new user interface built for a specific product backlog item is not something users are excited about as the product owner thought.

Another consideration is how much risk will be reduced or eliminated by developing a product backlog item. If a certain product backlog item needs to be developed and doing so will be risky, my preference is to do that product backlog item early so that I have time to recover from the risk if it hits.

Selecting product backlog items to work on that achieve two (or all three!) of these goals can be a very powerful prioritization strategy. Adding value while simultaneously reducing risk or accelerating learning is just as good as playing a Go stone that achieves two goals.