Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/sources/6' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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!

Herding Cats - Glen Alleman
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.
Syndicate content
Deep Learning Resources about Performance-Based Project Management¬ģ And the Principles, Practices, and Processes to Increase Probability of Success
Updated: 10 hours 18 min ago

Quote of the Day

Mon, 09/26/2016 - 02:05

The essence of mathematics is to not make simple things complicated, but to make complicated things simple - Stan Gudder 

This notion that estimating is hard, estimating are a waste because they are always wrong, willfully ignore the basic mathematics of making decisions of in presence if uncertainty.

Categories: Project Management

Where Are We Going, Doesn't Much Matter It Seems

Sat, 09/24/2016 - 17:15

Chesire Cat‚ÄúWould you tell me, please, which way I ought to go from here?‚ÄĚ
‚ÄúThat depends a good deal on where you want to get to,‚ÄĚ said the Cat.
‚ÄúI don‚Äôt much care where‚Äď‚ÄĚ said Alice.
‚ÄúThen it doesn‚Äôt matter which way you go,‚ÄĚ said the Cat.
‚Äú‚Äďso long as I get SOMEWHERE,‚ÄĚ Alice added as an explanation.
‚ÄúOh, you‚Äôre sure to do that,‚ÄĚ said the Cat, ‚Äúif you only walk long enough.‚ÄĚ

(Alice’s Adventures in Wonderland, Chapter 6)

When we hear

The idea behind the #NoEstimates approach to software development isn't to eliminate estimates but, rather, to explore other ways to solve problems without specifically asking, 'How long will it take?'

We first need to ask by what principle of decision making in the presence of uncertainty, what kind of business project has no interest in how long will it take? The answer seems to be a de minimis project. 

Because in the real world not Wonderland with Unicorns, those paying have some sense of where they want to go, how much they are willing to pay, how long they are willing to wait to get there, and what value will be produced by their investment. De Minimis projects have no concern for those answers.

And those spending that customers money appear not very interested in applying known solutions, instead are answering with the Cheshire Cat's words, since the No Estimates advocates appear to live in Wonderland.

For those interested in learning how to produce credible Estimates and make decisions in the presence of uncertainty, here's some starting places that have served me well:

  • How to Measure Anything, Douglas Hubbard.
  • The Flaw of Averages - Why We Underestimate Risk in the Face of Uncertainty, Sam L. Savage.
  • Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban and Scrum Projects Using Monte Carlo Simulation, Troy Magennis.
  • Decision Analysis for Management Judgement, Paul Goodwin and George Wright.

There are many dozens of other books, and 100's of papers describing how to make estimates in the presence of uncertainty. 

After you do some reading and you hear someone say, estimates are hard, estimates are guesses, estimates are always wrong. estimates are a waste, we can decide with estimates, you'll know they didn't read any of these, haven't a clue what they're talking about, and just making things up as the go. Just like the cat

Related articles Flaw of Averages The Reason We Plan, Schedule, Measure, and Correct Essential Reading List for Managing Other People's Money The Flaw of Empirical Data Used to Make Decisions About the Future Making Decisions In The Presence of Uncertainty Decision Making in the Presence of Uncertainty Why Guessing is not Estimating and Estimating is not Guessing IT Risk Management
Categories: Project Management

Business Dysfunction, Malfunction and Strategy

Thu, 09/22/2016 - 20:03

Mike Cottmeyer posted

This is an interesting article that misses the point of what's going on. Companies have too much management because they are poorly architected and not organized around value producing assets. When you don't have sufficient encapsulation, you end up with too much orchestration. Management is not the problem. It's a symptom of the problem. Firing, or redeploying managers, without fixing the underlying organizational issues will fail cause you to faster and harder. The solution is to refactor the organizational architecture, increasing encapsulation, and then redeploy managers as you are able to reduce the need for them.

The root cause of this dysfunction is the lack of line of sight traceability for Why the firm is in business to how the firm fulfills the strategy needed to deliver on that WHY.

Here's one way that has been shown over the years to connect the dots between Why and How and critically importantly, how the projectize the work efforts needed to implement the strategy.

