Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
It’s quite common for a team to have a bit of unfinished work at the end of an agile sprint or iteration. Ideally, a team would finish every item on its sprint backlog every sprint. But, for a variety of reasons, that isn’t always the case. This leads to a couple of questions I’ll address here:
When a product backlog item is not finished at the end of an agile sprint, it should first technically be put back onto the product backlog. Work never moves automatically from one sprint to the next.
I’m perhaps being overly pedantic here, but the point is that each sprint begins with the product owner making a conscious, deliberate decision about what the team should work on. If there’s unfinished work from the prior sprint, it’s very likely the product owner will want the team to finish that work in the new sprint. But, the product owner should still make an actual decision to do that.
(As a note, let me also say that I’m not suggesting you make extra work for yourself if you are using a tool that would make this difficult. All I’m saying is that work does not automatically move into the next sprint. The product owner must decide if the work is still valuable.)Splitting or Carrying the Item Forward
When a product backlog is unfinished, teams are often torn on whether they should leave the product backlog item description alone (even though part of that functionality might be complete) or rewrite it to describe just the missing piece.
For example, consider a team building typical print preview functionality in a desktop application. If the team builds everything but the ability to page backward through the pages, it can either carry forward the original user story or write a smaller, replacement story like, “As a user, I can page backward while on the print preview screen.”
I recommend that if you are going to finish the story in the coming sprint, just leave it alone. Don’t rewrite it. Everyone is used to it as it’s written. Assuming it’s still of value to the product owner, it moves forward exactly as written.
However, if the remaining work will be deferred to a later sprint, write a new story that describes just that subset of functionality. IMAGE QUOTE: If you’ll finish in the next sprint, don’t rewrite the story.Does the Team Earn Velocity Credit
I always want to take a conservative stance towards calculating velocity. This means that a team should only take credit for work that is truly complete.
So, in the case the unfinished product backlog item is rolling forward to be completed in the next agile sprint, do not take any velocity credit. The team instead earns all credit in the sprint in which the work is finished. Since I advocate working with average velocities anyway, this averages out and avoids the risk of overstating velocity.
But when the team splits the story and puts the remaining subset onto the product backlog to be done in the future, go ahead and take some amount of velocity credit. The team will need to do its best to estimate a fair number of points for the subset of work that was completed. And, even though it did not finish the entire original story, the team may give itself all the original points if it feels the story was larger than originally planned. I’d be reluctant to do that very often. But, it is OK.Always Look for a Root Cause
Finally, whenever work is unfinished at the end of an agile sprint, the team should take time in the retrospective to consider whether it was caused by something preventable. Sometimes, it’s just bad luck or bad timing, such as a team member becoming ill or a problem being found late in the sprint that could not have been found earlier. But, it’s always worth considering whether there is a root cause and whether something can be done to prevent it from affecting future sprints.What Do You Do?
How do you handle work left at the end of the sprint? And have you found good ways of minimizing how often you have work left unfinished at the end?
These new books are worth your consideration. My 30 reading tips for October! (plus 5 extra)
Phillip Armour has a classic article in CACM titled "Ten Unmyths of Project Estimation," Communications of the ACM (CACM), November 2002, Vol 45, No 11. Several of these Unmyths are applicable to the current #NoEstimates concept. Much of the misinformation about how estimating is the smell of dysfunction can be traced to these unmyths.
Mythology is not a lie ... it is metaphorical. It has been well said that mythology is the penultimate truth - Joseph Campbell,¬†The Power of Myth
Using Campbell's quote, myths are not untrue. They are an essential truth, but wrapped in anecdotes that are not literally¬†true. In our software development domain a myth is a truth that seems to be untrue. This is Armour's origin of the¬†unmyth.¬†
The unmyth is something that seems to be true but is actually false.
Let's look at the three core conjectures of the #Noestimates paradigm:
The Accuracy Myth
Estimates are not numeric values. they are probability distributions. If the Probability Distribution below represents the probability of the duration of a project, there is a finite minim - some time where the project cannot be completed in less time.
There is the highest probability, or the¬†Most¬†Likely¬†duration for the project. This is the Mode of the distribution. There is a mid point in the distribution, the Median. This ¬†is the value between the highest and the lowest possible completion times. Then there ¬†is the Mean of the distribution. This is the¬†average of all the possible completion times. And of course¬†The Flaw of¬†Averages¬†is in effect for any decisions being made on this average value ‚Ä†
‚ÄúIt is moronic to predict without first establishing an error rate for a prediction and keeping track of one‚Äôs past record of accuracy‚ÄĚ¬†‚ÄĒ Nassim Nicholas Taleb, Fooled By Randomness
If we want to answer the question¬†What is the¬†probability¬†of¬†completing¬†ON OR BEFORE a specific date, we can look at the Cumulative Distribution Function (CDF) of the Probability Distribution Function (PDF). In the chart below the PDF has the earliest finish in mid-September 2014 and the latest finish early November 2014.
The 50% probability is 23 September 2014. In most of our work, we seek an 80% confidence level of completing ON OR BEFORE¬†the need date.
The project then MUST have schedule, cost, and technical margin to protect that probabilistic date.
How much margin is another topic.
But projects without margin are late, over budget, and likely don't work on day one. Can't be complaining about poor project performance if you don't have margin, risk management, and a plan for managing both as well as the technical processes.
So what we need is not Accurate estimates, we need Useful estimates. The usefulness of the estimate is the degree to which it helps make optimal business decisions. The process of estimating is¬†Buying Information. The¬†Value of the estimates, like all value is determined by the cost to obtain that information. The value of the estimate of the¬†opportunity cost,¬†which is the different between the business decision made with the estimate and the business decision made without the estimate. ‚Ä°
Anyone suggesting that simple serial work streams can accurately forecast - ¬†an estimate of the completion time - MUST read¬†Forecasting and Simulating Software Development¬†Projects: Effective¬†Modeling of Kanban & Scrum Projects using Monte Carlo¬†Simulation, Troy Magennis.
In this book are the answers to all the questions those in the #NoEstimates camp say can't be answered.
The Accuracy Answer
But remember, making estimates is how you make business decisions with¬†opportunity costs.¬†Those opportunity costs are the basis of Microeconomics and Managerial Finance.¬†
Cone of Uncertainty and Accuracy of Estimating
There is a popular myth that the¬†Cone of¬†Uncertainty¬†prevents us from making accurate estimates. We now know we need useful estimates, but those are not prevented by in the cone of uncertainty. Here's the guidance we use on our Software Intensive Systems projects.
Finally in the estimate accuracy discussion comes the¬†cost estimate.¬†The chart below shows how cost is driven by the probabilistic elements of the project. Which brings us back to the fundamental principle that¬†all¬†project¬†work is¬†probabilistic. Modeling the cost, schedule, and probability of technical success is mandatory in any non-trivial project. By non-trivial I mean a de minimis project, one that if we're off by a lot it doesn't really matter to those paying.
The Commitment Unmyth
So now to the big bug a boo of #NoEstimates. Estimates are evil, because they are taken as commitments by management.¬†They're taken as commitment by Bad Management, uninformed management., management that was asleep in the High School Probability and Statistics class, management that claims to have a Business degree, but never took the Business Statistics class.¬†
So let's clear something up,
Commitment is how Business Works
Here's an example taken directly from¬†‚Ä°¬†
Estimation is a technical activity of assembling technical information about a specific situation to create hypothetical scenarios that (we hope) support a business decision. Making a commitment based on these scenarios is a business function.
The Technical ‚ÄúEstimation‚ÄĚ decisions include:
This kind of information allows us to calculate the amount of time we should allow to get there.
The Business ‚ÄúCommitment‚ÄĚ and Risk decisions include:
These are the business consequences that determine how much risk we can afford to take.
Along with these of course is the risk associated with the uncertainty in the decisions. So estimating is also Risk Management and Risk Management is management in the presence of uncertainty. And the now familiar presentation from this blog.
Managing in the presence of uncertainty from Glen Alleman
Risk Management is how Adults manage projects - Tim Lister. Risk management is managing in the presence of uncertainty. All project work is probabilistic and creates uncertainty. Making decisions in the presence of uncertainty requires - mandates actually - making estimates (otherwise you're guess your pulling numbers from the rectal database). ¬†So ¬†if we're going to have an Adult conversation about managing in the presence of uncertainty, it's going to be around estimating. Making estimates. improving estimates, making estimates valuable to the decision makers.¬†
Estimates are how business works - exploring for alternatives means willfully ignoring the needs of business. Proceed at your own risk
‚Ä† This average notion is common in the No estimates community. Take all the past stories or story points and find the average value and use that for the future values. That is a serious error in statistical thinking, since without the variance being acceptable, that average can be wildly off form the actual future outcomes of the project
‚Ä° Unmythology and the Science of Estimation, Corvus International, Inc., Chicago Software Process Improvement Network, C-Spin, October 23, 2013Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
On October 1, 2010, I started my life as a self-employed entrepreneur. My full-color high-quality #Workout book costs ONLY EUR 15.00 excluding VAT (normally EUR 27.50) for 24 hours on October 1.
As far as hypothesis are concerned, let no one expect anything certain from astronomy, which cannot furnish it, lest he accept as the truth ideas conceived for another purpose, and depart from this study a greater fool than when he entered it. Andreas¬†Osiander's (editor) preface to¬†De Revolutionbus, Copernicus, in¬†To Explain the World: The¬†Discovery¬† of¬†Modern Science, Steven Weinberg
In the realm of project, product, and business management we come across nearly endless¬†ideas conjecturing to solve some problem or another.
Replace the word Astronomy with what ever word those conjecturing a solution will fix some unnamed problem.
From removing the¬†smell of dysfunction, to increasing productivity by 10 times, to removing the need to have any governance frameworks, to making decisions in the presence of uncertainty without the need to know the impacts of those decisions.
In the absence of any hypothesis by which to test those conjectures,¬†leaving¬†a¬†greater¬†fool than when entering¬†is the likely result.¬†In the absence of a testable hypothesis, any conjecture is an unsubstantiated anecdotal opinion.
An anecdote is a sample of one from an unknown population
And that makes those conjectures doubly useless, because they can not only not be tested, they are likely applicable only the those making the conjectures. ¬†¬†
If we are ever to discover new and innovative ways to increase the probability of success for our project work, we need to move far away from conjecture, anecdote, and untestable ideas and toward evidence based assessment of the problem, the proposed solutions and the evidence that the propsed correction will in fact result in improvement.
One Final Note
As a first year Grad student in Physics I learned a critical concept that is missing from much of the conversation around process improvement. When an idea is put forward in the science and engineering world, the very first thing is to do a literature search.
Without some way to assess the credibility of any idea, either through replication, assessment against a baseline (governance framework, accounting rules, regulations), the idea is just an opinion. And like Daniel Moynihan says:
Everyone is entitled¬†to his own opinion, but not his own facts.¬†
and of course my favorite
Again and again and again ‚ÄĒ what are the facts? Shun wishful thinking, ignore divine revelation, forget what "the stars foretell," avoid opinion, care not what the neighbors think, never mind the unguessable "verdict of history" ‚ÄĒ what are the facts, and to how many decimal places?¬†You pilot always into an unknown future; facts are your single clue. Get the facts! -¬†Robert Heinlein (1978)Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Over the past few months, I've read a few books on marketing. But I've also taken a handful of video training courses on marketing and have been listening to some enjoyable podcasts on the subject. Back when I was in college, we really did look down on the people majoring in marketing. This was the 1980s. And it seemed like they often chose that major because it didn't require any math at all. And to an outsider, the main skills they appeared to need were a firm handshake and a good golf game.
A lot has changed since then and I've become fascinated with marketing because of all the data that's available to marketers today. It appeals to my analytical side. So while consuming all this content on marketing, I noticed something. Individuals whom I thought would be competitors in that space were often endorsing one another.Scarcity and Abundance Mindsets
And I realized this no longer happens as often as it should within the community of Scrum trainers and coaches. Too many professional Scrum trainers and coaches have shifted into a scarcity mindset. Each trainer then acts as though any win by another trainer is a loss for his or her own business. Their thinking implies there are only so many clients in the world and clients are to be divvied up like slices of a pie.
But what if that client someone else trains is then wildly successful and tells 10 or 100 or 1,000 other people? The pie grows and it can very likely grow large enough that everyone wins. This is an abundance mindset rather than a scarcity mindset.The Founding of the Scrum Alliance
When Ken Schwaber, Esther Derby and I co-founded the Scrum Alliance, part of the plan was a credibility transfer from ourselves and the organization to other trainers. We knew that for Scrum to succeed in the world, it needed a lot more training and coaching than the three of us could or wanted to provide. And, approaching it with an abundance mindset, we knew the need for Scrum training and coaching would grow well beyond what the three of us could provide.
And that brings me to today: Many of us who make our livings training and coaching Scrum (or agile in general) seem to have reverted to a scarcity mindset. I'm generalizing, of course. There are some wonderful examples of people within the Scrum community who live an abundance mindset daily. I wonder though if it gets tough for them to continue doing so when many around them are doing the opposite.We Are Partners and Future Partners, Not Competitors
One of the marketing books I read made an interesting point. The author said he never refers to others in his space as "competitors." Instead, they are "partners" and "future partners." And this is indeed what I noticed while participating in video training and podcasts from these marketing experts. Even when some of them could have viewed themselves as competitors since they sold similar products and services, they knew that if I bought a product from one of them, it did not preclude me from buying a product from the others.
So, if you are a Scrum Alliance Certified Scrum Trainer or Coach, or a Scrum.org Professional Scrum Trainer, please know that I consider you a partner or future partner. You aren't my competition, and I'm not yours. Our competition is crappy products and all the forces of nature that conspire to make teams build crappy software.
And, if you're reading my blog looking for a training course, I hope you'll consider mine. But, it's a big world and I may not be in your area at the time you want training. In that case, I sincerely hope you'll consider training, coaching or at least reading the blogs of my "partners and future partners."
Finally, CSTs, CSCs and PSTs (my partners and future partners!): I encourage you to leave links to training pages, bios, blogs, etc. below.
As always, I look forward to everyone's thoughts in the comments below.
There's a common notion in some agile circles the projects aren't the right vehicle for developing products. This is usually expressed by Agile Coaches. As a business manager, applying Agile to develop products ¬†as well as delivering Operational Services based on those products, projects are how we account for the expenditures of those outcomes, manage the resources and coordinate the needed resources to produce products as planned.
In our software product business, we use both a Product Manager and a Project Manager. These roles are separate and at the same time overlapping.
Product Managers focus on Markets. What features are the market segments demanding? What features Must Ship and what featues can we drop? What is the Sales impacts of any slipped dates?
Project Managers are inward focused to the resource allocation and management of the development teams. How can we get the work done to meet the market demand? When can we ship the product to maintain the sales forecast?
In very small companies and startups these roles are usually performed by the same person.
Once we move beyond the sole proprietor and his friends, separation of concerns takes over. These roles become distinct.
Products are about What and¬†Why. Projects are about Who,¬†How, When,¬†and Where. From Rudyard Kipling's Six Trusted Friends)
Product Management focuses on the overall product vision - usually documented in a Product Roadmap, showing the release cycles of capabilities and features as a function of time. Project Management is about logistics, schedule, planning, staffing, and work management to produce products in accordance with the Road Map.
When agile says it's¬†customer focused, this is true only when there is One customer for the Product, rather than a Market for the Product and that customer is on site. That'd not be a very robust product company if they had only one customer.¬†
When we hear Products are not Projects, ask in what domain, business size, and¬†value at risk is it possible not to separate these concerns between Products and Projects?Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Risk Management is How Adults Manage Projects - Tim Lister
Let's start with some background on Risk Management
Tim's quote sets the paradigm for managing the impediments to success in all our endeavors
It says volumes about project management and project failure. It also means that managing risk is managing in the presence of uncertainty. And managing in the presence of uncertainty means making estimates about the impacts of our decision on future outcomes. So you can invert the statement when you hear¬†we can make decisions in the absence of estimates.
Tim's update is titled¬†Risk Management is Project Management for Grownups.
For those interested in managing projects in the presence of uncertainty and the risk that uncertainty creates, here's a collection from the office library, in no particular order
Here's a summary at a recent meeting around decision making in the presence of risk
Earning value from risk (v4 full charts) from Glen Alleman
The popular notion that¬†Cynefin¬†can be applied in the software development domain as a way of discussing the problems involved in writing software for money is missing the profession of Systems Engineering. From Wikipedia Cynefin is...
The¬†framework¬†provides a typology of contexts that guides what sort of explanations or solutions might apply. It draws on research into¬†complex adaptive systems¬†theory, cognitive science, anthropology, and narrative patterns, as well as evolutionary psychology, to describe problems, situations, and systems.
While Cynefin uses the term Complexity and Complex Adaptive System, it is applied from the¬†observational¬†point of view. That is the system exists outside of our influence on the system to control its behavior - we are observers of the systems, not¬†engineers¬†of the¬†solutions¬†in the form of a¬†system that provides needed capabilities to solve a problem.
Read carefully the original paper on Cynefin¬†The New Dynamics of Strategy: Sense Making in a Complex and Complicated World¬†This post is NOT about those types of systems, but about the conjecture that the development of software is by its nature Chaotic. This argument is used by many in the agile world for avoid the¬†engineering¬†disciplines of¬†INCOSE style Systems¬†Engineering.¬†¬†
There are certainly¬†engineered systems that transform into complex adaptive systems with emergent behaviors that cause the system to fail. Example below. This is not likely to be the case when engineering principles are applied in the domains of Complex and Complicated.
A good starting point for the complex, complicated, and chaotic view of¬†engineered systems is¬†Complexity and Chaos -¬†State¬†of the Art: List of Works, Experts, Organizations,¬†Projects, Journals, Conferences, and Tools¬†There is a reference to Cynefin as organization modeling. While organizational modeling is important - I suspect Cynefin advocates would suggest the only important item - the¬†engineered aspects¬† of applying Systems Engineering to complex, complicated, and emergent systems is mandatory for any organization to¬†get the product out the door on time, on budget, and on specification.
For another view of the complex systems problem¬†Principles¬†of¬†Complex¬†Systems for Systems Engineering is a good place to start along with the resources from INCOSE and AIAA like¬†Complexity Primer for Systems Engineers,¬†Engineering Complex Systems,¬†Complex System Classification, and many others.
So Let's Look At the Agile Point of View
In the agile community it is popular to use the terms¬†complex, complexity, complicated, complex¬†adaptive¬†system¬†many times interchangeably and many times wrongly - to assert we can't possibly plan ahead,¬†know¬†what we're going to need, and establish a cost and schedule because the¬†systems¬†complex, and emergent.
These terms are many times overloaded with an agenda used to push a process or even a method. As well, in the agile community it is popular to claim we have no control over the system, so we must adapt to its emerging behavior. This is likely the case in one condition - the chaotic behaviors of Complex Adaptive Systems. But this is only the case when we fail to establish the basis for how the CAS was formed and what sub-systems are driving that behaviors, and most importantly what are the dynamics of the interfaces between those subsystems - the System of Systems architecture - that create the chaotic behaviors .¬†
It is highly unlikely those working in the agile community actually work on complex systems that evolve AND at the same time are¬†engineered at the lower levels to meet specific capabilities and resulting requirements of the system owner. They've simply let the work and the resulting outcomes¬†emerge¬†and become¬†Complex, Complicated,¬†and create¬†Complexity. They are¬†observers¬† of the outcomes, not¬†engineers of the outcomes.
Here's one example of an engineered system that actually did become a CAS because of poor efforts of the Systems Engineers. I worked on Class I and II sensor platforms. Eventually FCS was canceled for all the right reasons. But for small teams of agile developers the outcomes become¬†complex when the Systems Engineering processes are missing. Cynefin partitions beyond obvious¬†emerge¬†for the most part when Systems Engineering is missing.
First some definitions
One more item we need is the types of Complexity
And Now To The Point
When we hear complex, complexity, complex systems, complex adaptive system, pause to ask what kind of¬†complex are you talking about. What¬†Type of complex system. In what system are you applying the term¬†complex. Have you classified that system in a way that actually matches a real system. Don't take anyone saying¬†well the system is emerging and becoming too complex for us to manage Unless in fact that is the case after all the Systems Engineering activities have been exhausted. It's a cheap excuse for simply not doing the hard work of¬†engineering the outcomes.
It is common use the terms complex, complicated, and complexity interchanged. And software development is classified or mis-classified as one or the both or all three. It is also common to toss around these terms with not actual understanding of their meaning or application.
We need to move beyond buzz words. Words like¬†Systems Thinking.¬†Building software is part of a system. There are interacting parts that when assembled, produce an outcome. Hopefully a desired outcome. In the case of software the interacting parts are more than just the parts. Software has emergent properties. A Type 4 system, built from Type 1, 2, and 3 systems. With changes in time and uncertainty, modeling these systems requires stochastic processes. These processes depend on estimating behaviors as a starting point.¬†
The understanding that software development is an uncertain process (stochastic) is well known, starting in the 1980's  with COCOMO. Later models, like¬†Cone of Uncertainty made it clear that these uncertainties, themselves, evolve with time. The current predictive models based on stochastic processes include Monte Carlo Simulation of networks of activities, Real Options, and Bayesian Networks. Each is directly applicable to modeling software development projects.
 Software Engineering Economics, Barry Boehm, Prentice-Hall, 1981.Related articles Decision Analysis and Software Project Management Making Decisions in the Presence of Uncertainty Some More Background on Probability, Needed for Estimating Approximating for Improved Understanding The Microeconomics of a Project Driven Organization How to Avoid the "Yesterday's Weather" Estimating Problem Hope is not a Strategy Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
There are enough opinions to paper the side of a battle ship. ¬†With all these opinions, nobody has a straightforward answer that is applicable to all projects. There are two fundamental understanding though: (1) Everyone has a theory , (2) there is no singular cause that is universally applicable.
In fact most of the suggestions on project failures have little in common. With that said, I'd suggest there is a better way to view the project failure problem.
What are the core principles, processes, and practices for project success?
I will suggest there are three common denominators consistently mentioned in the literature that are key to a project‚Äôs success:
Of the 155 defense project failures studied in ‚ÄúThe core problem of project failure,‚ÄĚ T. Perkins, The Journal of Defense Software Engineering, Vol 3. 11, pp 17, June 2006.
From this research these numbers can be summarized into two larger classes
So where do we start?
Let's start with some principles. But first a recap
Five Immutable Principles of Project Success
¬†With these Principles, here's five Practiuces that can put them to work
The integration of these five Practices are the foundation of Performance‚ÄďBased Project Management¬ģ.¬†Each Practice stands alone and at the same time is coupled with the other Practices areas. Each Practice contains specific steps for producing beneficial outcomes to the project, while establishing the basis for overall project success.
Each Practice can be developed to the level needed for specific projects. All five Practices are critical to the success of any project.¬†If a Practice area is missing or poorly developed, the capability to manage the project will be jeopardized, possibly in ways not know until the project is too far along to be recovered.
Each Practice provides information needed to make decisions about the majority flow of the project. This actionable information is the feedback mechanism needed to keep a project under control. These control processes are not impediments to progress, but are the tools needed to increase the probability of success.
Why All This Formality, Why Not Just Start Coding, Let Customer Tell Us ¬†To Stop?
All business works on managing the flow of cost in exchange for value. All business has a fiduciary responsibility to¬†spend wisely.¬†Visibility to the obligated spend is part of Managerial Finance.¬†Opportunity Cost is the basis of Microeconomics of decision making.¬†
The 5 Principles and 5 Practices are the basis of good business management of the scarce resources of all businesses.¬†
This is how adults manage projectsRelated articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
When confronted with making decisions on software projects in the presence of uncertainty, we can turn to an established and well tested set of principles found in¬†Software Engineering Economics.
First a definition from¬†Guide to the Systems Engineering Body of Knowledge (SEBoK)
Software Engineering Economics is concerned with making decisions within the business context to align¬†technical decisions with the business goals of an organization. Topics covered include fundamentals of software¬†engineering economics (proposals, cash flow, the time-value of money, planning horizons, inflation, depreciation,¬†replacement and retirement decisions); not for-profit decision-making (cost-benefit analysis, optimization analysis);¬†estimation, economic risk and uncertainty (estimation techniques, decisions under risk and uncertainty); and multiple¬†attribute decision making (value and measurement scales, compensatory and non-compensatory techniques).
Engineering Economics is one of the Knowledge Areas for educational requirements in Software Engineering defined by INCOSE, along with Computing Foundations, Mathematical Foundations, and Engineering Foundations.¬†
A critical success factor for all software development is to¬†model the system under development as holistic, value-providing entities have been gaining recognition as a central process of¬†systems engineering. The use of modeling and simulation during the early stages of the system design of complex¬†systems and architectures can:
The process above can be performed in any lifecycle duration. From formal top down INCOSE VEE to Agile software development. The process rhythm is independent of the principles.
This is a critical communication factor - separation of Principles, Practices, and Processes, establishes the basis of comparing these Principles, Practices, and Processes across a broad spectrum of domains, governance models, methods, and experiences. Without a shared set of Principles, it's hard to have a conversation. ¬†
Developing products or services with other peoples money means we need a¬†paradigm to guide our activities. Since we are spending other peoples money, the economics of that process is guided by¬†Engineering Economics.
Engineering economic analysis concerns techniques and methods that estimate output and evaluate the worth of¬†products and services relative to their costs. (We can't determine the value of our efforts, without knowing the cost to produce that value) Engineering economic analysis is used to evaluate system¬†affordability. Fundamental to this knowledge area are value and utility, classification of cost, time value of money¬†and depreciation. These are used to perform cash flow analysis, financial decision making, replacement analysis,¬†break-even and minimum cost analysis, accounting and cost accounting. Additionally, this area involves decision¬†making involving risk and uncertainty and estimating economic elements. [SEBok, 2015]
The Microeconomic aspects of the decision making process is guided by the principles of ¬†making decisions regarding the allocation of limited resources. In software development we always have limited resources - time, money, staff, facilities, performance limitations of software and hardware.
If we are going to increase the probability of success for software development projects we need to understand how to manage in the presence of the uncertainty surrounding time, money, staff, facilities, performance of products and services and all the other probabilistic attributes of our work.
To make decisions in the presence of these uncertainties, we need to make estimates about the impacts of those decisions. This is an unavoidable consequence of how the decision making process works.
The¬†opportunity cost of any decision between two or more choices means there is a cost for NOT choosing one or more of the available choices. This is the basis of¬†microeconomics¬†of decision making.¬†What's the cost of NOT selecting an alternative?
So when it is conjectured we can make a decision in the presence of uncertainty without estimating the impact of that decision, it's simply NOT true.
That notion violates the principle of Microeconomics ¬†¬†Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Whenever someone warns you that you shouldn’t be working on different things, because it’s bad for your productivity, tell them the problem is multitasking, not multiprojecting.
Constructing a credible Integrated Master Schedule (IMS) requires sufficient schedule margin be placed at specific locations to protect key deliverables. One approach to determining this margin is the use of a Monte Carlo simulation tool.
This probabilistic margin analysis starts with the construction of a ‚Äúbest estimate‚ÄĚ Integrated Master Schedule with the work activities arranged in a ‚Äúbest path‚ÄĚ network.
While there may be ‚Äúslack‚ÄĚ in some of the activities, the Critical Path exists through this network for each Key Deliverable. This network of activities must show how each deliverable will arrive on or before the contractual need date. This ‚Äúbest path‚ÄĚ network is the Deterministic Schedule ‚Äď the schedule with fixed activity durations.
By assigning a duration variance for each class of work activity, the Monte Carlo model shows if the at what confidence level the probabilistic delivery date occurs on or before the deterministic date. The needed schedule margin for each deliverable can be derived by the Monte Carlo simulation. This activity network is referred to as the Probabilistic Schedule ‚Äď the schedule with activity durations of random variables.
With the schedule margin inserted in front of each deliverable, the Deterministic schedule becomes the basis of the Probabilistic schedule. Next is a cycle of adjusting the Deterministic schedule to assure the needed margin produces the final baselined Deterministic schedule to be placed on baseline. As the program proceeds, this schedule margin is managed through a ‚Äúmargin burn down‚ÄĚ process. Assessing the sufficiency of this margin for the remaining work is then part of the monthly program performance report.
Here's an example from an upcoming workshop on building and executing a credible Performance Measurement Baseline based on the Wright Brother's work
For this to work we need several things:
Here's how to use a Monte Carlo tool for determining the likelihood of completing on or before a given date, when there is a schedule of the work with Most Likelies for the work durations and the variances in those durations
Risk management using risk+ (v5) from Glen Alleman Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
When I hear a post like:
Two things come to mind:
All projects have uncertainty.
And there are two kinds of uncertainty on all projects. Reducible and Irreducible.
Reducible uncertainty (on the right) is described by the probability of some outcome.¬†There is an 82% probability that we'll be complete on or before the second week in November, 2016.¬†Irreducible uncertainty (on the left) is described by the Probability Distribution Function (PDF) for the underlying statistical processes.¬†
In both cases estimating is required. There is no deterministic way to produce an assessment of an outcome in the presence of uncertainty without making estimates. This is simple math. In the presence of uncertainty, the project variables are random variables, not deterministic variables. If there is no uncertainty, not need to estimate, just measure.
When we hear that #NoEstimates is about empirical data used to forecast the future, let‚Äôs look deeper into the term and the processes of empiricism.
First, an empiricist rejects the logical necessity for scientific principles and bases processes on observations.¬†
While managing other people‚Äôs money in the production of value in exchange for that money, there are principles by which that activity is guided. For empiricist principles are not immediately evident. But principles are called principles because they are indemonstrable and cannot be deduced form other premises nor be proved by any formal procedure. They are accepted they have been observed to be true in many instances and to be false in none.¬†
Second, with empirical data comes two critical assumptions that must be tested before that data has any value in decision making.
Understanding this basis of empiricism is critical to understanding the notion of making predictions in the presence of uncertainty about the future.
Next let‚Äôs address the issue of what is an estimate. It seems obvious to all working in engineering, science, and financial domain that an estimate is a numeric value or range of values for some measure that may occur at sometime in the future.Making up definitions for¬†estimate or selecting definition outside of engineering, science, and finance is disingenuous. There is no need to redefine anything.¬†
Estimation consists of finding appropriate values (the estimate) for the parameters of the system of concern in such a way that some criterion is optimized. 
The estimate has several elements:
Now when those wanting to redefine what an estimate is to support their quest to have No Estimates, like redefining forecasting as Not Estimating, it becomes clear they are not using any terms found in engineering, science, mathematics, or finance. When they suggest there are many definitions of an estimate and don‚Äôt provide any definition, with the appropriate references to that definition, it‚Äôs the same approach as saying we‚Äôre exploring for better ways to ‚Ä¶. ¬†It‚Äôs a simple and simple minded approach to a well established discipline and making decisions and fundamentally disingenuous. And should not be tolerated.
The purpose of a cost estimate is determined by its intended use, and its intended use determines its scope and detail.
Cost estimates have two general purposes:
Specific applications for estimates include providing data for trade studies, independent reviews, and baseline changes. Regardless of why the cost estimate is being developed, it is important that the project‚Äôs purpose link to the missions, goals, and strategic objectives and connect the statistical and probabilistic aspects of the project to the assessment of progress to plan and the production of value in exchange for the cost to produce that value.
The Need to Estimate
The picture below, with apologies for Scott Adams, is typical of the No Estimates advocates who contend¬†estimates are evil and need to be stopped. Estimates can‚Äôt be done. Not estimating results in a ten-fold increase in project productivity or some vague unit of measure.¬†¬†
 Dictionary of Scientific Biography, ed. Charles Coulston Gillespie, Scribner, 1073, Volume 2, pp. 604-5
 Forecasting Methods and Applications, Third Edition, Spyros Makridakis, Steven C. Whellwright, and Rob J. Hayndman
Some More Background
Insurance is great for all sorts of things. I have health insurance in case I become ill or injured. I have auto insurance that will repair or replace my vehicle if it's damaged. It also protects me in case I am involved in an accident that harms someone else. I have life insurance so that if I die, my wife and daughters are taken care of.
These are types of insurance I've chosen to have. There are other types of insurance I've also chosen not to have. For example, I've personally chosen not to have dental insurance. Most years that works out great for me. But there are some years when I have a big bill and wish I'd paid for the insurance. But, overall, I've been happy with that decision.
Similarly, every time I buy a plane ticket online there's a little checkbox asking if I want to buy travel insurance. I think it covers me in case I get sick right before a flight or something like that. I've never bought that and I've never regretted it. I've also flown over 2 million miles. So forgoing that type of insurance has also worked out well for me.
So insurance is great. I can't imagine going without my health insurance. But other types of insurance can be thought of as calculated gambles, which is exactly what they are. And sometimes those gambles pay off, sometimes they don't.
We can think of upfront thinking on development projects in the same way we think about insurance. Like insurance, upfront thinking is a way of paying a little today to avoid paying a lot tomorrow.
Upfront thinking on software projects can take a number of forms. It can be someone thinking about the architecture of the system. It could be a UI designer sketching wireframes. It could be an analyst building detailed scenarios and confirming all manner of edge cases conditions through workflows. Or it could be a database designer thinking about the structure of the database. I'm not saying any of these are bad (or that they're good). They are merely examples of upfront thinking.
Some projects will benefit from some amount of upfront thinking (although perhaps not all forms at once that I've just listed), just like many of us benefit from having some types of insurance.How Much Upfront Thinking Is Enough?
An important consideration is how much upfront thinking is enough. The best way to determine this is, unfortunately, in hindsight. But use the level of upfront thinking you do on current projects to help you decide how much to do on future projects. Here's how ...
Suppose your team finishes a project and they never had to reverse a decision. Every decision was made perfectly the first time. I'd say that team overinvested in upfront thinking. They over insured.
Consider instead a team that finishes their project and only had to reverse one decision. But it was a major decision and caused a total re-architecting of the system. That team underinvested in upfront thinking. They underinsured.
Finally, consider a team that finishes the project and had to reverse a lot of little decisions. None caused big re-architecting, but there were a lot of little decisions that each caused rework. On their own, each is small. But added together, it was a lot. Again, here's a team that underinvested in in upfront thinking. They were under insured.
So, as projects progress, evaluate whether the team is having to occasionally backtrack on decision and architectural decisions. They should occasionally have to do so. If they never do so, they've over invested in insurance by doing too much upfront thinking. But, if they're backing up too much or in big ways, they have underinvested and should do more upfront thinking.What Do You Think?
Use the Comments Section below to let me (and everyone else!) know how your projects are doing. Are you over- or under-investing in upfront thinking? Are there strategies you’ve found helpful for doing just enough upfront thinking?
The discussion to now:
When you move from resource efficiency (experts and handoffs from expert to expert) to flow efficiency (team works together to finish work), everything changes.
The time that people spend multitasking should decrease or go to zero because the team works together to finish features. The team will recognize when they are done—really done—with a feature. You don’t have the “It’s all done except for…” problem.
Managers don’t need to manage performance. They manage the system, the environment that makes it possible for people to perform their best. Managers help equip teams to manage their own performance.
The team is accountable, not a person. That increases the likelihood that the team will estimate well¬†and that the team delivers what they promised.
If you are transitioning to agile, and you have not seen these things occur, perform a retrospective. Set aside at least two hours and understand your particular challenges. I like Agile Retrospectives: Making Good Teams Great,¬†Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises, and¬†The Retrospective Handbook: A Guide for Agile Teams¬†for creating a retrospective that will work for you. You have unique challenges. Learn about them so you can address them.
I hope you enjoyed this series. Let me know if you have questions or comments.
This is the next in a series of posts about resource efficiency vs. flow efficiency:
Managers new to agile often ask, “How do I know people will be accountable?” Let’s tease apart the pieces of accountability:
Let’s take¬†the first two together:Accountable for finishing their own work and by doing their work
I suspect that managers mean, “How do I know each person does their work? How do I know they aren’t asking other people to do their work? How do I know these people are learning to do their own work?”
Those are good questions. I have yet to see a single-person feature. At the least, a developer needs someone to test their work. Yes, it’s possible to test your own work. Some of you are quite good at that, I bet.¬†Many people are not. If you want to prevent rework, build in checking in some form or another: pairing, design review, code review, unit tests, system tests, something.
So the part about “own work” seems a little micro-managing to me.
The part about doing their work is a little trickier. When people get stuck, what do they do? Often, they ask someone else for help. The help might be: talk to the duck, an explanation about what is going on in that area of the product, pairing on solving the problem, or even talking to more people.
There is no such thing as “cheating” at work. Managers are right to be concerned that people work to their capabilities. And, if those people are stuck, I don’t want them mired in the problem. We want people to learn, not be stuck.
Here’s the answer: You can’t know as a manager. You never did know as a manager.
The team knows who is hardworking and who slacks. The team knows how people are learning and if they are stuck. Even in waterfall days, the team knew. Managers may have had the illusion they knew, but they didn’t. Managers only knew what people told them.Accountable for documentation
For me, the question is who will use the documentation? I am always amazed at how many managers want documentation other than end-user documentation and how few teams find this useful. In agile, you could make it part of the definition of done.
If people build documentation time into their estimates and the team finds the internal documentation useful, the team will pressure each person to deliver their documentation. The team knows whether the person documents their work.Accountable for living up to estimates
When I ask managers if they want good estimates or completed features, they almost always say, “completed features.” Too often, the people multitask on fixing defects or production support work while they are supposed to work on a feature. I do understand the need for estimates, but holding people to their estimates? Sometimes, that’s about money.Accountable for how the project spends money
Of all the accountabilities, this one makes the most sense to me. However, it doesn’t make sense in agile, where the customer/product owner is the one responsible. As long as the team completes features, the PO determines when either there is no more value in the backlog, or there is no more money for the project. With any luck, the team has met the release criteria by this time.
For me, the idea of accountability is a team-based idea, not a person-based idea. In flow efficiency, you can ask the team to be accountable for:
When you look at accountability like this, it looks pretty different than a single person’s accountability.