Last year MySQL marked its 30th birthday, but with end of life for the current version (8.0) coming up next month and moves towards a community edition what does the future hold for the platform? We spoke to Peter Zaitsev, founder of database support specialist Percona, to discuss what MySQL users should be doing now and whether there’s still life in the old database yet. BN: MySQL celebrated 30 years of development in 2025 -- how important do you think this database is within the wider world of technology? Is it still relevant today? PZ: MySQL is still extremely important… [Continue Reading]

The following article originally appeared on Q McCallum’s blog and is being republished here with the author’s permission.

Generative AI agents and rogue traders pose similar insider threats to their employers.

Specifically, we can expect companies to deploy agentic AI with broad reach and insufficient oversight. That creates the conditions for a particular flavor of long-running problem, which in turn creates a novel risk exposure for both the companies in question and for anyone doing business with them. The bot and the rogue trader are able to inflict sizable, sometimes existential, damage to the firms that employ them.

The key difference is the scope: Rogue traders operate in investment banks, while agentic AI will be deployed to a wider array of companies and industry verticals. Agentic AI may therefore create a greater number of problems than rogue traders and put a greater amount of capital at risk.

I’m naming this risk exposure ROT—Rogue Operator Threat—and this document is a brief explainer on what it is and how to address it.

(I almost called it RAT, with the A for “agentic,” but then realized that it would apply to any kind of automated system. So I broadened the scope to “operator.”)

To set the stage, let’s take a trip to the trading floor:

Understanding the rogue trader

Rogue trader scandals follow the same storyline:

• A trader accrues losses due to bad trades.
• They hide those losses while placing new trades in an attempt to recover.
• The new trades also lose money, digging a deeper hole.
• Repeat.

This cycle continues until they’re caught, at which point the bank is sitting on a large loss (sometimes into the billions of dollars) and the trader faces legal repercussions.

The story of Barings Bank offers a concrete example. Trader Nick Leeson had been logging fraudulent trades, over a stretch of three years, in an attempt to cover his mounting losses. This only came to light when the Kobe earthquake shifted markets against his most recent positions and the losses were no longer possible to hide. Leeson’s £800M ($1.3B) hole drove Barings to bankruptcy just three days later.

This is when you’ll ask: How could a professional trading operation let so many bad trades slip through undetected? How could a trader falsify records? Aren’t trading floors high-tech operations, full of electronic audit trails?

And the answer is: It’s complicated.

Trading operations do keep records, yes. But no system is perfect. Each time a rogue trading scandal comes to light, it turns out that there were loopholes in risk controls. A sufficiently motivated trader—especially one desperate to hide their mistakes—found and exploited these loopholes, continuing their losing streak in plain sight until they could bring in real money to backfill the fake records.

That “until” never happened, though. Which is why their employers then faced financial, reputational, and sometimes legal troubles.

The AI agent’s ROT threat

Similar to a trader, an AI agent operates on behalf of its parent business and is given room to operate independently so it can accomplish its tasks.

The risk is that, in the rush to deploy agentic AI, these companies will likely grant the bots more leeway than is necessary. We’ve already seen cases in which bots have been able to delete emails and wipe a production database. And there are no doubt other stories that haven’t made it into the news.

Those issues were at least caught in real time. Companies facing ROT are exposed to additional longer-running problems in which the bot is able to accrue losses or inflict greater damage over an extended period. In those cases the problems will only be uncovered by accident and/or when it’s too late.

Consider, for example, an agent that creates false data records to reflect (nonexistent) sales orders. It’s possible for this to run until some external event, such as investor due diligence or a budget review, forces someone to double-check those records against reality.

Avoiding ROT: Mitigating the threat

How can you narrow your downside risk exposure to ROT? Preventative measures are key. Strong risk controls, narrow scope of authority, and monitoring can catch rogue operator problems long before they’ve metastasized into an existential threat.

In light of rogue trader scandals, trading shops have been known to tighten risk controls and also separate duties to create a system of checks and balances. (This inhibits traders from logging their own fake trades.) Companies also require traders to take time off, as fraudulent activity may surface when the perpetrator isn’t around every day to keep the system running.

Adapting these ideas to agentic AI, a company could monitor and limit the scope of the bot’s activity (say, requiring human approval to place more than 10 orders an hour). It could also periodically purge the agent’s memory so it doesn’t accumulate too many evolved behaviors, or swap in completely new bots to pick up where the previous one had left off. And per my usual refrain of “never let the bots run unattended,” this company could employ people to cross-check everything the bot does. Trust, but verify.

