Monkey and Vine

A wise sage once introduced me to the principle  of  “the monkey and the vine”: you never let go of the vine you holding until you have fully grasped the next one that is going to keep you from crashing to the ground.

Say what you will about project management and project oriented delivery of software, at least they had a coherent framework to measure success.

On Time, On Scope and On Budget was at the very least, a rational basis to evaluate software investments from a business perspective. Never mind, that it actually is a terrible way to build software.

To the credit of the folks operating that way, there was plenty of data available by the late nineties to show that based on those criteria, 80% or more software projects that aimed to optimize on all these three dimensions were failures.  And people were hungry for better ways of delivering software.

It was a great opening for us engineers to come along and give businesses another option on how to build software. After all, what is the Agile Manifesto, other than engineers, who actually understood why project based delivery was a failure on the ground, the place where ideas get turned into shipped code, providing businesses with better, more reliable options for how to deliver software in more economically efficient ways?

But unfortunately, we only did half the job. We expected businesses to fill in the gaps on how adopting these techniques would translate to business outcomes and success. We gave a whole new set of ways in which we could work to deliver software, claimed they were superior but never took upon ourselves the hard job of replacing "On Time", "On Scope" and "On Budget" with something better.

We left that as an exercise for the reader, convinced that the obvious superiority of our new methods would be all that was need to foster change. Or worse foisted things like story points and velocity on the industry to deflect attention from the topic.

Even after 20+ years of Agile, we talk a lot about “measurable outcomes” and “fast feedback” as being the selling points for our “new ways of working”, but there is very little by way of theory, quantifiable data, or falsifiable measurements that can conclusively replace “On Time”, “On Scope”, and “On Budget” as meaningful replacements for an investment framework for software development - and in the real world, all this does come down to money and ROI at some level, however much we like to pretend it is otherwise.

So if we think our “new ways of working” are truly revolutionary, we also need to come up with new vines that decision makers can grasp on to invest in software development rationally.

Hiring “digital native” managers, moving from project based budgeting to stable value streams and product based budgeting, rearranging team topologies for fast flow, retooling engineering processes to deliver software continuously, etc.. are all just tactical steps that when run without any overarching way of quantifying what the expected success metrics for an “agile transformation” are.

We need something as clean and unambiguous  as the old way for determining how doing all this work impacts the bottom line for the business.

I fear that without a credible replacement for On Time, In Scope, On Budget, every attempt at adopting our fancy new techniques in a business context at any scale, will devolve  into project management by some other name.

We can derisively call it “waterfall”, but that does not solve the problem, until you can *prove* that “Agile” is meaningfully better and that all the investments in agility are not merely rearranging the deck chairs, but will lead to meaningful returns on the investment.

It drives us crazy as engineers and agile advocates that SAFe is as successful as it is. "But that’s not agile, its waterfall!", we cry, as Scaled Agile walks away with a third of a billion dollars in the bank.

Well maybe it’s because 30% more on time, 20% closer to budget and 50% of original scope is a lot more concrete and meaningful quarter by quarter than "we guarantee a fast flow of value".

Modest failures are better than abject failures, I suppose, and if an impure form of Agile gets those kinds of results, I know of very few business owners who are not actually software developers who won’t take it any day of the week.

I am an engineer first, and I passionately believe all these “new ways of working” actually work, because in over 30 years of developing software, nothing else compares to the sheer joy and efficiency of  shipping working products with fast iterative feedback from the market.

And the fact that the best technology companies in the world use these ways of working without really even bothering to name them as such or navel-gaze about terminology or theory, should be proof enough that from a technical perspective this is the way to go.

But we engineers need to get our heads out of the sand and get engaged much more actively in coming up with better and more standard ways of translating what we do into tangible economic value when dealing with non-technical stakeholders or working with enterprises that are culturally not attuned to the obvious benefits of the methods we propose.  

Or else we are going to be relegated to being eternally frustrated like Abe Simpson.