Predictability In Software Delivery? Great!
Predictability-In-Software

But, please lose it now.

Why would I ever lose predictability in my software delivery, which has taken me years to get to? That is the exact reason I was recognized in my organization and also promoted to lead the delivery teams. This is the peak where I could rest on my laurels, increased perks and the title I eyed for so many precious years of my professional life. Time as hard a teacher as it can be at times, soon made me realize, though, what got me here was not enough to get me across the new age digital chasm. The industry had moved fast. Digitization had been quite disruptive.

My business sponsor was happy that I can commit and stay largely faithful to my commitments. This predictability was a huge leap as compared to my predecessors, who struggled to stay even within limits of their high-level ranges and were usually off by a factor 50%+. In any regular business which was supposed to bring revenue in with a healthy bottom line, my track record of meeting my commitments with a relentless focus on quality was welcomed with open arms.

It came at a cost, though, I was just a more detailed oriented and experienced manager who thought of every small thing that could go wrong and then intelligently built padding in my WBS (Work Breakdown Structure) line items and which gave me a lot better chance to succeed. However, as an organization whose promise was to deliver excellent products to our clients and client’s clients quickly, I was making them (even though unknowingly) slower.
We were starting to lose our market share and our large customers, including some known big names, were tumbling down on the charts year on year. We were known for one of the highest delivery success rates in the industry, but when “success” is defined in contracts as delivering to agreed long-range timelines and within agreed costs, it was not meant for the always-on digital world, which was rather hungry for speed.

New technology inventions were being applied and in so many different ways that while we were busy creating power points and detailed excel (ok, we did move on from Microsoft Project) plans with hundreds of assumptions and dependencies, there were small teams of young developers putting functional products in our customers’ hands. Yes, the first version of those products were not great and not perfect as our teams would have produced, but those products worked and fulfilled an immediate need!

So, my empire was being challenged. A large number of specialist technology component teams I had groomed and developed over the years to match my perfect multi-tiered solution were under threat.
My initial reaction to this change was to externalize the problem – “My delivery is perfect, and my record proves it, the problem is with your ideation process. Business owners just take too much time crystallizing their thoughts.”. Yes, people spending a considerable amount of time on ideation and refinement had been and was an issue, but as it appears was not the biggest constraints on our concept to cash flow of work.

When that didn’t work, I tried hiding behind my team’s skills – “Industry has changed rapidly, we need fresh blood with newer skills and re-train our existing workforce”. Of course, that was an issue and people needed to sharpen their saw and become relatively full stack as compared to the specialization silos they had gone into for the last few years. We could break the component teams down to some extent while could not eliminate them altogether. That helped and the teams now looked more self-reliant and surprisingly happy but didn’t seem to have any marked change in the real speed to market.

When slowness became quite apparent – my last desperate attempt was to jump on tools and engineering bandwagon. That is one trick which usually works and keeps people if nothing else wondering for some time. Large LCD screens with graphs and traffic lights, numerous confusing metrics pushed the critics away and once again I made it to “the list” at the end of the year. “Guys learn from that team – they have a perfect PM tool implementation, excellent information radiators across the team area, complete CI process, builds on every check-in, deployment, multiple times a day, build break hooters (or lava lamps?), automated unit tests and coverage reports, Etc. Etc.” My steering committee reports looked full and green. I was back in the game.

While it helped, it didn’t last long. We were a little faster in coding and identifying issues, we had fancy looking monitors, and we did introduce a few additional feedback loops, but clients were still suffering from the increased cost of delay and in cases missed opportunities. We still had big numbers being added up from detailed top-down estimates and long plans, which they were now refusing to buy and even if they did, they soon realized they had to cut down key features to keep it viable.

While we were busy negotiating scope with them, there was someone else putting a product increment in the hands of their customers. Pipeline dwindled, numerous smaller external players from different geographies entered the fray for most work we were doing and then someone somewhere took notice. CxO’s were fired, entire structure shaken-up and numerous layoffs in almost all teams. “We just had to keep the cost down and reduce weight to move faster,” we were told. Was I responsible for that, even if partially? If yes, where did I go wrong?

I in this story could be me, and if you are managing programs and portfolios with yesterday’s approach, it could very well be you or that delivery leader in the corner cabin. Nothing wrong with my intentions or of all of these people really, but I think while they were busy bringing predictability and control to software deliveries of mostly automation kind of projects, they failed to notice the slow change to innovative and complex nature of the products their teams were being asked to build. Underlying business in the digital world had changed, but our tricks of the trade remained the same. Moreover, even if they did change, they were improvisations at best.

As Jurgen Appelo says in his book Management 3.0 – “If predictability is the friendly and reliable son of the neighbors next door, complexity is his unfathomable and unruly little sister.” But she is the digital native which goes places and eventually wins. I, in this story, was slow in embracing this complexity and associated uncertainty. I was slow in empowering my people and letting them experiment. I knew probe-sense-respond or quick small increments was the right answer to such complex problems, but I just couldn’t ever have the courage to lose control beyond the realms of a strict plan which was driven out of detailed commercial and resource models. I committed hard scope & estimate numbers to my sponsors and believed agility is something which only happens among developers in a Scrum team. I was too eager to show I was on top of things and in control. Failing to realize, that embracing uncertainty, flexing plans, trusting & empowering people and letting off the cost constraints was really the only way to deliver useful product increments in the hands of the customer and hence the basis of creating lasting value in the new digital world.

Are you me? Or, are you the organization which gives rise to managers like me, since you value predictability more than you value the ability to change direction quickly? If you are lucky, there might still be some time left to change.

Leave a Comment