This will not prevent the AI agent from making mistakes. But guardrails and sufficiently frequent checks should limit the scope of the bot’s damage. As with the rogue trader, the ROT problem isn’t about a single error; it’s about letting the errors grow out of control, undetected.

Iryna Stelmakh: Fighting Agile Theater, When Organizations Adopt the Ceremonies But Not the Mindset

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

 

"Transparency can be uncomfortable, but without transparency, there is no real improvement." — Iryna Stelmakh

 

Iryna brings a challenge she calls "Agile Theater" — organizations that implement all the visible parts of Agile (the ceremonies, the boards, the terminology) while the underlying mindset remains unchanged. Decisions stay centralized, transparency is avoided, and problems are hidden. As she puts it: "Teams go through the emotions of Agile without actually benefiting from it."

 

But her real challenge goes deeper. Iryna shares a story about building trust with outsourcing clients. Five days into a new assignment on a project the company had worked on for over ten years, she received an email listing team members to be removed — with no explanation. It was a red flag: the absence of transparency signaled that the client relationship lacked the trust bridge needed for genuine collaboration.

 

Iryna's response was characteristically direct. She organized a call with stakeholders and discovered the client operated on quarterly budget cycles — these cuts could happen every three months. Instead of accepting the loss, she shifted the cut team members to other projects within the same account, turning the problem into an opportunity. A QA engineer moved to another project that needed one. A developer and two others got upsold into a team extension. Nobody ended up on the bench.

 

Then came the systemic fix: Iryna set up one-on-one meetings with each stakeholder across different divisions to stay informed in advance. Prevention over reaction — because, as she says, reactions cost more.

 

Self-reflection Question: In your current engagement, do you have direct relationships with the people who make budget and staffing decisions — or would a surprise email catch you completely off guard?

 

[The Scrum Master Toolbox Podcast Recommends]

 

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

 

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

 

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

 

Buy Now on Amazon

 

[The Scrum Master Toolbox Podcast Recommends]

 

About Iryna Stelmakh

 

Iryna Stelmakh is a Project & Delivery Leader and Agile Coach who helps leaders turn complexity into clarity. With 10+ years across US, Nordic, and Eastern European environments, she works at the intersection of business transformation and human systems, building resilient organizations and high-performing teams in complex contexts.

 

You can link with Iryna Stelmakh on LinkedIn.

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20260325_Iryna_Stelmakh_W.mp3?dest-id=246429

When you join Octopus, you get a great laptop and your choice from a range of docks, monitors, webcams, and input devices. You also get a home office allowance, which lets you upgrade your space and get 50% back. You may want a sit/stand desk, an awesome chair, and portrait lighting so everyone can see how delighted you are when they demo their cool new feature.

What we ask in return is that you set yourself up to do your best work. Invest in your brain, bytes, back, and buns, as Scott Hanselman put it. The essential idea behind this is that when you win, Octopus wins. We all win!

Yet you can throw a soggy cat at a conference, and the chances are it will splash someone from an organization with a completely different approach to developer experience. One that doesn’t value the sustainable delivery of their people’s best work. Why is that?

A fork stuck in the road

As we’ve seen in the software industry, silos are the source of all kinds of chaos. DevOps was created when someone realized the scale of the problem caused by having two teams with conflicting goals working on opposite sides of the same problem. Leaders whipped developers up for feature throughput and wanted to hold operations teams to account for reliability.

In hindsight, it’s obvious that this isn’t going to work, but we did it for decades. You can get halfway to DevOps just by aligning the goals. When both teams share the same target, they’ll work out how to get you the rest of the way.

If we zoom out on our organization, we’re likely to find a similar silo/goal conflict between engineering managers and the finance team. We ask the engineering manager to build a high-performing team, while we direct finance to spend as little money as possible. This structural incentive problem leads developers to get laptops and tools that someone has negotiated to be “good enough,” and trust me, they aren’t.

When you look at developer experience through a FinBoss lens, where finance and engineering managers align around the return on investment, you’ll find the optimal spend on developer tools shifts right rapidly.