Notes on balanced scorecard from Glen Alleman With Balanced Scorecard concepts from this briefing, go read Execution: The Discipline of Getting Things Done, then you'll have a foundation for correcting and even avoid what Mike talks about Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Deadlines Always Matter
Categories: Project Management

The #NoEstimates Paradigm and Response

Mon, 09/19/2016 - 02:32

Thanks to Sean Craig's Live Sketch Note for capturing concepts directly from Woody Zuill's talk. This is a good starting point for answering the mail on the notion that decisions can be made in the presence of uncertainty without estimating the impact of those decisions.

NoEstimates Map

Let's look at these Notes and plausible responses to the conjectures. But first, let's look at the motivation for a blog post like this one from Bono's admonition ...

There‚Äôs nothing more dangerous than an idea ‚Äď or a person ‚Äď that‚Äôs almost right. ‚Äď Bono

I attended our Agile Meetup last night, where the speaker walked through  the three current Agile at Scale development methods, all based on Scrum - SAFe, LeSS, and Nexus. He had an interesting statement.

Each of the authors have a different, sometimes slight, sometimes major, approach to producing software using their methods. But each author (or currator of the mehod) has extensive experience testing that method in the field against a broad range of domain and environments. 1,000 to 10's of 1,000's. There is no sure basis of credibilityy for the No Estimates conjecture that decision can be made in the presence of uncertainty without first estimating the impact of the decision. 

When we hear a suggestion about a process that inverts the logic of normal business activities based on a governance framework - say Microeconomics of Software Development, we need to ask who benefits? How would that suggestion be tangibly beneficial to the recipient that is now inverted?

Estimates are for the business, why would the business no longer want an estimate of cost, schedule, or technical performance for the provided capabilities they are paying to have developed?

