This post started with an entirely different approach.
I wanted to rant about how some statements of work are written with absolute certainty based assumptions, and when those assumptions are proven wrong the work still proceeds with the obligation of fulfilling the SOW, resulting in lot of wasted effort spent on things that do nothing to further the goals of the enterprise. These same SOWs are also written with the absolute certainty of how much time it will take to do the job, so the time spent on the useless parts robs from the time available to work on what will make everyone’s life easier for the next SOW…provided history doesn’t repeat itself.
Instead, I got caught up in mangling metaphors and exaggerating erroneous errors and wound up writing the following, which somehow represents the point I was trying to make. To me, at least. Apologies in advance if it’s not as good for you.
Waterfall methodologies like RUP ruled the enterprise IT landscape back when it was mostly green fields, and that made sense. Projects were funded based on clear goals where the ROI had already been calculated. That ROI was calculated based on a set of business goals that were frozen once the project got the green light (yes, I know that scope creep existed even back when dinosaurs roamed the server rooms, but stick with me and then tell me if it really matters for the purpose of illustration). These goals were numbered 1 to n, then a person or a team (project sizes and budgets varying) would write functional requirements (FR) that meet those business requirements, numbering them 1.1 to n.∞. And then there would be development tasks, and test cases, all of which must have a compatible numbering systems, and each must tie back to one (and only one) functional requirement. Life was simple, and project schedules were measured in years. For some, enough years to add up to more than a decade.
Even when Pmanagersaurous (the p is silent) ruled the cube halls, there were businesses (and even some rebellious departments within enterprises) that used a different approach. To those who kept getting their ties caught in printers spewing out detailed requirements to be bound, distributed, and shelved, this alternative method seemed like some cavemen cracking their knuckles and banging on keyboards, intent on creating fire or agriculture or quantum computers. Much of what they built has gone the way of GeoCities and MySpace, but some of it went the way of either owning or replacing the big companies with the big projects and the big budgets. And they taught others their secrets. So many that it stopped being secret.
Then the legacy companies decided they wanted some of this high-margin, low-cost, no-longer-secret sauce for themselves, so they hired agile coaches. Of course, the ones that were really good at doing agile were off doing agile and becoming rich and famous. So the coaches would sometimes wing it, or steal from other processes to differentiate themselves. The legacy companies, being legacy, would pay the coaches lots of money, and thank them profusely, and then start requiring a business case before green lighting an “agile” project. The business cases had numbered paragraphs, and the business leaders wanted to know how things were going every moment of the day, so they insisted that the paragraph numbers be included in the “stories”, and it was Epic.
The little agile companies merged with competitors and became big legacy companies. To compete with even bigger legacy companies, they hired their executives, who needed to know everything that was going on so they could “take it to the next level”. So all of the highly skilled, highly productive people began applying half of their skills and productivity in doing what they have always done best, and half matching numbers to lines of code. Working for the plan.
And then AI came along, but that is post of a different order.
© Scott S. Nelson
