It's common to hear, projects are overhead, we just need to get the value to the customer as fast as possible. This seems to be a lament from agile developers. Anything getting in the way of the coding is seen as an impediment.
Here's a little story.
Long ago (1978) in a land far away (Redondo Beach) I too wrote code and continued to write code for a decade or so after that. This code was for a Missile Defense system - Cobra Dane and a few satellites that supported it. My boss was a crusty engineer with a long history of delivering products to the DOD that showed up on time and on budget and worked as needed in the defense of the nation. When us young pups arrived to move the development processes into the next century (minicomputers, high-level languages, integrated development environments) from the previous generation of punching holes in pieces of paper - either card stock or rolls of paper tape - we thought we were clearly superior to those of the past generation and were proud to tell anyone who would listen how we had a lock on what to do best.
After tolerating our attitudes for a few months - and it was good work which is why we were hired and continued to work there for many years - Fred had a little talk with us. It was clear many years later, he was a good development manager and waited for the appropriate time to coach and mentor us. In those days we got a paper paycheck and took it across the street to the Bank of America and deposited it every other Friday. The checks were handed out in envelopes by Fred personally.
Take out your paycheck boys (very few women in those days, although my next boss - Carol - was one of the best) and look in the upper left-hand corner. It says Bank of America and the name of our company (TRW). Well, I just want to clear up a misconception here. That's not where that money comes from. The money on that check comes from the United States Airforce. The Bank of America is just holding it until you cash it. It's the United States Air Force that pays your salary and mine, and the United States Air Force wants us to do our work in the way they want, not the way you want or the way you think they want you to spend it. Or Worse yet, the way you think they should be spending it. So please consider that the next time you get some cockamamy idea that your way of doing things is better than the United States Air Force thinks you should do it. It's their money. For sure make those suggestions to the Contracting Officer and Chief Engineer and they'll assess those ideas for their usefulness. But It's Not Your Money.
He liked to emphasize the full name of the customer, point out the blue suiters walking around Building O6 in Redondo Beach, not as just customers, but US Air Force customers. I work in that same domain 30 years later. Eat lunch with uniformed staff, shop at noon with stores containing uniformed personnel, stay at hotels, where uniformed personnel are eating. It's a unique environment. but one where Process is King since the money for our work comes from a sovereign.
That was a long story, so here's the point
The notion that process and overhead are a waste is true in some sense in all domains. The question is who gets to says what is waste and what is needed governance?
Too much process, too much overhead is a waste. But it's not your money so process and overhead are part of spending that money. And most of all, the amount of process and overhead is not likely your decision unless that decision has been assigned to you. This is how business works.
A Scrum of people works very well when doing Scrum, but operations, finance, and accounting are not the same as writing software for money. A Scrum of cost accountants, planner, finance, and operations people is called Chaos. It works for coders, not so much for others.
Projects are operational, financial, and accounting vehicles for managing and keeping track of that money. What I learned from Fred was this...
Without an understanding of where my paycheck came from, how the customer's money was turned into salaries, those salaries turned into products, and those products turned into revenue, we (all us young pups) were going to continue in our roles of being just labor.
In those days, TRW sent a few of us back to school (MS, Systems Management, USC) to learn how to put to work the words in the book of one of the founders of our little firm, The Management of Innovative Technological Corporations, Simon Ramo, who was the R in Thompson, Ramo, and Woolrich.
There doesn't seem to be many Fred's in the world of the internet. They're still there at my clients. It's a Value at Risk thing in my opinion.
If you hear #NoProjects, #NoManagement, #NoEstimates, #NoPlans and the people saying that are at a firm making a good margin on millions of dollars of revenue good for them.
But ask how they submit the month end financial report to the investors or stockholders. You may find out they account for all that money in some form of a project - finite bounded set of work that converts cost into revenue and what's left is profit. That those numbers are assigned to discrete buckets of cost, revenue, and project and they call that a project since it's a handy way to keep all the money from getting all mixed up.
Another Myth in Today's World
There is another myth in today's world - that iterative and incremental is somehow a new invention. It's not. We were doing iterative and incremental in the 1970's and 1980's