FinCost organizations reduce costs through standardization, commoditization, and by delaying kit refreshes for as long as possible. They often spend less than $1,000 on a laptop without realizing the true cost of an under-spec’d machine. Meanwhile, FinBoss organizations are seeking the $30,000 annual return on a $3,000 investment.

To achieve this ROI, finance and engineering leadership work together to design policies that allow engineers to choose from a set of well-designed options. The combination of investment in great tools and individual choice in building the right setup is the path to success.

Tiny visible costs

FinCost organizations are driving decisions based on small, visible costs. Where there’s a paper trail, there are savings to make: the purchase of a laptop, the training budget, and the conference invoice. These are part of the legible model, so there is no guesswork or experimental method needed to cost them. The numbers are right there on the page.

Once you’re managing costs, it’s not uncommon to dial up the control, too. You limit options, standardize across the organization, and negotiate in bulk on everything to drive costs even lower. Compared to competitors, you could be spending 75% less on laptops, and just look at the savings from those pesky licenses and SaaS tools various teams were using. Hooray.

Instead of letting engineers attend conferences they find relevant to their work, the organization negotiates a bulk purchase for a single conference. Instead of teams buzzing with diverse ideas and approaches, they all sit and watch the same talk. It’s cheaper that way.

A wooden fence encloses my garden. A fence lasts a long time if you give it a protective coat of wood preserver every once in a while. A tin of wood preserve costs about $20 and a few hours of mindful application each year. Over 5 years, I can save $100 by skipping the treatment. If I do this, my fence lasts about 10 years instead of 30.

The cost of a tin of wood preserver is immediate and visible. The cost of replacing the fence is far higher, but it won’t be visible for years. Additionally, if the fence provides value beyond privacy, like keeping a goat out of my vegetable garden, the cost of the fence failing could be the cost of my whole crop, which is even less legible to my cost control mindset.

If you’re creating software, it’s likely to be more valuable than a fence. In fact, it should be giving you returns multiple times your investment. It’s like a golden goose. You feed it well, and you get regular, valuable deliveries. If you had a golden goose, you wouldn’t try to save on food costs if it reduced the flow of golden eggs.

The same logic plays out with training. A FinCost organization cuts the training budget because the line item is visible and the return isn’t. Individual engineers stop attending relevant courses, and teams miss out on the steady accumulation of skill that comes from ongoing, targeted learning. Nobody raises a purchase order for “capability that didn’t grow this year.”

Then something goes wrong. Delivery is slow, the codebase is a mess, or a competitor pulls ahead. Someone decides the answer is transformation, and that means Scaled Agile, or whatever flavor of desperation is in fashion in exec suites at the time.

So the whole department gets booked onto an external SAFe course. Not one or two people who need it. Everyone. The invoice lands, and it’s eye-watering: many times what a thoughtful, ongoing training program would have cost across the same period. The organization that was too cautious to spend $500 on a course people wanted just spent $50,000 on one nobody asked for.

This is the hidden tax of FinCost thinking. Small, visible costs get cut. The problems that those small costs would have prevented quietly compound. Eventually, the pressure releases all at once, in an expensive, rushed, and hard-to-argue-against way, because now there’s a crisis with a visible price tag.

The tin of wood preserver was the right investment all along.

The invisible people-hours

Developers work around 40 hours a week. Stripe’s Developer Coefficient found that productivity friction can eat up roughly half of those hours. That’s the time that evaporates before a single line of useful code is written. Across the global developer workforce, Stripe put a number on that loss: $300 billion. It’s worth noting that only $85 billion of this is attributable to bad code. The rest is pure friction: slow tools, broken environments, waiting for builds, wrestling with under-spec’d machines. Productivity means more than writing code faster.

That friction has a texture. It’s a developer losing flow because their laptop is thrashing memory, and they’ve lost the thread of what they were thinking.

It’s waiting 10 minutes for a build that would have completed in 2 minutes on a faster machine. It’s the workarounds you built because the approved tool wasn’t good enough, which obliterates hours of your week for maintenance. It’s the skilled engineers who start looking for a new role because the environment makes them feel like you don’t take their work seriously.

None of this appears on a purchase order. None of it shows up in a variance report. It just quietly drains the value your software could be creating.

There’s also an upside case, not just a loss case. Software that ships faster captures more market share. Developers who stay in flow write better code with fewer bugs, which means less rework and fewer incidents. A high-performing team attracts other high performers. The return on investing in developer experience isn’t just “we lose less time”; it’s sales opportunities, reduced churn, higher product quality, and a compounding advantage over competitors who are still buying $800 laptops and calling it responsible.

