Scrums.com https://www.scrums.com

This episode of The Next Biz Thing turns its attention to Scrums.com, a Software Engineering Orchestration Platform that has spent fourteen years working on why software delivery remains so unpredictable. Markus J. Diplama walks through how the company unifies AI engineering agents, managed delivery squads, pre-vetted talent across more than a hundred technology stacks, cloud provisioning and DORA based analytics into one system, and why its outcomes based billing model signals real confidence. The episode also looks at the company’s African delivery hubs and what its approach suggests about the wider re-bundling of business software. Well worth a listen for anyone whose business depends on shipping software.

There is a question that quietly haunts almost every company building software today, and it is not the one you might expect. It is not whether artificial intelligence will change engineering. That argument is settled. The real question, the one that keeps chief technology officers awake, is far less glamorous and far more practical. It is this: why, after decades of better tools, faster machines, and smarter people, is shipping software still so unpredictable?

Welcome back to The Next Biz Thing. I am Markus J. Diplama, and this is the show where we go looking for the companies that are not simply riding a wave but actually reshaping the water underneath it. Every episode, I pick one business that is doing something genuinely interesting in its corner of the world, and we spend some time understanding what it does, why it matters, and what it tells us about where an entire industry is heading. Today we are heading into the world of software engineering, and specifically into a company that has spent fourteen years trying to answer that unpredictability question. The business is called Scrums dot com, and their tagline is about as direct as taglines get. Software Engineering. Sorted.

Let me set the scene, because I think the context here is what makes this story worth your time.

If you have ever been near a software project, you know the pattern. A company decides it needs to build something. It hires developers, or it hires an agency, or it does both. It buys a project management tool, and a code repository, and a continuous integration service, and a cloud provider, and a monitoring platform, and an analytics dashboard, and somewhere along the way it realises that it now owns roughly fifteen different systems that do not talk to each other particularly well. Meanwhile the actual work happens somewhere in the middle of all that, and nobody can say with confidence when it will be finished. Estimates slip. Bottlenecks appear from nowhere. And the person paying the bills is left with the uneasy feeling that they are funding a process they cannot see.

Scrums dot com looked at that mess and made a bet. Their bet was that the problem is not the developers, and it is not the tools individually. The problem is fragmentation. So rather than sell you another point solution to bolt onto the pile, they built what they call a Software Engineering Orchestration Platform, and they use that phrase deliberately, because orchestration is exactly what they mean. One place where AI agents, human talent, delivery teams, tooling, cloud infrastructure, and delivery operations all live together and, crucially, all inform one another.

Now, I want to be careful here, because platform is one of the most overused words in business, and it usually means very little. So let me tell you what it actually looks like in practice, because the specifics are what convinced me this was worth an episode.

There are AI powered engineering agents that take on the automatable parts of the workflow, the repetitive scaffolding and checking that eats a developer's afternoon. There are managed delivery squads, which is to say fully assembled teams that come to you already knowing how to work together rather than being introduced on day one and hoping for chemistry. There is a talent layer, where you can hire pre vetted engineers across more than a hundred technology stacks, which is a genuinely large number when you consider how specialised modern engineering has become. There is cloud infrastructure provisioning built into the same platform, so the environment your code runs on is not a separate procurement exercise. And sitting across all of it, there is a developer analytics layer built on DORA metrics, which for those outside the field are the industry standard measures of how well a software team is actually performing.

That last piece is the one I find most interesting, and I will tell you why. Analytics in software delivery has historically been retrospective. You find out that a project was late after it was late. What Scrums dot com is aiming at is something closer to predictive. Real time engineering visibility with bottleneck detection that flags the problem while there is still time to do something about it. That is a meaningful shift in posture, from reporting to steering, and it is only possible because everything is running through one system rather than scattered across a dozen.

There is another detail in how they operate that I think deserves a moment, because it says something about their confidence. They bill on outcomes rather than hours. Anyone who has worked in professional services will understand immediately why that is unusual. The billable hour is the safest possible business model for a supplier, because it transfers all the risk of inefficiency onto the client. Moving away from it means you are betting on your own ability to deliver. Companies do not make that bet unless they believe their process holds up.

So who is actually using this? The client list is, I have to say, more impressive than I expected before I started digging. BDO. Huawei. Volkswagen. Nedbank. Investec. Naspers and Prosus. Nivea. IAG. Network International. These are not experimental pilot customers. These are large, conservative, heavily governed organisations that do not hand their engineering to a supplier casually.

And the testimonials line up with that. A chief technology officer at Massmart, part of the Walmart group, described the team members as high impact, hard working, and always available. That last word, available, is doing quiet work in that sentence. Anyone who has managed distributed engineering knows that responsiveness is often the difference between a good partner and a frustrating one. From Volkswagen, a customer experience specialist noted that the team often pre empted solutions and enhancements, meaning they were not just executing tickets but thinking ahead of the brief. That is the behaviour you want and rarely get.

The numbers the company reports are equally worth noting. Three times faster delivery than the industry average. A two hundred percent productivity improvement. Ninety four percent client renewal rate. That renewal figure is the one I would pay most attention to if I were evaluating them, because in services, renewal is the only metric that cannot really be dressed up. Clients who are unhappy leave. Ninety four percent of them staying is a strong signal about lived experience rather than marketing.

They also run across five delivery regions, with presence in the United States on both coasts, in London for Europe, and across Africa with hubs in Cape Town, Johannesburg, and Nairobi, and they report platform uptime of five nines, which is the sort of figure infrastructure people quote when they want to be taken seriously. And the company has been at this since 2012, which in software terms is a long time. Fourteen years means they have lived through several complete shifts in how engineering gets done, from the rise of cloud to the arrival of ge...