Agile companies and teams can develop new products and features much faster than before.
Last year's 'State of Agile' report from digital.ai found 64% of companies and teams use Agile methodologies to "accelerate software delivery" while 47% use it to "increase team productivity". Velocity is the third most-used metric for measuring agility.
Software engineering teams have had the best part of three decades to embed Agile ways of working, yet challenges in the space remain, and many of these pertain to speed. That is, while speed is considered one of the key benefits of Agile, it is operationally challenging to maintain.
Indeed, An AIPM/KPMG report found that 73% of organisations formally use 'capital A' Agile to some extent, with the top benefit of doing so being "better able to respond and adapt to changing project environments and circumstances.
There is now a shorter time between new versions or the arrival of new tools that aim to improve the performance of actions.
Organisations that want to stay on the cutting edge of productivity are expected to be across the breadth of this change, to keep up with weekly new feature releases, to validate whether new products are substitutable for older ones and to be flexible enough to swap tools in and out quickly where it makes sense.
They must also counterbalance this against their organisation's ability to change. Even Agile teams can struggle with too many changes. A fast cycle of innovation can become a disruptive influence on business-as-usual operations. While almost everyone is focused on moving faster, there needs to be a period of adjustment so that a change has time to take effect and have an impact before the next change appears.
Fastly APAC technology evangelist Stephen Gillies.
The simple life
Businesses have been looking to understand change and counter-resistance to it since Kotter and Schlesinger. It's the subject of countless books and studies and is particularly relevant today as businesses undergo a period of rapid change at scale.
Many Australian organisations have adopted Agile methodologies and thinking to enable that change. Informally, the proportion of organisations that might consider themselves to show Agile tendencies in the past year is likely much higher.
Inevitably, they may encounter some challenges around this, as well as resistance to the pace of change, even if the organisation theoretically has the 'mindset' for it.
A change of pace
Software as a service that enables businesses to operate doesn't stand still and is constantly being optimised.
The security space is a case in point. A colleague recently pondered why the security tools that were good enough a few years ago aren't now. He came up with several explanations:
- The fast pace of innovation is making tools obsolete much faster.
- The number of tools in use, and the way changes to one might impact the way it integrates or functions with others.
That second point is important.
Recent research by ESG Research and Fastly shows that 47% of Australian organisations expect to support more than 200 internally-developed applications within the next 18 months, up from 33% of organisations in 2021. Most internal applications rely on APIs to support the use of microservices, to share data or interconnect with other applications.
Keeping up with fast-paced innovation across all these applications is difficult. It may not even be possible. System interdependencies may make upgrades difficult, leaving an organisation stuck on a tool version that remains fit-for-purpose but falls out of the continuous improvement or support cycle.
Arguably, the faster pace of change in the world today makes it harder to justify maintaining an environment of 11-plus best-of-breed tools. That is leading organisations to rethink their large best-of-breed environments, with most - our research suggests 93% - now looking to scale back to a single integrated stack for simplicity purposes.
A single stack
Organisations that want to consolidate down to a manageable number of tools - and eventually a single integrated stack - can take the following steps.
First, take an inventory of the tools you have. Understand how software is delivered and secured. You can't protect what you can't see. Developers are interested in moving quickly, so they may not always tell IT teams about new APIs or AWS instances that need to be protected. In addition, not every tool a developer uses has been created or blessed by the security org.
Once you have a list of everything you need to ensure is secure, you can assign risk ratings to each item. Basically, consider what parts of your software systems would most disrupt or damage revenue generation and delivery to users. Then, consider where low-hanging fruit for attackers can be pruned, so there isn't an easy way to attack those high-priority resources.
Once you've assigned risk and prioritised your list, get to work in small increments. Don't try to do everything at once. Instead, start serially - maximise or replace one, then move to the next. In the background, consider wrapping security into your development processes, such that you don't need to undergo this auditing and risk assessment effort again. This ensures that as a product is being developed or refined, it is being tested for security in a way that avoids disrupting development productivity or velocity.
Having an end-to-end view of your threats and traffic across security and development is also required. You need visibility against a spectrum of threats because attackers are testing multiple places for vulnerabilities or ways to abuse functionality.
And then wash, rinse and repeat until your environment is more manageable and you have the pace of change more within your control.