Turns out of course, it's not the business that has lost the need to estimate, it's those spending the money provided by the business that are suggesting estimates are not needed. This conjecture started long ago when an original post, from his chief coder position at the lawn sprinkler company. (I have those sprinkler heads on my lawn, and they're pretty nice). But his conjecture starts with estimates are a waste, not saying for whom they are a waste for.

Anyone in the finance department, paying his salary, paying the developers has a fiduciary need to know what something will cost when it is done. And since ALL and I Mean ALL software development operates in the presence of uncertainty, the only when to have knowledge of that cost, schedule, and technical content is to make estimates. The further conjecture that estimates are hard, can't be made, and are always wrong, simply affirms that those making those claims don't know how to estimate. That is clear, but that has nothing to do with the principles of estimating in the presence of uncertainty.

I'm no longer a developer, having left development in the early 80's after a career of writing FORTRAN 77 code for missile defense systems that is still in place today. But that has nothing to do with the principles, practices, and processes of writing code using current languages and tools. If you find it hard, but go find someone who doesn't find it hard. 

So let's look at what's being said here about managing software development in the presence of uncertainty using other people's money

Transformation comes from pursuing profound questions than seeking practical answers 

  • Let's assume we are in the business of spending other people'ss money to produce value in exchange for that money.
  • It is likely¬†those paying us have some sort of governance process in place for managing the spend of that money
  • Governance is about¬†decision rights. Who has the¬†Right to decide?
  • Asking profound questions? Who's job is that? Those spending or those paying? This is a crass point of view I know. But in many ways business is crass, harsh, rude, to the point. It's about the money. Unless we live and work in a socialist society, someone has to pay for our efforts. That¬†someone¬†has and expectation of¬†getting their money back, plus some more some time in the future. That expectation is called Return on Investment and requires some knowledge about the future - the uncertain future - to make a decision today.
  • So¬†practical answers are less important than¬†profound questions? Interesting conjecture. Who's most interested in¬†practical answers and¬†profound questions? Those paying or those spending.¬†

It's not your money

Here's an extract from a Deloitte handbook about business decision making

Effective governance and decision making establishes a framework for transformation and can improve the odds of solidifying change and realizing the benefits of transformation.

  • So when we hear about transformation what does that actually mean?
    • Transforming how the business works? Process improvement?
    • Transforming how we develop software? New methods, processes, tools?
    • Transforming how we spend money? Better ROI, some magic formula for better ROI?
    • Woody doesn't say. It's just¬†transformation.
  • What are the profound questions?
    • For the business, a few profound¬†questions of a time cost of money project¬†are likely
      • When will we be done?
      • Will we show up on the needed date with the needed Features?

Control and Certainty about What?

  • There is no such thing as certainty on projects - this is a¬†false argument, had been a false argument since man started building things, anything, not just software.
    • Projects are uncertain. Uncertanity creates risk.
    • Uncertainty come in two¬†types and these two types of uncertainty¬†are always present on projects
      • Reducible uncertainty - Epistemic uncertainty, which can be handled with margin and redundancy
      • Irreducible uncertainty - Aleatory uncertainty, which can ONLY be handled with¬†margin
    • Uncertainty is the source¬†risk. Risk does not exist in the absence of uncertainty.¬†
      • Risk Managment is How Adults Manage Projects - Tim Lister
      • Risk management requires making estimates of the probability of occurrence, the statistical¬†behaviour of underlying processes, the probability of the impact of the risk if it were to come true and become an issue, the probability¬†of the residual risk even after the actual risk has been mitigated

If you're not managing risk, if you're not making estimates about these risk, you're not managing the project as an adult

 Control our Urge to Control Things

  • Managing the spend of other people's money, while producing value in exchange for that money means having ¬†control to some degree of that spend process.¬†
    • Management is a verb
    • Management is a closed loop process
    • Close loop process makes use of¬†control to keep the process (development of software) moving toward the target
  • Without control, the project is Open Loop
    • Open Loop control doesn't use feedback to take corrective actions
    • Not estimating is Open Loop control. Another No Estimates advocate claims NE is closed loop control. I suspect he didn't attend a Process Control Systems class, nor has any understanding of control system loops.

If the types of decisions we make requires estimates, then are there better types of decisions?

  • This is typical question like¬†when did you stop beating your wife Senator? It's a question designed to have no answer but rather make some unsubstantiated statement.¬†
  • Not sure there are¬†types of decisions¬†unless there are decisions in the¬†absence¬†of uncertainty and decisions in the¬†presence of uncertainty
    • If there is no uncertainty, making a decision is easy, no need to estimate. It's obvious what to do, obvious the outcome.¬†
    • Never seen a project where there is no uncertainty. Even production lines have uncertainties¬†during the day.

If you accept that project have uncertainty, then making decisions in the presence of this uncertainty requires you estimate the impact of that decisions. #NoEstimates has yet to state how, in the presence of uncertainty, that a decision can be made with NO Estimates. Only that they are exploring for ways to to this. Been exploring for going on 4 years now, seems to have found nothing. Which would support the notion that the microeconomics of decision making is still in place and any decisions in the presence of uncertainty requires making an estimate.

The Fear of Losing Control is a Big Barrier to Change. Control is Illusion. Fear is Real

  • ¬†This is one of those platitude statements Woody love to make.
    • Would he say that about driving his car?
    • Would he say that about skiing in the back bowls of Vail?
    • Would he say that about his 401(k) investment plan?
    • How about the cost budget for the room addition to his house?
    • Closed loop control is¬†control¬†the in the presence of emerging drivers.
    • Open loop control is Not control from external drivers, but manual change.

Just another platitude without any basis in principles of closed loop business and technical management

The cycle of non-improvement

  • The cycle of¬†estimate, work, estimates off, requirements unclear, invest in better estimates and requirements is labelled as a cycle of¬†non-improvement.¬†
    • No root cause for this behavior, just a statement of bad behaviour
    • Without root cause, only the symptom is observed
    • Without root cause, any suggestion of a corrective action -¬†no estimates - has no credibility, since the problem has not been identified but the solution is proposed.
    • Any proposed solution to¬†stop doing something requires direct evidence that¬†not estimating will improve requirements fidelity and improve the probability of delivering the needed software as needed.

There is no evidence that No estimates improves anything for those paying for the software development. This is a consistent issue with the conjecture that No Estimates fixes problems, without idnetifying the root cause of the problem, testing the hypothesis that No Estimates fixies the problem, and that this fix can be syndicated beyound the personal ancedote of the orginal conjetcure

What is an Estimate?

This question has a simple answer. It is not a Guess. It is not a promise. This question and the answers used by No Estimates advocates is used to manipulate the situation. Bad Managers use estimates as promises. Those with no experience, skill, or knowledge of estimating consider estimates as Guess's. Both are wrong, both are behaving as if they are in a Dilbert carton, following the script of a dysfunctional set of characters.

There endless numbers of books, papers, tools, classes on how to estimate software projects. These have all been provided in this blog before and can be found again. But here's a starting place - Estimating Software Intensive Systems. Read this and you'll have the start of all you need to break the cycle of uniformed, unsubstantiated states about what is an estimate, how are they made, and how can they be used to make decisions in the presence of uncertainty

Most of the things that matter can't be measured

  • Matter to whom?¬†
    • It must matter to those paying
    • For those paying, measuring is a critical success factor for determining of the money is returning the expected value at the expected time
    • Without asking and answering that question Woody's quote has no basis of applicability

Let's establish a baseline here. We're writing software for money, usually other people's money. In this context - a business context, Lord Kelvin has good advice for us. Writing software for money is not about the self-actualization of the individuals on the team. That may an outcome, but those paying ae not paying to improve the staff's psychological wellbeing.

When you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind. ‚ĶIt may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the stage of science. -¬†Lord Kelvin (1824‚ÄĒ1907)

 So what is the quest of the advocates of No Estimates? It's not actually clear. 

  • Improve the probability of success of project work? Can't see how that can be, since making decisions in the presence of uncertainty - which appears on all projects - requires we make estimates about the outcomes of those decisions.
  • Reduce the work load on the developers of software products or services? Perhaps, but that leaves open the need to have some probabilistic understanding of where the project is going in the presence of uncertainty to someone else.¬†
  • Reduce or remove the¬†dysfunction¬†of managers in making decisions in the presence of uncertainty? Certainty not, since that uncertainty is present whether you estimate it's impacts or not. Not Estimating does not remove the dysfunction of humans.

I can only conjecture that the purpose of Not Estimating is to return control of the work processes to those doing the work by removing the decision making processes from those owning the money. It's the anarchistic approach to software development. 

I, the one providing the labor in exchange for payment, am the one who will be telling you, the paying, when I'll be done, how much it will cost when I'm done, and what you'll be getting for that time and money. I am the one in charge of the effort to spend your money.

 

 

Related articles Risk Management is How Adults Manage Projects Estimating is Risk Management Herding Cats: Book of the Month IT Risk Management Making Decisions in the Presence of Uncertainty Intellectual Honesty of Managing in the Presence of Uncertainty Herding Cats: Making Decisions in the Presence of Uncertainty Herding Cats: Connecting Project Benefits to Business Strategy for Success Estimating and Making Decisions in Presence of Uncertainty Your Project Needs a Budget and Other Things
Categories: Project Management

Quote of the Day

Sat, 09/17/2016 - 09:53

Screen Shot 2016-09-15 at 9.49.52 PM

While this quote appears inverted in our self-centered world, the expert has eliminated the nonsensical, naive, amateur, simple minded options and narrowed the choices based principles, practices, and processes of her profession. It is trivially easy to assert I'm exploring  new ways of doing things when there is no bounding governance principles to guide your exploration.  If the exploration takes place in a de minimis world, the options are boundless. 

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Herding Cats: Connecting Project Benefits to Business Strategy for Success Herding Cats: Estimating on Non-Trivial Software Projects
Categories: Project Management

Book of the Month

Fri, 09/16/2016 - 20:12

SAFeThe SAFe Reference Guide is out.

The website has most everything you need, but it is hard to use and when printed in simplified mode doesn't contain the embedded pictures.

In our local Agile Meetup at Rally, Charles Bradley went through the 3 major methods for agile at scale - SAFe, LeSS, and Nexus

This book is a very useful even if you're not using SAFe, there is invaluable content in the book, including many pages on estimating.

As well as this book, at the Agile Meetup Charles provided a link to an Agility Guide and the site EB Management with lots of resources on Empirical Management

So get the book SAFe , it's the latest in how to manage software development At Scale. LeSS has similar advice, Nexus not so more, you have to attend their classes.

Categories: Project Management

Quote of the Day

Thu, 09/15/2016 - 12:43

Thought interferes with the probability of events, and in the long run therefore, with entropy - David L. Waston (1930)

All project work is probabilistic, driven by underlying uncertainties, both reducible and irreducible. Willing an outcome in the presence of these uncertainties does not make is so. The only useful process to manage in the presence of uncertainty is to estimate the outcome of any decisions made by the participants of the processes by which the project operates

Related articles Managing in the Presence of Uncertainty Estimating Processes in Support of Economic Analysis Herding Cats: Book of the Month Herding Cats: Making Decisions in the Presence of Uncertainty Making Decisions In The Presence of Uncertainty Herding Cats: The Problems with Schedules
Categories: Project Management

Quote of the Day

Wed, 09/14/2016 - 12:39

It is probably dangerous to use this theory of information in fields for which it was not designed, but I think the danger will not keep people from using it - J. C. R. Lickider (1950)

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Trust But Verify

Wed, 09/14/2016 - 01:10

The mantra of Agile is¬†Trust the team. In some domains, that is an admirable goal. In other domains it's a na√Įve path to disaster. I work in the latter domain, on mission critical, sometimes¬†national asset¬†programs, but always mission critical - can't fail, must work, must provide proper information when called upon to do so.

When we are called on to perform a Root Cause Analysis of why the system failed to do what it was suppose to be, we find the same thing that Dr. Bill Corcoran suggest is found on all root cause analysis processes.

An inescapable fact is that the competent investigation of every harmful event reveals that the causation of the harm includes the mistaken/ na√Įve/ unwarranted/ gullible/ imprudent trust and confidence in one or more erroneous/ untrustworthy theories, assumptions, standards, devices, procedures, processes, programs, people, institutions, agencies, contractors, and/or conditions. The functional alternatives include monitoring, curiosity, skepticism, and the ‚Äúquestioning attitude.‚ÄĚ

Here's some quotes to apply when you hear agile means trust of the team, why are you questioning our processes, our methods, our organizational models. (Thanks to Dr. Corcorn's news feed today):

  • You get what you inspect; not what you expect¬†- An old U.S. Navy proverb
  • Trust, but verify¬†- Quoted by President Ronald Reagan
  • A sucker is born every day -Attributed to P. T. Barnum
  • The world abounds in unrocked boats with holes just above the current waterline -Salty Wisdom
  • Faith is believing for sure what ain‚Äôt so¬†-Mark Twain
  • In God we trust; all others please furnish evidence - Unknown for now