When you focus on cost control, there’s a ceiling on how much you can save. When you look for return on investment, there’s no equivalent ceiling on how much you can gain.

The CFO lens

When I asked Sammy, our CFO, about why we invest in people, powerful machines, and great tools, he said: “At Octopus, we think about equipment as a productivity tool. Developers are one of our most expensive and constrained resources. If spending a few extra thousand dollars on a fast machine and proper screen space saves time, reduces cognitive load, or keeps someone in flow more often, it pays for itself very quickly.”

That means our finance team doesn’t ask “What’s the cheapest laptop we can buy?” Instead, they ask, “What setup helps this person do their best work?” From a finance perspective, this is about a high-ROI spend, not indulgence.

Octopus is running the FinBoss playbook, which aligns finance and leadership in empowering employees to do their best work. That means expanding what you’re willing to measure so that you can balance the visible costs with traditionally invisible returns.

The responsibility for providing this environment for employees rests with all leaders, including Sammy, and is part of the deal employees have with the company; we’ll give you the best environment and tools if you give us the greatest work of your career.

The reckoning

If you’ve ever met, I’ve likely mentioned DORA’s research. I’m a super-fan of their State of DevOps reports, because they provide us techniques, practices, and outcomes that are all linked through complex relationships. The model shows that transformational leadership, lean product management, and Continuous Delivery drive software delivery performance and organizational outcomes.

While many of the capabilities in the DORA model are technical, many others relate to leadership. Particularly relevant to developer experience are generative organizational culture, transformational leadership, empowering teams to choose tools, team experimentation, and a learning culture. You can read about these and more on the DORA website. Together, they back up the FinBoss concept with tens of thousands of survey samples that support the case.

The question is: Which organization are you now, and which do you want to be? Is it FinCost, operating myopically against the bottom line, or FinBoss, sharing the responsibility for developer experience and employee productivity? The fork in the road was never a choice. We know FinCost is a dead end, and the benefits of FinBoss aren’t soft claims; they’re measurable outcomes.

Happy deployments!

Since Argo CD in Octopus was released in Early Access in 2025, we’ve been incrementally adding new features to make the integration even more useful. This blog post is a deep dive into the new step verification feature that lets you wait for the updated Argo CD applications to be healthy before the step in Octopus completes.

Step verification

Previously, Octopus would consider a step complete once changes were pushed to Git.

There are some new options in the step editor now that allow you to customize the behavior. The options are listed under step Verification:

• Direct commit: Progress to the next step once changes are pushed to Git (this is the existing behavior)
• Pull request merged: Progress to the next step once pull requests are merged, or fail the step if pull requests are closed or abandoned. This option results in a no-op if changes are committed directly without a pull request (see Git commit method)
• Argo CD application is healthy: Progress to the next step once all the Argo CD applications have synced the new changes and the applications are in a healthy state. Choosing this setting means your Octopus dashboard will accurately reflect the version and status of your applications deployed to the cluster

The task is paused while Octopus waits for pull requests to be merged or for Argo CD applications to be healthy. This means the task does not count towards your instance task cap.

Trigger sync

Turning on this option will trigger Argo CD to explicitly sync applications with the changes committed to Git by this same step.

If the application has auto-sync turned off, then triggering sync ensures Argo CD will look at the latest changes in Git when verifying application health.

If the application has auto-sync turned on, then triggering sync speeds up the deployment because Octopus does not have to wait for the next Argo CD refresh loop.

When is the application synced and healthy?

When verifying that the application is healthy after a change, we first need to check whether it references the changes we just made. Unfortunately, we can’t rely on Argo CD’s sync status alone, since Argo CD doesn’t know what Octopus’s intended changes are.

Let’s go through a few scenarios:

Scenario 1: All synced

1. Octopus commits 97A2
2. Argo CD refreshes to 97A2 and syncs the changes to the cluster

Sync status:

• Argo CD: In sync
• Octopus: In sync

This is the simplest scenario where all parties are looking at the same commit, so everyone is In sync.

Scenario 2: Out of sync

1. Octopus commits 97A2
2. Argo CD refreshes to 97A2 but has yet to sync the changes to the cluster

Sync status:

• Argo CD: Out of sync
• Octopus: Out of sync

