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!
When it is mentioned project management is a¬†control system many in the agile world whince. But in fact project is a control system, a closed loop control system.
Here's how it works.
Each of these elements has some unit of measure:
Here's a small example of incremental delivery of value in an enterprise domain
The accomplishment of a mission or fulfillment of a business strategy can be called the¬†value produced by the project. In the picture above the¬†value delivered to the business is incremental, but fully functional on delivery to accomplish the business goal. These goals are defined in¬†Measures of Effectiveness and¬†Measures of Performance and these measures are derived from the business strategy or mission statement. So if I want a fleet of cars for my taxi service, producing a sketboard, then a bicycle, is not likley to accomplishment the business goal.
But the term¬†value alone is nice, but not sufficient. Value needs to have some unit of measure. Revenue, cost reduction, environmental cleanup, education of students, reduction of disease, the process of sales orders at a lower cost, flying the 747 to it's destination with minimal fuel. Something that can be assessed in tangible units of measure.
In exchange for this value, with it's units of measure, we have the cost of producing this value.
To assess the value or the cost, we need to know the other item. We can't know the value of something without knowing its cost. We can't know if the cost is appropriate without knowing the value produced by the cost.
This is one principle of Microeconomics of software development
The process of deciding between choices about cost and value - the trade space between cost and value - starts with information about both cost and value. This information lives in the realm of uncertainty before and during the project's life-cycle. It is only known on the cost side after the project completes. And for the value may never be known in the absence of some uncertainty as to the actual measure. This is also a principle of microeconomics - the measures we use to make decisions are random variables.
To determine the value of the random variable we need to estimate, since of course they are random. With these random variables - cost of producing value and the value exchanged for the cost, the next step in projects is to define what we want the project to do:
The actual delivery of this value can be incremental, it can be iterative, evolutionary, linear, big bang, or other ways. Software many times can be iterative or incremental, pouring concrete and welding pipe can as well. Building the Interstate might be incremental, the high rise usually needs to wait for the occupancy permit before the value is delivered to the owners. There is no single approach.
For each of these a control system is needed to assure progress to plan is being made. The two types of control systems are Open Loop and¬†Close Loop. The briefing below speaks to those and their use.
So In The End When we hear about a control loop applied to project management, we'll now know about Open and Closed Loop control. And that there can't be a Closed Loop control process without.
I tried running a few years ago, but I stopped because of shin splints and impossible work schedules.
I tried a fitness school, for several months, but I hated all the machines and uninteresting equipment.
I tried Pilates exercises, for a few days, but I found the exercises on a mat mind-numbingly boring.
I tried swimming, for a week or two, but the pool was always crowded and it was far away from my home.
I tried body-weight exercises, for exactly two days, but I found them too hard, which didn’t really motivate me.
And I tried yoga, for less than a week, but it was as least as boring as the Pilates exercises.
The presentation¬†Dealing with Estimation, Uncertainty, Risk, and Commitment: An Outside-In Look at Agility and Risk Management¬†has become a popular message for those suggesting we can make decisions about software development in the absence of estimates.
The core issue starts with first chart. It shows the actual completion of a self-selected set of projects versus the ideal estimate. This chart is now in use for the #NoEstimates paradigm as to why estimating is flawed and should be eliminated. How to eliminate estimates while making decisions about spending other peoples money is not actually clear. You'll have to pay ‚ā¨1,300 to find out.¬†
But let's look at this first chart. It shows the self-selected projects, the vast majority completed above the initial estimate. What is this¬†initial estimate?¬†In the original paper, the initial estimate appears to be the estimate made by someone for how long the project would take. No sure how that estimate was arrived at - the¬†basis of estimate - or how was the estimate was derived. We all know that subject matter expertise is the least desired and past performance, calibrated for all the variables is the best.
So Here in Lies the Rub - to Misquote from Shakespeare's¬†Hamlet
The ideal line is not calibrated. There is no assessment if the orginal estimate was credible or bogus. If it was credible, what was the confidence of that credibility and what was the error band on that confidence.¬†
This is a serious - some might say egregious¬†- error in statistical analysis. We're comparing actuals to a baseline that is not calibrated. This means the initial estimate is meaningless in the analysis of the variances without an assessment of it accuracy and precision. To then construct a probability distribution chart is nice, but measured against¬†what¬†- against bogus data.
This is harsh, but the paper and the presentation provide no description of the credibility of the¬†initial estimates. Without that, any statistical analysis is meaningless. Let's move to another example in the second chart.
The second chart - below - is from a¬†calibrated¬† baseline. The calibration comes from a parametric model, where the parameters of the¬†initial estimate are derived from prior projects - the¬†reference class forecasting paradigm. The tool used here is COCOMO. There are other tools based on COCOMO and Larry Putman's and other methods that can be used for similar¬†calibration of the initial estimates. A few we use are¬†QSM, SEER, Price.
One place to start is Validation Method for Calibrating Software Effort Models. But this approach started long ago with An Empirical Validation of Software Cost Estimation Models. All the way to the current approaches of ARIMA and PCA forecasting for cost, schedule, and performance using past performance. And current approaches, derived from past research, of tuning those cost drivers using Bayesian Statistics.
The issue of software management, estimates of software cost, time, and performance abound. We hear about it every day. Our firm works on programs that have¬†gone Over Target Baseline. So we walk the walk every day.
But when there is bad statistics used to¬†sell solutions to complex problems, that's when it becomes a larger problem. To solve this nearly intractable problem of project cost and schedule over run, we need to look to the root cause. Let's start with a book¬†Facts and Fallacies of Estimating Software Cost and Schedule.¬†From there let's look to some more root causes of software project problems. Why Projects Fail is a good place to move to, with their 101 common casues. Like the RAND and IDA Root Cause Analysis reports many are symptoms, rather than root causes, but good infomation all the same.
So in the end when it is suggested that the woo's of project success can be addressed by applying
Ask a simple question - is there¬†any tangible, verifiable, externally reviewed evidence for this. Or is this just another self-selected, self-reviewed, self-promoting idea that violates the principles of microeconomics as it is applied to software development, where:
Economics is the study of how people make decisions in resource-limited situations. This definition of economics fits the major branches of classical economics very well.¬†
Macroeconomics is the study of how people make decisions in resource-limited situations on a national or global scale. It deals with the effects of decisions that national leaders make on such issues as tax rates, interest rates, and foreign and trade policy, in the presence of uncertainty
Microeconomics is the study of how people make decisions in resource‚ÄĒlimited situations on a ¬†personal scale. It deals with the decisions that individuals and organizations make on such issues as how much insurance to buy, which word processor to buy, what features to develop in what order, whether to make or buy a capability,¬†or what prices to charge for their products or services, in the presence of uncertainty. Real Options is part of this decision making process as well.
Economic principles underlie the structure of the software development life cycle, and its primary refinements of prototyping, itertaive and incremental development, and emerging requirements.¬†
If we look at writing software for money, it falls into the¬†microeconomics realm. We have limited resources, limited time, and we need to make decisions in the presence of uncertainty.
In order to decide about the future impact of any one decision - making a choice - we need to know something about the furture which is itself¬†uncertain. The tool to makes these decisions about the future in the presence of uncertainty is call¬†estimating. Lot's of ways to estimate. Lots of tools to help us. Lots of guidance - books, papers, classrooms, advisers.¬†
But asserting we can in fact make decisions about the future in the presence of uncertainty without estimating is mathematically and practically nonsense.¬†
So now is the time to learn how to estimate, using your favorite method, because to decide in the absence of knowing the impact of that decision is counter to the stewardship of our customers money. And if we want to keep writing software for money we need to be good stewards first.Related articles Averages Without Variances are Meaningless - Or Worse Misleading How to "Lie" with Statistics How to Fib With Statistics When Uncertainty is Good No Estimates of Costs and Schedule? The Value of Information COCOMO Model Why is Statistical Thinking Hard? Back To The Future The Failure of Open Loop Thinking
Obvious not every decision we make is based on mathematics, but when we're spending money, especially¬†other people's money, we'd better have so good reason to do so. Some reason other than gut feel for any sigifican¬†value at risk. This is the principle of Microeconomics.
All Things Considered is running a series on how people interprete probability. From capturing a terrortist to the probability it will rain at your house today. The world lives on probabilitic outcomes. These probabilities are driven by underlying statistical process. These statistical processes create uncertainties in our decision making processes.
Both Aleatory and Epistemic uncertainty exist on projects. These two uncertainties create risk. This risk impacts how we make decisions. Minimizing risk, while maximizing reward is a project management process, as well as a microeconomics process. By applying statistical process control we can engage project participants in the¬†decision making¬†process. Making decision in the presence of uncertainty is sporty business and many example of poor forecasts abound. The flaws of statistical thinking are well documented.
When we encounter to notion that¬†decisions can be made in the absence of statistical thinking, there are some questions that need to be answered. Here's one set of questions and answers from the point of view of the mathematics of decision making using probability and statistics.
The book opens with a simple example.
Here's a question. We're designing airplanes - during WWII - in ways that will prevent them getting shot down by enemy fighters, so we provide them ¬†with armour. But armor makes them heavier. Heavier planes are less maneuverable and use more fuel. Armoring planes too much is a proplem. Too little is a problem. Somewhere in between is optimum.
When the planes came back from a mission, the number of bullet holes was recorded. The damage was not uniformly distributed, but followed this pattern
The mathematics here is simple. Start with setting a variable to¬†Zero. This variables is the probability that a plane that takes a hit in the enginer manages to staty in the air and return to base. The result of this analysis (pp. 5-7 of the book) can be applied to our project work.
This is an example of the thought processes needed for project management and the decision making processes needed for spending other peoples money. The mathematician approach is to ask¬†what assumptions are we making? Are they justified?¬†The first assumption - the errenous assumption - was tyhat the planes returning represented were a random sample of all the planes. If so, the conclusions could be drawn.
In The End
Show me the numbers. Numbers talk BS walks is the crude phrase, but true. When we hear some conjecture about the latest fad think about the numbers. But before that read¬†Beyond the Hype: Rediscovedring the Essence of Management, Robert Eccles and Nitin Nohria. This is an important book that lays out the processes for sorting out the hype - and untested and liley untestable conjectures - from the testable processes.Related articles How To Fix Martin Fowler's Estimating Problem in 3 Easy Steps The World of Probability and Statistics Stationary processes How Not To Be Wrong Why is Statistical Thinking Hard? Selection bias and bombers How Not To Make Decisions Using Bad Estimates
If you’ve been paying attention to agile at all, you’ve heard these terms: pairing and swarming. But what do they mean? What’s the difference?
When you pair, two people work together to finish a piece of work. Traditionally, two developers paired. The “driver” wrote the piece of work. The other person, the “navigator,” observed the work, providing review, as the work was completed.
I first paired as a developer in 1982 (kicking and screaming). I later paired in the late 1980′s as the tester in several developer-tester pairs. I co-wrote Behind Closed Doors: Secrets of Great Management with Esther Derby as a pair.
There is some data that says that when we pair, the actual coding takes about 15-20% longer. However, because we have built-in code review, there is much less debugging at the end.
When Esther and I wrote the book, we threw out the original two (boring) drafts, and rewrote the entire book in six weeks. We were physically together. I had to learn to stop talking. (She is very funny when she talks about this.) We both had to learn each others’ idiosyncrasies about indentations and deletions when writing. That’s what you do when you pair.
However, this book we wrote and published is nothing like what the original drafts were. Nothing. We did what pairs do: We discussed what we wanted this section to look like. One of us wrote for a few minutes. That person stopped. We changed. The other person wrote. Maybe we discussed as we went, but we paired.
After about five hours, we were done for the day. Done. We had expended all of our mental energy.
That’s pairing. Two developers. One work product. Not limited to code, okay?
Now, let’s talk about swarming.
Swarming is when the entire team says, “Let’s take this story and get it to done, all together.” You can think of swarming as pairing on steroids. Everyone works on the same problem. But how?
Someone will have to write code. Someone will have to write tests. The question is this: in what order and who navigates? What does everyone else do?
When I teach my agile and lean workshop, I ask the participants to select one feature that the team can complete in one hour. Everyone groans. Then they do it.
Some teams do it by having the product owner explain what the feature is in detail. Then the developers pair and the tester(s) write tests, both automated and manual. They all come together at about the 45-minute mark. They see if what they have done works. (It often doesn’t.) Then the team starts to work together, to really swarm. “What if we do this here? How about if this goes there?”
Some teams work together from the beginning. “What is the first thing we can do to add value?” (That is an excellent question.) They might move into smaller pairs, if necessary. Maybe. Maybe they need touchpoints every 15-20 minutes to re-orient themselves to say, “Where are we?” They find that if they ask for feedback from the product owner, that works well.
If you first ask, “What is the first thing we can do to add value and complete this story?” you are probably on the right track.Why Do Pairing and Swarming Work So Well?
Both pairing and swarming:
The effect of pairing and swarming is what improves your products. The built-in feedback is what creates less debugging downstream. The improved teamwork helps people work together. When you expose the work in progress, you can measure it, see it, have no surprises. With reduced work in progress, you can increase your throughput. You have better chances for craftsmanship.
You don’t have to be agile to try pairing or swarming. You can pair or swarm on any project. I bet you already have, if you’ve been on a “tiger team,” where you need to fix something for a “Very Important Customer” or you have a “Critical Fix” that must ship ASAP. If you had all eyes on one problem, you might have paired or swarmed.
If you are agile, and you are not pairing or swarming, consider adding either or both to your repertoire, now.
Someone emailed to me, “I’m sorry to see you had to work on Saturday night.” I don’t understand why because the “work” was only a couple of emails that I sent. And I was happy to do that on a Saturday night, just like I was perfectly happy to spend the entire Tuesday morning shopping for a mountain bike.
On the first day of my Certified ScrumMaster course, we go over the agenda for the two days. I point out that one topic we’ll cover will be “meetings.” I usually point out that Scrum is often criticized for the amount of meetings it defines. I then claim that this is a pretty weak criticism of Scrum because most of the meetings really aren’t very long, and that if we wanted to, we could find better criticisms of Scrum than “Scrum teams meet too much.”
After saying that, I always expect someone to ask for an example of a better criticism of Scrum. But usually, no one asks and I move onto the next topic.
And since I think it’s important to remain critical, I’d like to use this post to share one of my own criticisms of Scrum.
The strongest criticism I’d levy on Scrum is that many Scrum teams have become too focused on checking the boxes to say they are done with something, and less focused on finding innovative solutions to the problems they are handed.
Scrum in the mid-1990s (as I implemented it and saw it implemented back then) was all about finding innovative solutions. Teams were given a problem, and given a month (or four weeks) to solve the problem. With that much time, teams were able to try one or more potential breakthrough approaches before having to revert back to a safer, tried-and-true approach.
In today’s version of Scrum, many teams have become overly obsessed with being able to say they finished everything they thought they would. This leads those teams to start with the safe approach. Many teams never try any wild ideas that could lead to truly innovative solutions.
I believe a great deal of this is the result of the move to shorter sprints, with two weeks being the norm these days. Shorter sprints leave less time to recover if a promising but risky initial approach fails to pan out.
I’m willing to take my share of the “blame” for the prevalence of two-week sprints. I’ve certainly been vocal in my preference for that length (while remaining open to whatever is right for a given team). And, I still think two weeks is the right length for most teams. Two weeks is also my default, initial recommendation to a team until I know more about them.
So, as much good as a shift toward shorter sprints have done for Scrum teams, for many teams, it has come at the expense of creativity, experimentation and breakthrough ideas.
I don’t think the answer is for all teams to instantly revert to four-week sprints. I think mature Scrum teams have found ways to balance the pressure to get things done with the benefits that come from occasionally pursuing long-shot ideas that sometimes pay off.
So, there’s my biggest criticism of Scrum as I see it practiced today. What’s yours? What problems do you see with Scrum as defined or as it’s commonly practiced today?
In preparation for my talk, Agile Projects, Programs, and Portfolio Management: No Air Quotes Required, I have created a Minimum Reading List for an Agile Transition. Note the emphasis on minimum.
I could have added many more books to this list. But the problem I see is that people don’t read anything. They think they do agile if they say they do agile.
But saying you do agile doesn’t mean anything if you don’t get to done on small stories and have the ability to change. I hope that if I suggest some small list of potential books, people will read the books, and realize, “I can do this!”
I am probably crazy-optimistic. But that hasn’t stopped me before.
I would like your help. Would you please review my list? Do you have better books? Do you have better suggestions? It’s my list. I might not change my mind. However, if you comment on that page, I would know what you think.
Thank you very much.
Visiting the Montana State Museum of the Rockies this weekend and came across this sign in an exhibit.¬†
Now writing software for money is not this kind of science, but it is closely related to engineering and the enablement of engineering processes in our domain - things that fly away, swim away, drive away, and the enterprise IT systems that support those outcomes.
When we hear about some new way to do something around managing projects that spend other peoples money, we do need to ask the questions posed by the sign above.
Is there any evidence that the suggested way - this new alternative of doing something - has the desired outcomes?
No? Then it's going to be difficult for those of us working in a domain that provides mission critical solutions - ERP, embedded software, infrastructure that other systems depend on - to know how to assess those suggestions.
The process of asking and answering a question like that is found in the¬†Governance paradigm. Since our role is to be stewards of our customer's money in the delivery of value in exchange for that money, it's a¬†legitimate question and deserves a legitimate answer. Without an answer, or at least and answer than can be tested outside the personal anecdotal experience of the proposer, it tends to be unsubstantiated opinion.¬†Related articles Performance Based Management Positive Deviance Can Agile Be Integrated with Governance Based Development Processes? What Software Domain Do You Work In? The Myth of Incremental Development How to "Lie" with Statistics What Does "Done" Look Like? Why is Statistical Thinking Hard? If We're Going To Make Improvements, We Have To Be Able To Calculate Real Numbers
I have an article in a new online magazine, Women Testers, the July 2014 edition. My article is called “Why Testing?”
When I was a tester or a developer, I asked many questions. As a project manager, program manager or consultant, I still ask many questions. One of those is the Why question. This article examines that question from a number of perspectives.
I bet you’ll enjoy it!
Sometimes, event organizers ask me to fill out a form asking me for my company name, address, bank account number, bank name, tax number, and much more. They tell me they need this information in order to make their payment to me later. But I think this is a bit silly.
In my role as technical editor for agileconnection.com, I have the opportunity to read many terrific articles. I also have the opportunity to review and comment on those articles.
One such comment is what do teams do? Do they “gel” or do they “jell”?
Gel is what you put in hair. When you “gel” things, you create a thick goo, like concrete. Teams are not a thick goo. Teams are flexible and responsive.
Jell is what you want teams to do. You want them firm, but not set in concrete. When teams jell, they might even jiggle a little. They wave. They adapt. They might even do a little dance, zigging here, zapping there.
You want to keep the people in the teams as much as possible, so you flow work through the teams. But you want the people in the teams to reconsider what they do on a regular basis. That’s called retrospecting. People who have their feet in concrete don’t retrospect. They are stuck. People who are flexible and responsive do.
So, think about whether you have a gelled or a jelled team. Maybe I’m being a nitpicker. I probably am. Our words mean something.
If you have an article you’d like to publish, send it to me. You and I will craft it into something great. Whether or not your team jells.
The question is two fold. Can the customer accept the release into use and the other does the customer have the ability to make use of the incremental capabilities of these releases?
Let's start with the incremental release. I know the picture to the left is ¬†considered a metaphor by some. But as a metaphor it's a weak. Let's look a a few previous posts. Another Bad Agile Analogy, Use, Misuse, and Danger of Metaphor. Each of these presents some issues with using Metaphors.
But let's be crystal clear here. Incremental development in the style of the bottom picture¬†may be a preferred method, once the customer agrees. Much of the reterotic around agile assumes the customer can behave in this way, without looking outside the ancedotal and many times narrow experiences of the those making that suggestion. For agile to succeed in the enterprise and mission critical product and project domain, testing the applicability of both pictures is needed.
Ask the customer if they are willing to use the skateboard while waiting for the car? Otherwise you have a solution looking for a problem to solve.
Now to the bigger issue. In the picture above, the top series is a linear development and the bottom an iterative or incremental depending on where you work. Iterating on the needed capabilities to arrive at the car. Or incrementally delivering a mode of transporatation.
The bottom's increment shows 5 vehicles produced by the project. The core question that is unanswered is¬†does the customer want a skate board, scooter, bicycle, motorcycle, and then a car for transportation. If yes, no problem. But if the customer actually needs a car to conduct business, drive the kids to school, or arrive at the airport for your vacation trip.
The failure of the metaphor and most metaphors is they don't address the reason for writing software for money
Provide capabilities for the business to accomplish something - Capabilities Based Planning
The customer didn't buy requirements, software, hardware, stories, features, or even the agile development process. They bought a capability to do something. Here's how to start that process.
Here's the outcome and an insurnace provider network enrollemtn ERP system.
Producing skateboards, then scooters, then bicycles and then finally the car isn't going to meet the needs of the customer if they want a car or a fleet of cars. In the figure above the Minimal Viable Features, aren't features they are capabilities. For example this statement is a¬†minimal viable product is likey a good description of a Beta Feature. Could be connected to a business capability, but without a¬†Capabilities Based Plan as in above, can't really tell.
So How Did We Get In This Situation?
Here's a biased opinion informed by my several decades of experience writing code and managing others who write code -¬†we're missing the systems engineering paradigm in commercial software development. That is for software development of mission critical systems, and Enterprise IT is an example of mission critical systems.
Here's some posts:
The patradigm of Systems Engineering fills 1,000's pages and dozen's of books, but it is boiled down to this.
You need to know what DONE looks like in units of measure meaningful to the decision makers. Those units start with Measures of Effectiveness and Measures of Performance.
Each of those measures is probabilistic, driven by the underlying statistical processes of the system. These mean you must be able to estimate not only cost and schedule, but how that cost and schedule will deliver the needed system capabilities measured in MOE's and MOP's.Do It Right or Do It Twice Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Agile vs Waterfall: Introduction Lean Startup, Innovation, #NoEstimates, and Minimal Viable Features
I often promote work-life fusion, quitting jobs that are not fulfilling, and seeking work that is a calling instead of just a career. But, I hear some people think, can this be true for everyone? Is there a great job, somewhere, for every person in the world?
What about cleaning toilets?
How can this work be fulfilling to anyone?
Well, that depends…
Project Management is a control system, subject to the theory and practice of control systems.¬†The Project Management Control System provides for the management of systems and processes - cost estimating, work scope¬†structuring and authorization, scheduling, performance measurement, reporting, for assessing the progress of spending other peoples money.
The level of formality for these processes varies according to domain and context. From sticky notes on the wall for a 3 person internal warehouse locator website of a plastic shoe manufacture - ¬†to a full DCMA ANSI-748C validated Earned Value Management System (EVMS) on a $1B software development project and everything in between.
The key here is if we're going to say we have a¬†control system it needs to be a Closed Loop control system, not an Open Loop control system. On Open Loop system is called¬†train watching, we sit by the side of the tracks and count the trains going by and report that number. How many trains¬†should go by,¬†could go by? We don't know. That's what's shown in the first picture. We sample the data, we apply that data to the process and it generates an output. There is no corrective action, it's just a signal based on the past performance of the system. Some examples of Open Loop control implemented in the first picture:
The key attribute of Open Loop Control¬†
The key disadvantage of open-loop systems is it is poorly equipped to handle disturbances or changes in the conditions which that reduce its ability to complete the desired task.¬†
A close loop system behaves differently. Here's some example of controllers used in the second picture
The key attributes of ¬†Close Loop Control, shown in the second picture
Because the closed-loop system has ¬†knowledge of the output condition - in the case of projects the desired cost, schedule, and technical performance, it is ¬†equipped to handle ¬†system disturbances or changes in the conditions which may reduce its ability to complete the desired task.
When we have a target cost - defined on day one by the target budget, a planned need date, and some technical performance target, closed loop control provides the needed feedback to make decisions along the when, when the¬†actual¬†performance is not meeting our¬†planned or¬†needed performance
In the end it comes back to the immutable principle of microeconomics. When we are spending money to produce a value, we need to make decisions about which is the best path to take, which are the best of multiple options to choose. In our to do this we need to know something about the cost, schedule, and performance¬†forecasts from each of the choices. Then we need feedback from the¬†actual performance to compare with our¬†planned¬†performance to create an¬†error¬†signal. With this¬†error¬†signal, we can then¬†DECIDE what corrective actions to take.
Without this error signal, derived from the planned values compared with the actual values there is no information needed to decide. Sure we can measure what happened in the past and decide, just like we can count trains and make some decision. But that decision is not based on a planned outcome, a stated need, or an Estimated Arrival time for example.¬†
Without that estimated arrival time, we can't tell if the train is late or early, just that it arrived. Same with the project measurements.
Open Loop provides no feedback, so you're essentially driving in the rear view mirror, when you should be looking out the windshield deciding where to go next to escape the problem.Can We Make Decisions Without Feedback? Seven Immutable Activities of Project Success Agile Requires Discipline, In Fact Successful Projects Require Discipline The DCMA 14 Point Schedule Assessment Control system and its classification The Failure of Open Loop Thinking First Comes Theory, Then Comes Practice All Project Numbers are Random Numbers - Act Accordingly
We find no sense in talking about something unless we specify how we measure it. A definition by the method of measuring a quantity is the one sure way of avoiding talking nonsense¬†‚ÄĒ Sir Hermann Bondi
So when we hear a suggested approach to solving any problem, what are the units of measure of the discussion elements, the inputs to that discussion, and the outcomes?
Micro-economics is defined as
A branch of economics that studies the behavior of individuals and small impacting players in making decisions on the allocation of limited resources. Typically, it applies to markets where goods or services are bought and sold.
Certainly in the software development business, goods are bought and sold. Software is developed in exchange for money. The resulting product is then put to work to generate some monetized value for the buyer. The value exchanged for the cost of that value is usually assessed as the Return on Investment
ROI = (Value - Cost of the Value) / Cost of the Value
Let's start with some basic concepts of writing software for money. I'd suggest these are immutable concepts in a¬†for proft¬†business world. The book on the left is a ggod start, but there are other materials about the¬†economics of software development. The one that comes to mind is¬†Software Engineering Economics, Barry Boehm, Prentice Hall. While some has suggested this book is dated and no longer applicable to our modern software development paradigm, that could only be true if our modern paradigm is not subject to the principles of micro-economics. And that is unlikely, so let's proceed with applying the principles of micro-economics to the problem at hand. That problem is
How can we know the cost, schedule, and performance of a software product with sufficient confidence into order to make business (micro-economic) decisions about how to manage the limited resources of the project?
Those resources are of course the variables we are trying to determine. Cost, Schedule, and Performance. Each of which contains¬†resources. Cost in software development is primarily driven by staff. Schedule is driven by the efficacy of that staff's ability to write code. And the performance of the resulting outcomes are driven by the skills and experience of the staff, who is consuming the funds (cost) provided to the project.
So if we look at the basics of the economics of writing software for money, we'll see some simple principles.
If it's a product development effort, someone in the marketing and sales department has a planned release date. This date and the projected revenue from that release is in the sales plan. These are random numbers of course - ¬†so I won't repeat that, but all numbers in business are random numnbers until they get entered into the General Ledger.
If it's a service effort, the customer has engaged the firm to perform some work in writing software, doing consulting around that software, integrating existing software or some combination of these and other¬†software related services. Managing the Professional Services Firm, was mandatory reading along wioth other internal company written books when I worked for a large Professional Services (PS) firm. With our small firm now, we still refer to that book.
Warning this is an Opinion Piece.
In a conversation this week the quote¬†Insanity¬†is doing everything the same way and expecting a different outcome. Or some variant of that. Attributed to Einstein. As if attributing it to Einstein makes it somehow more credible, than attributing it to Dagwood Bumstead.
Why is this Seemingly Trival Point Important
We toss around platitudes, quotes, and similar phrases in the weak and useless attempt to establish credibility of an idea by referencing some other work. Like quoting a 34 year old software report from NATO, when only mainframes and FORTRAN 77 were used, to show the¬†software crisis and try to convince people it's the same today. Or use un-vetted, un-reviewed, charts and graphs from an opinion piece in popular techncial¬†magazine¬†as the basis of statistical analysis of self-selected data
Is it world shaking news? No. Is the balanced of the universe disrupted? Hardly.¬†
But is shows a lack of mental discipline that leaks into the next level of thought process. It's always the little things that count, get those right and the big things follow. That is a quote from somewhere. But it also shows laziness of thought, use of platitudes in place of the hard work to solve nearly intractable problems, and all around disdain for working on those hard problems. It's a sign of our modern world - look for the fun stuff, the easy stuff, and the stuff we don't really want to be held accountable for if it goes wrong
I will use the Edwin Land quote though, that is properly attributed to him
Don't¬†undertake¬†a project unless it is manifestly important and nearly impossible.¬†
That doesn't sound like much fun, let's work on small, simple, and easy projects and tell everyone how those successful processes we developed can be scaled to the¬†manifestly important and nearly impossible ones.Related articles Resources for Moving Beyond the "Estimating Fallacy" How to Deal With Complexity In Software Projects? 50 Common Misquotations, but no Howard Thurman Fake quotes flood social media 31 Famous Quotations You've Been Getting Wrong 6 Famous Misquotes & Where They Came From (Mis)quoting Neil Armstrong
The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.
I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.
I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason, this doesn’t bother my wife, Laura, but it annoys me. So I’d like to replace the dishwasher.
The clothes washer is doing fine, but the dryer isn’t working too well. I think we’ve had it 14 years, and I sometimes have to run the drying cycle three times before clothes are fully dried. So, I’ll probably want to buy a clothes dryer, too. I’ve also lately become irritated by the toaster. It’s great and works well, but bread doesn’t fit. I have to angle the bread, with part sticking out of the toaster – so, I get partially toasted bread. Or, I flip the bread midway and then get the middle of the bread overly toasted. So, add a new toaster to the list.
After all that, a new car might be nice.
What is this list? Well, my personal Things to Buy Backlog, of course. It’s a prioritized sequenced list of things I plan to buy. To facilitate long-term planning it includes everything I plan to buy for the next 12 months:
Don’t you have a list like this, with that level of detail? Of course not. Neither do I. We don’t make lists like this because such a list is unnecessary. In everyday life, we don’t map out the equivalent of a product backlog.
Instead, we make our purchase decisions in a much simpler fashion: “Now” or “not now.” Do I want that big television now, or not now? And this amount of prioritization is good enough.
In many cases, it is also good enough for our product development projects.
Sure, you’ll always need to know what you’re going to build this sprint. But what you build next sprint will likely depend on what the team delivers this sprint, and on how customers respond to it.
That means you might want to forgo prioritizing any further ahead unless you are in an environment that requires it, such as contract development.
Prioritizing features in a “now/not now” manner streamlines your planning process, allows learning to be incorporated into the planning process, and better matches how we prioritize outside the workplace.
Many projects will find this a very valuable shift.
In next month’s newsletter, I’ll write about how to do this within the context of establishing a longer-term vision for a product.
Sometimes people ask me, ‚ÄúWhat do you mean with work-life fusion? How is that different from work-life balance?‚ÄĚ
Work-life balance means using Twitter for your work-life and Facebook for your private life. Instead, I have friends, family, and business contacts everywhere! My 13th happy anniverselfie on Facebook was liked by 86 people, half of them were friends and family, and the other half were business contacts. I call that work-life fusion.