So saying it again for clarity - you can't make a decsion in the presence of uncertaty without estimating the outcome of that decision. When you do, be preared to conduct a Root Cause Analysis of why your project went in the ditch. Trust is necessary but far from sufficient when spending other people's money on non-trivial development efforts.

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Root Cause Analysis Estimating and Making Decisions in Presence of Uncertainty Are Estimates Really The Smell of Dysfunction? Making Conjectures Without Testable Outcomes Good Project and Bad Project Estimates
Categories: Project Management

Trust But Verify

Wed, 09/14/2016 - 01:10

The mantra of Agile is¬†Trust the team. In some domains, that is an admirable goal. In other domains it's a na√Įve path to disaster. I work in the latter domain, on mission critical, sometimes¬†national asset¬†programs, but always mission critical - can't fail, must work, must provide proper information when called upon to do so.

When we are called on to perform a Root Cause Analysis of why the system failed to do what it was suppose to be, we find the same thing that Dr. Bill Corcoran suggest is found on all root cause analysis processes.

An inescapable fact is that the competent investigation of every harmful event reveals that the causation of the harm includes the mistaken/ na√Įve/ unwarranted/ gullible/ imprudent trust and confidence in one or more erroneous/ untrustworthy theories, assumptions, standards, devices, procedures, processes, programs, people, institutions, agencies, contractors, and/or conditions. The functional alternatives include monitoring, curiosity, skepticism, and the ‚Äúquestioning attitude.‚ÄĚ