Even though Octopus and Argo CD are looking at the same commit, the changes have not yet been applied to the cluster, so Octopus still shows Out of sync.

Scenario 3: Octopus is ahead of Argo CD

1. Octopus commits 8DEF
2. Argo CD has yet to refresh, so it still considers 97A2 to be the latest

Sync status:

• Argo CD: In sync
• Octopus: Git drift

In this scenario, Octopus has made a change that Argo CD doesn’t see yet. Here we introduce a concept called Git drift - this means even though everything looks up to date from Argo CD’s perspective, the changes made by Octopus aren’t in the cluster.

Scenario 4: External change overwrites Octopus-generated changes

1. Octopus commits 97A2
2. Another process commits 1123 with contents overwriting Octopus-generated changes
3. Argo CD refreshes to 1123 and syncs the changes to the cluster

Sync status:

• Argo CD: In sync
• Octopus: Git drift

This scenario also results in Git drift because a later commit overwrites Octopus’s changes - an example would be the user updating image tags that Octopus updated.

Scenario 5: External change is unrelated to Octopus-generated changes

1. Octopus commits 97A2
2. Another process commits 1124 with contents unrelated to Octopus-generated changes
3. Argo CD refreshes to 1124 and syncs the changes to the cluster

Sync status:

• Argo CD: In sync
• Octopus: In sync

This scenario is similar to the previous one, but here the later commit only contains unrelated changes - an example would be the user updating the replica count after Octopus updates the image tags. Since Octopus-generated changes made are still in the cluster, it displays In sync.

How does Octopus know what changes are intended?

Since Octopus pushed the changes to the Git repository, it can keep track of the intended changes.

The two Argo CD steps have different functionality, so the way they record the intended changes is different.

Update Argo CD Application Image Tags

This step updates the image tags in the manifests. To track changes, Octopus records JSON patches for the files it updates.

When detecting whether these changes have been overwritten later on:

1. Octopus checks out the Git repository files for the commit that Argo CD is looking at
2. Octopus re-applies the JSON patches to the files it previously updated
3. If the files have any changes, then it means Octopus’s changes have been overwritten

Note that JSON patches have limitations, so if the manifest has been significantly restructured, you might see an unexpected Git drift status. Simply redeploy to remove this false positive.

Update Argo CD Application Manifests

This step generates the manifests that go into the application’s repository. To track changes, Octopus records the file hashes it generates.

When detecting whether these changes have been overwritten later on:

1. Octopus checks out the Git repository files for the commit that Argo CD is looking at
2. Octopus checks if the file contents have changed by comparing the hashes of the files it generated
3. If the files have any changes, then it means Octopus’s changes have been overwritten

Does Octopus inspect the Git tree?

While planning this feature, we initially went down the route of inspecting the Git tree to figure out whether Argo CD was including the latest changes deployed by Octopus. We soon realised that we would need to inspect file contents anyway because a later commit could easily overwrite Octopus’s changes.

Other than some small optimizations to skip file comparisons when the commit SHA matches between Octopus and Argo CD, Octopus only looks at the file contents in Git; it doesn’t care whether the commit is in the Git history.

How to try it out

The step verification functionality is currently available to all customers starting with 2026.1. Pull request merged verification is available from 2026.2 (rolling out in Octopus Cloud).

There’s nothing extra required to enable the feature. Simply open the Argo CD Instances section under Infrastructure, and connect one of your Argo CD instances to Octopus. From there, you can start modelling deployments that combine GitOps and Continuous Delivery out of the box.

Conclusion

Argo CD is a powerful GitOps tool for Kubernetes, but it wasn’t built to manage the full software delivery lifecycle. Octopus complements Argo CD by adding environment promotions, orchestration across diverse workloads, fine-grained RBAC, and centralized visibility across clusters.

With Argo CD integration, Octopus lets teams combine the strengths of GitOps and Continuous Delivery without building custom automations. You get the reliability of Git-driven deployments and the safety, governance, and flexibility of a full CD platform—all in one place.

Learn more on our use-case page.

Happy deployments!

In this episode, Shweta Vohra and Joseph Stein explore what changes when software systems start planning, acting, and making decisions on their own. The conversation distinguishes truly agentic use cases from traditional automation and looks at how architects and engineers should think about boundaries, orchestration, and system design in this new environment.

By Joseph Stein