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!
There is a popular Agile and No Estimates phrase...
It is by doing the work we discover the work we must do.Â
This of course ignores the notion ofÂ engineering Â orÂ designingÂ a solution to the needed Capabilities of the customer, BEFORE starting coding. It is certainly the case that some aspects of the software solution can only beÂ confirmed when the working software is available for use.Â But like all good platitudes in the agile community, there is no domain or context as to where this phrase is applicable. Where can coding start before there is some sort of framework for how the needed capabilities will be delivered?Â
This sounds not only nĂ¤ive, but sounds like we're wandering around looking for a solution without any definition of what the problem is. When that is the approach, when the solution appears it may not be recognized as the solution. Agile is certainly the basis of dealing withÂ emerging requirements. But all good agile processes have some sense of what the customer is looking for.Â
This understanding of what capabilities the customer needs starts with a Product Roadmap. TheÂ Product Roadmap is a plan that matches short-term and long-term business goals with specific technology solutions to help meet those goals.
A Plan is a Strategy for success. All strategies have a hypothesis. A Hypothesis need to be tested. This is what working software does. It tests the hypothesis of the Strategy described in the ProductÂ Roadmap.
So if you have toÂ do the workÂ to discoverÂ what work must be done, you've got anÂ Open Loop control system. ToÂ close the loop thisÂ emergent work needs to have aÂ target to steer toward. With thisÂ target the working software can be compared to theÂ desired workingÂ software.Â TheÂ variance between the two used to take corrective actions to steer toward the desired goals.
And of course, since the steering target (goal) and the path to this goal are both random variablesÂ - estimates will be needed toÂ close the loopÂ of the control processes used to reach the desired outcomes that meet the Capabilities requested by the customer.Related articles Mr. Franklin's Advice Root Cause of Project Failure Herding Cats: The Myth of "Discover by Doing" Estimating and Making Decisions in Presence of Uncertainty
If you can't explain what you are doing as a process, then you don't know what you are doing -Â Deming
Process is the Â answer to the questionÂ How do we do thingsÂ aroundÂ here? All organizations should have a widely accepted Process for making decisions. Â "A New Engineering Profession is Emerging: Decision Coach,"Â IEEE Engineering Management Review, Vol. 44, No. 2, Second Quarter, June 2016
A skeptic will question claims, then embrace the evidence. A denier will question claims, then reject the evidence. - Neil deGrase Tyson
Think of this whenever there is a conjecture that has no testable evidence of the claim. And think ever more when those making the conjectured claim refuse to provide evidence. When that is the case, it is appropriate to ignore the conjecture all togetherÂ
In Part 1, I talked about small stories/chunks of work, checking in all the time so you could buildÂ often and see progress. That assumes you know what done means. Project “done” means release criteria. Here are some stories about how I started using release criteria.
Back in the 70s,Â I worked in a small development group. We had 5 or 6 people, depending on the time of year. We worked alone on our parts of the system. We all integrated into one instrument, but we worked primarily alone. This is back in the days of microcomputers. I wrote assembler, Fortran, or microcode, depending on the part of the system. I still worked on small chunks, “checked in,” as in I made sure I saved my files. No, we had no real version control then.
We had a major release in about 1979 or something like that. I’d been there about 15 months by then. Our customers called the President of the company, complaining about the software. Yes, it was that bad.
Why was it that bad? We had thought we were working towards one goal. Our customers wanted a different goal. If I remember correctly, these were some of the problems (that was a long time ago. I might have forgotten some details.):
Oops. My boss told us we needed to fix it. I asked the question, “How will we know we are done?” He responded, “When the customers stop calling.” I said, “No, we’re not going to keep shipping more tape to people. What are all the things you want us to do?” He said, “You guys are the software people. You decide.”
I asked my colleagues if it was okay if I developed draft release criteria, so we would know that the release was done. They agreed. I developed them in the next half day, wrote a memo and asked people for a meeting to see if they agreed. (This is in the days before email.)
We met and we changed my strawman criteria to something we could all agree on. We now knew what we had to do. I showed the criteria to my boss. He agreed with them. We worked to the release criteria, sent out a new tape (before the days of disks or CDs!) to all our customers and that project finally finished.
I used the idea of release criteria on every single project since. For me, it’s a powerful idea, to know what done means for the project.
I wrote aÂ release criteria article (see the release criteria search for my release criteria writing) and explained it more in Manage It! Your Guide to Modern, Pragmatic Project Management.
In the 80s, I used it for a projectÂ where we did custom machine vision implementations. If I hadn’t, the customer would have continued asking for more features. The customer did anyway, but we could ask for more money every time we changed the release criteria to add more features.
I use release criteria and milestone criteria for any projects and programs longer than three months in duration, so we could see our progress (or lack thereof) earlier, rather than later. To be honest, even if we think the project is only a couple of months, I always ask, “Do we know what done means for this project?” For small projects, I want to make sure we finish and don’t add more to the project. For programs, I want to make sure we all know where we are headed, so we get there.
Here’s how small chunks of work, checking in every day, and release criteria all work together:
Here’s a little list that might help you achieve friction-less releases:
Solve these problems and you may find frictionless release possible.
When you make releasing externally a business decision—because you can release internally any time you want—you will find your project proceeds more smoothly, regardless of whether you are agile.
Reminder: If you want to learn how to Â make your stories smaller or solve some of the problems of non-frictionless releases, join my Practical Product Owner workshop, starting August 23, 2016. You’ll practice on your projects, so you can see maximum business value from the workshop.
Avoid software project horror stories - check the reality value of the estimate first from Harold van Heeringen
Would you like to release your product at any time? I like it when releases are a business decision, not a result of blood, sweat, and tears.Â It’s possible, and it might not be easy for you. Here are some stories thatÂ showed you how I did it, long ago and more recently.
Story 1: Many years ago, I was a developer on a moderately complex system. There were three of us working together. We used RCS (yes, it was in the ’80s or something like that). I hated that system. Maybe it was our installation of it. I don’t know. All I Â know is that it was too easy to lock each other out, and not be able to do a darn thing. My approach was to make sure I could check in my work in as few files as possible (Single Responsibility Principle, although I didn’t know it at the time), and to work on small chunks.
I checked in every day at least before I went to lunch, once in the middle of the afternoon, and before I left for the day. I did not do test-first development, and I didn’t check my tests in at the time. It took me a while to learn that lesson. I only checked in working code—at least, it worked on my machine.
We built almost every day. (No, we hadn’t learned that lesson either.) We could release at least once a week, closer to twice a week. Â Not friction-less, but close enough for our needs.
Story 2: I learned some lessons, and a few years later, I had graduated to SCCS. I still didn’t like it. Merging was not possible for us, so we each worked on our own small stuff. I still worked on small chunks and checked in at least three times a day. This time, I was smarter, and checked in my tests as I wrote code. I still wrote code first and tests second. However, I worked in really small chunks (small functions and the tests that went with them) and checked them in as a unit. The only time I didn’t do that is if it was lunch or the end of the day. If I was done with code but not tests, I checked in anyway. (No, I was not perfect.) We all had a policy of checking in all our code every day. That way, someone else could take over if one of us got sick.
Each of us did the same thing. This time, we built whenever we wanted a new system. Often, it was a couple of times a day. We told each other, “Don’t go there. That part’s not done, but it shouldn’t break anything.” We had internal releases at least once a day. We released as a demo once a week to our manager.
After that, I worked at a couple of places with home-grown version control systems that look a lot like subversion does now. That was in the later 80s. I became a project manager and program manager.
Story 3: I was a program manager for a 9-team software program. We’d had trouble in the past getting to the point where we could release. I asked teams to do these things: Work towards a program-wide deliverable (release) every month, and use continuous integration. I said, “I want you to check everything in every day and make sure we always have a working build. I want to be able to see the build work every morning when I arrive.” Seven teams said yes. Two teams said no. I explained to the teams they could work in any way they wanted, as long as they could integrate within 24 hours of seeing everyone else’s code. “No problem, JR. We know what we’re doing.”
Well, those two teams didn’t deliver their parts at the first month milestone. They were pissed when I explained they could not work on any more features until they integrated what they had. Until they had everything working, no new features. (I was pissed, too.)
It took them almost three weeks to integrate their four weeks of work. They finally asked for help and a couple of other guys worked with the teams to untangle their code and check everything in.
I learned the value of continuous integration early. Mostly because I was way too lazy (forgetful?, not smart enough?) to be able to keep the details of an entire system in my head for an entire project. I know people who can. I cannot. I used to think it was one of my failings. I now realize many people only think they can keep all the details. They can’t either.
Here’s the technical part of how I got to frictionless releases:
Frictionless releases are not just technical. You have to know what done means for a release. That’s why I started using release criteria back in the 70s. I’ll write a part 2 about release criteria.
A common assertion in the Agile community is we focus on Value over Cost.
Both are equally needed. Both must be present to make informed decisions. Both are random variables. As random variables, both need estimates to make informed decisions.
To assess value produced by the project we first must have targets to steer toward. A target Value must be measured in units meaningful to the decision makers. Measures of Effectiveness and Performance that can monetized this Value.
Value cannot be determined without knowing the cost to produce that Value. This is fundamental to the Microeconomics of Decision making for all business processes.
The Value must be assessed using...
Without these measures attached to the Value there is no way to confirm that the cost to produce the Value will breakeven. The Return on Investment to deliver the needed Capability is of course.
ROI = (Value - Cost)/Cost
So the numerator and the denominator must have the same units of Measure. This can usually be dollars. Maybe hours. So when we hear ...
The focus on value is what makes the #NoEstimatesÂ idea valuable - ask in what units of measure is that Value? Are those units of measure meanigful to the decision makers? Are those decision makers accountable for the financial performance of the firm?
Where You Stand Depends On Where You Sit
This notion of the basis of all good discussions. It is also the basis of discussions that get us in trouble. For example, IÂ sit in a FAR 34.2/DFARS 234.2 Federal Procurement paradigm and a similar paradigm for Enterprise IT based in ISO 12207, ITIL V3.1, CMMI, Â orÂ similar governance processes.
Both these domains are guided by a Governance framework for spending other people's money, planning for that spend, performing the work with that money, reporting the progress to plan for that spend to produce the needed value, and taking corrective actions when the outcomes don't match the plan to increase the probability that the needed value (Capabilities) will be delivered for the planned cost to keep the Return On Investment on track.
This paradigm is independent of the software development method - traditional or agile.
If you work where the customer has a lowÂ need to know the cost, schedule, or what will be produced for the money, then you likely sit somewhere else.Â
For at least 15 years, I’ve heard people say that projects are dead. Projects and project-based thinking are relics of the 20th century.
I don’t buy it. Let me explain.
Let’s start with the definition of a project. The Project Management Institute (PMI) defines a project this way:A project is a temporary endeavor undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end.
The general argument against projects is that work is more continual now. There is no “definite beginning and end.” And many endeavors we might call project do not have a “temporary nature.”
As an example of why we might think projects are dead, think about a developer with a freshly earned university degree. The developer gets hired at Google and is assigned to the AdWords project. The developer then works on AdWords for the next 40 years.
Has this developer worked on a project? After all, a 40-year career spent on AdWords was not of a “temporary nature.” And there was no “definite beginning and end” other than the beginning and end of the developer’s career on the same product.
Yes, that’s true. But during our developer’s 40-year career on AdWords, there were undoubtedly initiatives or milestones that were focused on.
For example, Google occasionally overhauls or significantly enhances its ranking algorithms. Past algorithm updates have been given names like Penguin, Panda, Pigeon, Pirate and Hummingbird. Each of these updates was likely a “temporary endeavor undertaken to create a unique product, service, or result.” In other words, each was a project.
Did each have a definite beginning and end? Perhaps not. The ease with which software can be released today (especially for web-based products) often blurs start and stop dates of projects. An initial release is made and then, for example, is quickly updated over the next few weeks.
But, for all reasonable purposes, our developer’s 40-year AdWords career can be thought of as having been split into a series of shorter projects.Why This Is Important
With any iterative and incremental process such as agile, there is a risk of delivering less value than possible because of focusing too much on the short term. When product owners are told to select the most important things each sprint, they can be tempted to select urgent items that customers are screaming for today rather than important items that will deliver more value over the longer term.
Projects mitigate this risk. Projects provide a planning horizon that is longer than a sprint--typically in the range of two to six months. This “definite beginning and end” that is focused on a “unique product, service or result” encourages product owners to select truly important things to work on rather than whatever some customer or salesperson screamed about yesterday.
I always encourage product owners and their teams to identify a milestone they are working toward that is longer than a single sprint. I like doing this quarterly, but other cycles can work equally well. The project, then, is the temporary pursuit of that milestone.
Projects remain a useful construct. They provide a motivation to accomplish something grander than could be done in a single iteration. Further, they serve as ways to group common work and provide a tangible target for teams working on them. Projects also facilitate communication about related sets of functionality.
Projects aren’t dead yet and I don’t see them going away.What Do You Think?
Does your agile team organize work in projects (temporary endeavors in pursuit of an objective)? Have you experienced the sub-optimizing I’ve described when product owners look ahead only one iteration? Please share your thoughts in the comments below.
I feel a bit strange.
Saturday was the first of a 50-day trip across the USA as part of my global book tour. I was on the first of what will be 14 flights, looking at a schedule comprised of 20+ cities, 17 events, 3 road trips, a couple of train rides, a handful of national parks, and many, many coffees.
I have never done this before. I’ve never been away from home for more than 4 weeks. Given that I’m someone who loves to be home, this will be a challenge. A slight feeling of homesickness is nothing strange to me.
Fortunately, I won’t be all alone. Raoul will join me on this trip after 14 days. And I’m looking forward to meeting many people with both familiar and unfamiliar faces. Maybe you are one of them! If you are, don’t be offended when I politely decline some social invitations. It will be hard enough already for me to keep my sanity. And I can only recharge when I’m not socializing.
Now and then, we should all do something that feels uncomfortable. When we do something that is a little bit scary, we are creating a new experience. And experiences make us happy. I’m sure I will feel that way about this trip as well.
On our morning ride, the conversation came around to Systems. Some of our group or like me - aÂ techie - a few others are business people in finance and ops. The topic wasÂ what's a system and how does that notion impact or world. The retailer in the group had a notion of a system - grocery stores are systems that manage the entire supply chain from field to basket.
Here's my reading list that has served me well for those interested in Systems
These are allÂ actionable outcomes books.Â
Systems of information-feedback control are fundamental to all life and human endeavor, from the slow pace of biological evolution to the launching the latest space satellite ... Everything we do as individuals, as an industry, or as a society is done in the context of an information-feedback system. - Jay W. Forrester
There is a popular graph showing project performance versus the estimated project performance in "Schedule Estimation and
Uncertainty SurroundingÂ the Cone of Uncertainty," Todd Little,Â IEEE Software,Â May/June 2006.Â
This chart (above) Â shows data from samples of software development projects and is used by many in the agile community and by #NoEstimates advocates to conjecture thatÂ estimates are usually wrong. In fact estimates can easily be wrong for many reasons. But knowingÂ whyÂ they are wrong is rarely theÂ outcome of the discussion.Â
This approach is missing a critical understanding about assessing the effectiveness of any estimating process. It starts with the notion ofÂ an ideal estimate. ThatÂ isÂ a post hoc assessment of the project. TheÂ idea estimateÂ is only knownÂ afterÂ the project is over.
Next isÂ another critical issue.Â
Did the projects (in the graph above) overrun the estimate because the estimate was wrong or because the project was executed wrongly?
In our domain of complex projects, many of which are Software Intensive System of Systems, there are four primary Root Causes of Unanticipated Cost and Schedule Growth, shown below.
The topÂ graph shows samples from the programs in the business. But it does not showÂ WHY those programs ended up Â greater than the initial estimates. The graph is just a collection of data after the fact. What was theÂ Root Cause of this unanticipated cost (and schedule) growth. The paper goes on toÂ speak about aÂ Estimating Quality Factor but that is only One of the four coreÂ Root Causes of cost growth from the PARCA research. As well the paper mentionsÂ other causes of growth, similar someÂ PARCA causes.
But each project in the graph is not assigned a specific (maybe even more than one) cause. Without that assignment it is not possible to determine ifÂ estimating was the Root Cause, or as stated above one or more of the three otherÂ causes was the reason the project was above theÂ Ideal line.Â
In the notion ofÂ Ideal I will assume the estimate wasÂ IdealÂ if the project actuals matched the estimate.
The problem here is those advocating estimates are flawed, a waste, not needed, do harm, or are evenÂ evil use this chart to support their claim. Without stating what theÂ Cause for the deviation from theÂ Ideal is. Just that it IS. Not Why. There is no basis to make any claims about the issues with estimating.Â
Without the Why, NOÂ corrective action can be taken to improve the performance of both the project or any of the four listed (and many other) processes includingÂ Â the estimating process for the project. This is the fundamental basis of Root Cause Analysis. And it comes down to this ...
Without the Root Cause for the undesirable outcome, no corrective action can be taken. You're just treating the Symptom. Those conjecturing a Cause (say Estimating is the smell of Dysfunction) have no basis on which to make that statement. It's a house built on sand.Â Â Same for the Cone Â of Uncertainty - also popularly misused, since the vertical scale is rarelyÂ calibratedÂ for the specific domain, instead some broad and uncalibrated range provided forÂ notational purposes.
And as aÂ notionalÂ concept the Cone of Uncertainty is useful. As a practical concept, only when the vertical scale isÂ calibrated (Cardinal versus Ordinal) can it be used to assess theÂ uncertantyÂ of the estimates during specific periods of the project. This is anotherÂ misuse ofÂ statistical data analysis.
There are databases that provide information needed toÂ calibrateÂ that chart as well. But that's another post.
For now, take care when seeing the first chart, to askÂ do you know the cause for theÂ projects that is above the Ideal Line?Â No, then all you can say isÂ we don't know why, but there are a lot of projects in our organization that have aÂ Symptom of cost overrun, but we have no way to know why. And therefore we have no way to know how to fix this symptom. Just that we've observed it. But can't fix it.
To start to apply Root Cause Analysis, here is an introduction to the method we use on our Software Intensive Systems.
Root cause analysis master plan from Glen Alleman
In June 2016, John Wiley & Sons will releaseÂ released my “new” book Managing for Happiness, which is a re-release of last year’s #Workout book. Some people asked me questions about that.
Why do you re-release the #Workout book with a publisher?
My aim is to be a full-time writer. That means I must sell more books so that I can earn a full income from writing. (Right now, I don’t.) A global publisher can help me with that. A second reason is that I want to reach as many people as possible with my message of better management with fewer managers. A third reason is that wider availability of the book (in bookstores and libraries) is not only good for new readers but also for my reputation as a public speaker.
A colleague asked mobbing last week on Twitter. Here’s the short answer, including pairing so you can see everything in one place:
A WIP limit of oneÂ means the team or pair works on just oneÂ story/feature at a time. Sometimes, that feature is large as in the team who worked as a swarm on very large stories. (See the postÂ Product Owners and Learning, Part 2Â for how one team finishes very large features over a couple of days.)
Here are some examples of what I’ve seen on projects.
Team 1 swarms. They get together as a teamÂ and discuss the item (WIP limit of 1) with the product owner. They talk among themselves for a couple of minutes to decide on their “plan of attack” (their words) and then scatter. The testers develop the automated and take notes on the exploratory tests. The developers work on the code.Â
Aside: On another team I know, the UI, platform, and middleware devs get together to discuss for a couple of minutesÂ and then write code together, each on their own computer. (They collaborateÂ but do not pair/mob together.) On another team, those people work together, on one keyboard for the platform/middleware work. The UI person works alone, checking in when she is done. Everyone checks their work into the code base, as they complete the work. Teams develop their own “mobbing” as sub-teams, which works, too.
Team 1 has an agreement to return every 25 minutes to check in with each other. They do this with this kind of a report: “I’m done with this piece. I need help for this next piece. Who’s available?” Or “I’m doneÂ as much as I can be for now. Anyone need another pair of eyes?” (Note: you might want more or less than 25 minutes. They chose that time because they have smallish stories and want to make sure they maintain a reasonable pace/momentum.
As people finish their work, they help other people in whatever way they can. Early in Team 1’s agile days, they had a ton of automated test “technical debt.” (I would call it insufficient test automation, but whatever term you like is fine.) The developers finished their stories and helped the testers bootstrap their test automation.
Team 2 mobs. The entire team sits around a table with one keyboard. The monitor output goes to a projector so everyone can see what the person typing is doing. This team has a guideline that they trade off keyboarding every 15 minutes. (You might like a slightly longer or slightly shorter time. In my experience, shorter times are better, but maybe that’s just me.) Sometimes, the tester leads, developing automated tests. Sometimes, the developer leads. This team often uses TDD, so the tests guide their development.Â
Team 2 checks in at least as often as they change keyboarders. Sometimes, more often.
Notice that the work in progress (WIP) is small, one story. In both swarming and mobbing, the teams work on one story. That’s it. Their focus is doing the work that gets that story to done. that story getting to done.
Pairing is one keyboard, one machine, two pairs of eyes.The keyboarder is the driver, the watcher is the navigator. You get continuous review on the work product as you proceed. I often ask what I consider “stupid” questions when I am the navigator. Sometimes, the questions aren’t stupid—they prompt us as a pair to understand the item better. Sometimes, they are. I’m okay with that. I find that when I pair, I learn a ton about the domain.
Here’s the value of swarming or mobbing:
If you work feature-by-feature, I urge you to consider swarming or mobbing. (Yes, you can swarm or mob in any life cycle, as long as you work feature-by-feature.) Either will help you move stories to done faster because of the team focus on that one story.
I wrote a post about pairing and swarming and how they will help your projectsÂ a couple of years ago.
The question of the viability of #NoEstimates starts with a simple principles based notion.
Can you make a non-trivial (NOT de minimis) decision in the presence of uncertainty without estimating?
The #NoEstimates advocates didnâ€™t start there. They started with â€śEstimates are a waste, stop doing them.â€ť Those advocates also started with the notion that estimates are a waste for the developers. Not considering those who pay their salary have a fiduciary obligation to know something about cash demands and profit resulting from that decision in the future.
The size of the â€śvalue at riskâ€ť is also the starting point for estimates. If the project is small (de minimis) meaning if we over run significantly no one cares, then estimating is likely a waste as well. The size of the project, whether small or multi-millionâ€™s doesn't influence the decision to estimate. The decision is determined by â€śvalue at risk,â€ť and that is determine by those paying NOTÂ by those consuming. So the fact I personallyÂ work on larger projects does not remove the principle of â€śvalue at risk.â€ť AnyÂ clientâ€™s (internal or external) V@R may be much different than my personal experienceÂ â€“ but itâ€™s not our money.
Next comes the original post from Woody â€“ â€śyou can make decisions with No Estimates.â€ť If we are having a principled based conversation (which NEâ€™er donâ€™t) then that statement violates the principles of Microeconomics. Making decisions in the presence of uncertainty (and Iâ€™m assuming all projects of interest have uncertainty), then estimates are needed to make decision. Those decisions are based in MicroEcon on the Opportunity Cost and the probability of making the best choice for the project involves assessing the probability outcome of those choices, estimating is required.
Real options isÂ a similar process in IT based on estimating. Vasco stated long ago he was using RO along with Bayesian Decision Making. I suspect he was tossing around buzz words without knowing what they actually mean.
From the business side, the final principle is Managerial Finance. This is the basis of business management of its financial assets. The balance sheet is one place these are found. Since the future returns from the expenses of today and the â€śpotentialâ€ť expenses of the future are carried in that balance sheet, estimating is needed there as well for the financial well being of the firm.
These three principles Value at Risk, MicroEconomics of Decision Making, and Managerial Finance are ignored by the NE advocates when they start with the conjecture that â€śdecisions can be made withoutÂ estimates,â€ť and continue on with â€śestimates are a waste of developers time, they should be coding not estimating.â€ť
Itâ€™s the view of the world, that as a developer â€śitâ€™s all about me.â€ť Never looking at their paycheck and asking where did the money come from. Thatâ€™s a common process and one I did when I started my career 35 years ago as a FORTRAN developer for Missile Defense radar systems and our boss had us takeÂ out our paychecks (a paper check in those days) and look at the upper left hand corner. â€śThat money doesnâ€™t come from the Bank of America, El Segundo Blvd, Redondo Beach, it comes from the US Air Force. You young pups need to stay on schedule and make this thing work as it says in ourÂ contract.â€ť
In the end, the NE conversation can be about the issues in estimating and there are many - and Steve McConnell speaks to those. I work large federal acquisition programs â€“ Â IT and embedded systems. And many times the â€śover target baselineâ€ť root cause is from â€śbad estimating.â€ť But the Root Cause of those bad estimates is not corrected by NoÂ Estimating as #Noestimates would have us believe.
As posted on thisÂ blog before and sourced from the Director of â€śPerformance Assessment and Root Cause Analysis,â€ť unanticipated growth in cost has 4 major sources:
1. Unrealistic performance expectations â€“ that will cost more money.
2. Unrealistic cost and schedule estimates â€“ the source of poor estimating.
3. Inadequate assessment of risk and unmitigated risk exposure.
4. Unanticipated technical issues.
Research where I work some times (www.ida.org) has shown these are core to problems of cost overruns in nearly every domain from ERP to embedded software intensive systems. It is unlikely those 4 root causes are not universal.
So whatâ€™s #NoEstimates trying to fix? They donâ€™t say, just â€śexploringâ€ť new ways.â€ť In what governance frameworks? They donâ€™t say. They donâ€™t actually say much of anything, just â€śestimates are waste, stop doing them and get back to coding.â€ť
As my boss in 1978 reminded us newly minted Masterâ€™s degreed coders, â€śit ainâ€™t your money itâ€™s the USAFâ€™s money, act accordingly â€“ give me an estimate of this thing youâ€™re building can be used to find SS-9â€™s coming our way?â€ť Since then Iâ€™ve never forgotten his words, â€śbusiness (in that case TRW) needs to know how much, when, and what, if itâ€™s going to stay in business.â€ť
Sitting in our seats at last night's Rockie v. Phillies game and dawned on me the analogy betweenÂ MoneyballÂ strategy and good management of software development. InÂ Moneyball, Billy Beane was faced with a limited budget forÂ players. Â He hired a statistics guy and they figured out theÂ getting on base was just as important asÂ hitting aÂ homerunÂ and a hell of alot cheaper.
Last night there were a few home runs. But most of the action were singles and a few doubles. If you do the simple minded math, when the rotation all get singles with batting averages of 0.303, then there'll be runs scored every inning. 4 singles equals a home run. Getting on base is the key to winning games.
Getting incrementally more software out the door - assuming it's the right software needed by the customer and that customer can put the software to work - then progress toward the win is being made.
So the Strawman of Waterfall and Big Bang is just that a Strawman. The Straw Man of No Projects is also nonsense, along with No estimates. The manager of the Rockies has a plan in the presence of uncertanty and emerging situations. That's why he's called theÂ MANAGER because he manages in the presence of uncertainty. And in doing that job he makes estimates on the probability of success of the emerging play options.Â
We can learn a lot from Baseball about managing projects. FirstÂ get on base.Â You can't score unless you're on base. First, Second, Third, then Home. You can't count on hitting Home Runs to win the game. It doesn't work that way. Offense of good, but so is defense. Managing the risks is defense. Defense in baseball is more than just putting players on the field. It's how those players react when the ball is hit.Â Go for the out at first? Try for a double play? Hold the ball after a single bounce in the outfield?
While baseball is not a contact sport, it still requiresÂ teamwork. I played competitive Volleyball inÂ College - the ultimate Team Sport, since you're only as strong as the weakest player. Much like theÂ software development team. But all teams have a strategy, aÂ game play that changes as the game emerges and most of all - as Peter Kretzman has lambasted some NE advocates who have not likely ever played baseball - all the players are making estimates all the time in order to catch the ball, keep control of the ball and the emerging situation of the game.
There appears to be a resurgence in the No Projects conversation, similar to the No Estimates notion that has been around for awhile.
Iâ€™m going to suggest that most of the disconnects around ideas of software development â€’ from No Estimates to No Projects to whatever â€’ starts with Developers and the assumption Itâ€™s their money. Itâ€™s not their money. If it is they can do with it as they please, no one cares.
There are standard business accounting processes in any business that creates products or services -- including Software -Â for money. Unless the developers are Staff Aug (just labor) to another firm, the accounting processes are defined in several places. FASB 86, FASB 10, even GAAP for capitalization and expenses of the cost of developing that product for use internally and for sale externally.
Here'sÂ a start â€¦
The separation of Products from Projects at the software development process level is understandable. I work a Program that has both. Both for good reasons for both. A Product Line enhancement is usually on continuing systemÂ â€“ Version 9 of a legacy system is a Product Line extension of a system that as be in place for 11 years. A â€śnewâ€ť productâ€ť Version 1.0 in the same domain is treated as a Project. The Project is to establish Version 1.0 which will then be extended over its life.
If the No Projects approach goes that same way as the No Estimates approach, those paying for the work will be intentionally excluded from the conversation. When I asked one of the originators of the #NoEstimates conjecture toÂ go check your idea with the CFO, I got silence.Â
Follow the Money is advice I received from my colleague â€“ former NASA Cost Director
This is good advice for any anyone proposing anÂ initiative that pretends to change the status quo, tilt at the windmill of supposed bad management, or any suggestedÂ evil as seen by those spending the money provided by someone else. Remember this when making suggestions...
It's not Your Money, act accordingly. Your opinion should be considered as appropriate, but it's not your money. Those whose money it is have a fiduciary responsibility to spend it in a manner compliant with the accounting principles of the firm, be that private or public.
I work on Agile software development programs. Most everyone in Boulder Colorado works on Agile development programs. We meet once a month or so for coffee and talk about Agile. We have formal MeetUps hosted by local vendors - Rally, Scaled Agile, and other agile development shops.
The range of projects at our morning coffeeÂ clutch go from one man shows to multi-billion dollar space flight programs and back again. There are times when we get pissed off at each other for all the right reasons - this is theÂ big ended littled endedÂ argument of Gulliver's Travels that was actually an argument about the bit order in microprocessors when the 32 bit machines started with floating point calculations -Â Holy Wars and a Plea for Peace.Â When I was working on embedded systems and we had to choose a 32 bit machine for our new signal processing system, we got in huge fights about how the floating points software was going to be moved over to the floating point hardware.
So the question isÂ what are the shared principles across aÂ broad range of projects, business andÂ technicalÂ domains. Here's some background on the domain I work and the applicationÂ of Agile in that domain. I'm speaking at the Boulder Agile MeetupÂ July 27th if anyone is interested in hearing about Agile in Government.
Here's some background on Agile in the domain I work
Typically these are also Software Intensive System of Systems. Here's some background on those
So when we hear something aboutÂ exploring new approaches, ask first -Â in what domain have you tested that idea? By what Principles can that new idea be accepted into a domain outside your domain? Is there any evidence that your new ideaÂ canÂ workÂ outsideÂ yourÂ personalÂ experience?Â How would I testÂ yourÂ idea before spending my customer's money? WhatÂ would be those test cases?