Here's some quotes to apply when you hear agile means trust of the team, why are you questioning our processes, our methods, our organizational models. (Thanks to Dr. Corcorn's news feed today):

  • You get what you inspect; not what you expect¬†- An old U.S. Navy proverb
  • Trust, but verify¬†- Quoted by President Ronald Reagan
  • A sucker is born every day -Attributed to P. T. Barnum
  • The world abounds in unrocked boats with holes just above the current waterline -Salty Wisdom
  • Faith is believing for sure what ain‚Äôt so¬†-Mark Twain
  • In God we trust; all others please furnish evidence - Unknown for now

So saying it again for clarity - you can't make a decsion in the presence of uncertaty without estimating the outcome of that decision. When you do, be preared to conduct a Root Cause Analysis of why your project went in the ditch. Trust is necessary but far from sufficient when spending other people's money on non-trivial development efforts.

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Root Cause Analysis Estimating and Making Decisions in Presence of Uncertainty Are Estimates Really The Smell of Dysfunction? Making Conjectures Without Testable Outcomes Good Project and Bad Project Estimates
Categories: Project Management

Quote of the Day

Mon, 09/12/2016 - 12:25

The perfect symmetry of the whole apparatus - the wire in the middle, the two phones at the ends and the two gossips at the ends of the telephones - may be very fascinating to a mere mathematician - James Clark Maxwell (1878)

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Single Factor Analysis and Reduction Reasoning

