Salto for
DevOps
Articles
SHARE
Benny Schnaider
January 23, 2022
3
min read
Teams in business systems tend to use the term “Agile” a lot—in a lot of different ways—and I think that’s because it lacks a clear definition. In this article, I’ll attempt to provide a framework for thinking about it, as well as some encouragement.Agile is not easy to practice in business operations (BizOps). In fact, the way business applications are built actually prevents you from practicing Agile, though it is highly valuable if you can pull it off. If you can, Agile offers a reliable way to invent, protect, and perfect your company’s internal systems. It also draws you into closer alignment with your product development team, which likely already uses Agile, allows your teams to communicate better around changes, and allows your business systems to evolve just as fast as the business—and to continuously support it.
At its core, Agile is a philosophy about rethinking the idea that work should happen in a linear sequence. That may work in industries like manufacturing, but not in software, where things are constantly evolving, and each change can retroactively change the changes that came before.
In the early days of software development, work was not Agile. There were widespread issues with productivity and software quality, and a group of developers created what’s known as The Agile Manifesto to fix them. In particular, developers sought to update the traditional waterfall approach to address these three challenges:
Thus, Agile was launched as a collection of generally accepted principles around making frequent changes with minimal risk, managing changes automatically and predictably, and simplifying system maintenance.
Some of those principles include iterating quickly, testing changes in real-world conditions, studying users, allowing teams to self-organize, and maintaining multiple versions of your work so you can easily revert if something goes wrong.
The parallels to business systems (BizOps) are almost exact. Today in BizOps, teams struggle to test, to anticipate and prevent errors, and to coordinate work. That’s why in BizOps, Agile can help you address all three challenges.
With Agile, you can:
Because errors in your systems can spread and compound, it’s vital that you have one central view of how your business systems are currently set up. This is what’s known as a “formal representation.” This is the foundation of Agile.
Without a formal representation:
That means you can’t understand the potential impact of proposed changes, which in turn means you have to spend a lot of time in analysis. And even then, you can never really be certain, because you can only view what the interface allows you to.
Practicing Agile in BizOps means:
Because the risk for breaking things in business applications is high (it can often affect revenue), you need a repeatable, predictable, and ideally automatic way to quality-assure your changes before you release them.
Practicing Agile in BizOps means:
Business system complexity can grow exponentially, but administrator headcount can’t. Thus, you need a scalable way to maintain your systems.
Practicing Agile in BizOps means:
Without agile, BizOps teams are in the same place software developers were pre-Agile—stuck in an endless loop of responding to breakages and fixing mistakes. With it, they’re able to make frequent changes with minimal risk, manage changes automatically and predictably, and simplify system maintenance.
And when you do that, your business systems can evolve just as quickly as your business processes do—and they’ll have to, if your business is to grow.
But of course, most business systems weren’t built to support Agile, which is why tools like Salto can be a big help.
Salto for
DevOps
Business Engineering
SHARE
Benny Schnaider
January 23, 2022
3
min read
Teams in business systems tend to use the term “Agile” a lot—in a lot of different ways—and I think that’s because it lacks a clear definition. In this article, I’ll attempt to provide a framework for thinking about it, as well as some encouragement.Agile is not easy to practice in business operations (BizOps). In fact, the way business applications are built actually prevents you from practicing Agile, though it is highly valuable if you can pull it off. If you can, Agile offers a reliable way to invent, protect, and perfect your company’s internal systems. It also draws you into closer alignment with your product development team, which likely already uses Agile, allows your teams to communicate better around changes, and allows your business systems to evolve just as fast as the business—and to continuously support it.
At its core, Agile is a philosophy about rethinking the idea that work should happen in a linear sequence. That may work in industries like manufacturing, but not in software, where things are constantly evolving, and each change can retroactively change the changes that came before.
In the early days of software development, work was not Agile. There were widespread issues with productivity and software quality, and a group of developers created what’s known as The Agile Manifesto to fix them. In particular, developers sought to update the traditional waterfall approach to address these three challenges:
Thus, Agile was launched as a collection of generally accepted principles around making frequent changes with minimal risk, managing changes automatically and predictably, and simplifying system maintenance.
Some of those principles include iterating quickly, testing changes in real-world conditions, studying users, allowing teams to self-organize, and maintaining multiple versions of your work so you can easily revert if something goes wrong.
The parallels to business systems (BizOps) are almost exact. Today in BizOps, teams struggle to test, to anticipate and prevent errors, and to coordinate work. That’s why in BizOps, Agile can help you address all three challenges.
With Agile, you can:
Because errors in your systems can spread and compound, it’s vital that you have one central view of how your business systems are currently set up. This is what’s known as a “formal representation.” This is the foundation of Agile.
Without a formal representation:
That means you can’t understand the potential impact of proposed changes, which in turn means you have to spend a lot of time in analysis. And even then, you can never really be certain, because you can only view what the interface allows you to.
Practicing Agile in BizOps means:
Because the risk for breaking things in business applications is high (it can often affect revenue), you need a repeatable, predictable, and ideally automatic way to quality-assure your changes before you release them.
Practicing Agile in BizOps means:
Business system complexity can grow exponentially, but administrator headcount can’t. Thus, you need a scalable way to maintain your systems.
Practicing Agile in BizOps means:
Without agile, BizOps teams are in the same place software developers were pre-Agile—stuck in an endless loop of responding to breakages and fixing mistakes. With it, they’re able to make frequent changes with minimal risk, manage changes automatically and predictably, and simplify system maintenance.
And when you do that, your business systems can evolve just as quickly as your business processes do—and they’ll have to, if your business is to grow.
But of course, most business systems weren’t built to support Agile, which is why tools like Salto can be a big help.