Sun, 09/11/2016 - 22:14

Much of the discussion around project management processes, especially around agile, and most especially around the misconceptions of Estimating as espoused by the #NoEstimates advocates, starts with the misuse of reductive reasons based on single factor analysis.

Here's how it goes.

  • Single Factor Analysis -¬†is a statistical method used to describe variability among observed, correlated variables in terms of a potentially lower number of unobserved variables called factors.¬†
    • The first assessment using SFA is¬†Estimates are the smell of dysfunction. There may be a¬†correlation, but causation has yet to be determined.
    • There are others -¬† estimates are evil,¬†estimates are commitments, and similar conjectures around a claim that somehow estimates, the making of estimates, and the use of estimates is somehow -¬†unstated how by the way - are the cause of problems in the software development domain.
  • Reductionism - is about connections between phenomena, or theories, "reducing" one to another, usually considered simpler or more basic
    • This is seen in the quest to reduce complex issues to simple issues,
    • Or worse make the claim that¬†non-simple systems are somehow undesirable and¬†if we only simplified¬†everything the problems we see in our¬†real world systems would somehow be removed.

When we see these two concepts used together we get things like as the cartoon of the Reductionist view of a single concept - If you did it this way, you'd be from 3X to 10X faster.

 

So here's the problem and the solution. Complex systems are part of the solution to all complex problems. Anyone claim complex problems can be solved with simple systems, needs to have a testable working system, in that complex problem space. I work in a complex problem space - literally space flight, aircraft flight, the ground systems that enable those systems to Fly. As well as biopharma, electric utilities (nuclear and conventional fired), complex enterprise IT systems (dozens to many dozens of interacting systems).

When you hear a simple and many time simple-minded solution to a complex problem - Applying No Estimates will remove the dysfunction on software projects (this is the ontological inverse of the statement estimates are the smell of dysfunction).  We can be reminded by H L Menken's quote:

For every complex problem there is an answer that is clear, simple, and wrong.

 

 

Categories: Project Management

Quote of the Day - Trust But Verify

Sat, 09/10/2016 - 20:16

Crede Sed Proba

Trust is a core attribute of Agile Software Development. But any non-trivial business venture will also what to verify that to outcomes of the work effort are going to meet the needs of those paying, at the time those capabilities are needed, for the expected cost.

When you hear agile is all about trust, make sure you have a appropriate verification process in place as well. This is called governance where we work. It's risk management and Risk Management is ow Adults Management Projects (Tim Lister).

Many want us to trust but any credible governance process requires a verification process. With that verification, that trust cannot be trusted.

Categories: Project Management

Quote of the Day

Sat, 09/10/2016 - 03:30

What I cannot create, I do not understand -  Richard Feynman, from his blackboard at the time of his death

Feynman spoke at our Society of Physics Students at UC Irvine. His was the penultimate teacher of all things physics

Categories: Project Management

Quote of the Day

Thu, 09/08/2016 - 16:00

I forgot something important that you must remember until you go six feet under‚Ķ. There are only two kinds of people in the whole wide world, grifters and suckers‚Ķ. [With suckers,] let their stupid brains stay asleep in their chump world. Keep your own brain honed to razor sharpness in the secret world of con. ‚ÄďIceberg Slim

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes Deadlines Always Matter
Categories: Project Management

The Origins of Scrum and Empirical Closed Loop Control

Wed, 09/07/2016 - 16:00

I came across a couple of interesting  tweets over the weekend

(Scrum is) more defined rather than empirical process. Agile in name only. scrum, not agile. not as it was prior to scrum. lost art.
Scrum is prescriptive and defined rather than empirical. it seeks to be guidance for work it's too far removed from to understand.

 This took me back since Scrum is derived from an empirical closed loop control system developed in the USAF by Col. John Boyd. There's a recent paper "What Lessons Can the Agile Community Learn from A Maverick Fighter Pilot?" by  Steve Adolph. I was puzzled by the tweet, asked why that was the opinion, but didn't get a response. As a start, here's a resource for Col. Boyds papers.

Ooda_figure11

No need to explain why OODA is the basis of Scrum, here's a much better post - OODA: The Mindset of Scrum. 

The OODA concept is very simple:

  • Observation: the collection of data by means of the senses. Measuring progress in units of measure meaningful to the decision makers.
  • Orientation: the analysis and synthesis of data to form one‚Äôs current perspective. Comparing this data to what is expected at this point in time.
  • Decision: the determination of a course of action based on that current perspective. With the variance¬†between plan and actual, what are we going to do to get back on plan?
  • Action: the physical playing-out of the¬†decision. Take the needed action to¬†get back on target.

Boyd's presentation "A Discourse on Winning and Losing Introducing core ideas & themes Of Boyd‚Äôs ‚ÄėTheory of intellectual evolution and growth,"was presented at ‚ÄúPatterns of Conflict‚ÄĚ at the U.S. Marine Amphibious Warfare School in June 1980. Here's some more Boyd from the Boyd Library. A good book on Boyd is Boyd: The Fighter Pilot Who Changed the Art of War

In our Software Intensive System of Systems domain, this is the definition of Agile we use from the now-Secretary of Defense Dr. Carter

Screen Shot 2016-09-06 at 3.40.15 PM

So when we hear anything about the current state of Agile or even that Scrum is NOT empirical and needs to be replaced, ask what new process is being suggested that will meet Dr. Carter's definition?

…the OODA loop sketch and related insights represent an evolving, open-ended, far from equilibrium process of self-organization, emergence and natural selection. This is a good starting point for not only Scrum and other agile methods, that can be used to test the validity of any method suggested to replace or augment the current agile software development processes.

And of course:

Assessing the outcomes of the feedforward and feedback loops is the basis of all Closed Loop control system. (See link below on Closed Loop Control). Making decisions in the presence of this emerging uncertainty requires making estimates of the impacts or outcomes of any decision. There's simply no way out of this principle when making decisions in an emerging domain with uncertainty (reducible or irreducible). Anyone suggesting otherwise either hasn't the knowledge of closed loop control systems or is try to sell you something that violates the principles of closed loop control, microeconomics of decision making, or managerial finance. Don't buy it. Learn to manage in the presence of uncertainty using principles not persoanl ancedotes.

Related articles Doing the Math Closed Loop Control Herding Cats: Invoking "Laws" Without a Domain or Context Hope is not a Strategy Your Project Needs a Budget and Other Things How to Avoid the "Yesterday's Weather" Estimating Problem Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Open Loop Thinking v. Close Loop Thinking
Categories: Project Management

Making Decisions in the Presence of Uncertainty

Tue, 09/06/2016 - 16:49

All project work is uncertain. This uncertainty comes in two forms - Aleatory and Epistemic. Aleatory Uncertainty is irreducible, Epistemic uncertainty is reducible. More can be found on this in Both Aleatory and Epistemic Uncertainty Create Risk. 

But now what to do about it. Here's a collection of papers that has served me well in defining the processes needed to make decisions in the presence of uncertainty when managing projects using other people's money:

So when you hear about making decisions in the presence of uncertainty without estimating the outcomes of those decisions, you'll have a basis of knowledge to realize that is completely bogus, a violation of the principles of microeconomics, and a violation of the principles of managerial finance. 

 

Categories: Project Management

Estimating on Non-Trivial Software Projects

Sat, 09/03/2016 - 18:17

A nice conversation on twitter about estimates on software brought up the topic of estimates as commitments. The #NoEstimates advocates see estimates as making commitments. Yes, commitments are made when we estimate. But that commitment is not a promise. A Promise is a guarantee, with 100% confidence it will be net. Our wedding vows are a promise to each other. A commitment must have a probabilistic confidence. Just for the reference, 

A commitment must have a probabilistic confidence. Just for the reference, a commitment is the state or quality of being dedicated to a cause, activity, etc.
"the company's commitment to quality
or an engagement or obligation that restricts freedom of action. Take for example Boulder's commitment for 100% recycling of consumer products inside the city limits. Is that commitment are guarantee every single consumer waste product collected at our curb will be recycled? That is a tall order and not likely to ever be the case. 

I have an 80% confidence (an estimate) I can deliver what you need on or before September 15 (an estimate), at or below $15,000.oo (an estimate) with a 15% error band (an estimate). 

Screen Shot 2016-09-03 at 8.11.19 AM

The misuse of that commitment is a real problem in all domains. But that's got NOTHING to do with the need for the estimate and EVERYTHING to do with bad management. No Estimating isn't going to make the need for estimates go away or fix bad management, no matter how many Dilbert cartoons are used to illustrate that.

In any non-trivial domain, there are larger business processes in play that is looking for value in exchange for money. When business people think about that exchange, they think about some agreement between those paying for the value and those providing the value . This agreement can be formal or it can be informal. But that agreement is always in place. 

In our domain of software intensive system of systems, we have formal agreements at the top of the engagement and less formal agreements lower down based on agile software development processes. Here's how it is done where we work.

This is not a unique domain, once the formality of dealing with a sovereign is removed. Corporate governance has similar frameworks for managing the stockholders or stakeholders money.   For specific activities in our domain, there are other work efforts needed to estimate the outcomes, the cost of those outcomes and when those outcomes will be delivered. This formality is not likely needed for anything other than the largest corporate IT projects. But the principles are the same, it's the processes and practices that are different.  But the 5 Immutable Principles of project success are always in place no matter the size of the project beyond de minimis projects. So when you hear Estimates can't be done, estimates are a waste, estimates are the smell of dysfunction, estimates are evil, this may actually be true for those working on de minimis projects. Projects where those paying for the work have NO concern about how much it will cost to produce the value, NO concern when that value will be available for use, NO concern if the capabilities that produce that value actually work and actually do produce the value for the needed cost on the needed date.   In those conditions, #NoEstimates advocates are right. Estimates are not needed. For those of us working outside the de minimis project domains, they are.   Related articles Capability Maturity Levels and Implications on Software Estimating Are Estimates Really The Smell of Dysfunction? Herding Cats: Connecting Project Benefits to Business Strategy for Success Why Guessing is not Estimating and Estimating is not Guessing Software Estimating for Non Trival Projects Herding Cats: Range of Domains in Sofwtare Development Essential Reading List for Managing Other People's Money Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

The Myth That Research Can't Be Managed

Thu, 09/01/2016 - 17:20

There is a popular myth that ...

some software development projects are research and aren't subject to normal business management processes

I'm here to tell you this ain't true. I've managed several pure and applied research projects in my life, including my graduate research. This experience includes bio-pharma, engineering development, and physics research projects - all software intensive.

Research projects start with a hypothesis,

A Hypothesis is a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.

This is the target of the research. The why of the effort. Without this hypothesis it's not research, it's wandering around looking under rocks for something. Something that you may not even recognize is what you're looking for.

So don't fall for the claim that I can't know when I'll be done, how much it will cost, or what Done looks like because we're working on innovation or PURE research.

Those who work on research projects and work on innovative design projects have a goal - a hypothesis. They wrote that down before they started. It's in their grant proposal. It's in their funding request. You self-funding, you'd better write that done as well, or your money is going to be wasted looking under rocks for that magic item that you don't even know will sell. 

Related articles Complex Project Management The Fallacy of the Planning Fallacy Qualitative Risk Management and Quantitative Risk Management What Happened to our Basic Math Skills? Mr. Franklin's Advice
Categories: Project Management