For many organisations, the starting point (and often the end point) for their Agile journey is the adoption of Scrum. In fact, in some people's eyes Scrum has become almost a commodity item now: run a few training courses, hire a few Scrum Masters. This makes adopting Scrum seem a relatively cheap option if the goal is simply to "be Agile".
Unfortunately, Scrum on its own is only a part of the whole puzzle and while it will deliver some benefits, these will be limited, especially in larger organisations.
A common (anti-)pattern is where an individual Scrum team is successfully developing software story-by-story, sprint-by-sprint, but can't release that software frequently because the company-wide release processes are unchanged and therefore the cost of release is still very high.
One of the problem outcomes of this pattern is that it appears to the business stakeholders as if nothing much has changed in real terms, thereby reducing their engagement in the process as a whole. Getting full business engagement can be challenging at the best of times, without losing your most effective catalyst for change.
The frequency of release has to be a first-order measure of Agility. This is often referred to as putting in place the "route to live" or the release "pipeline".
Clearly, a large part of an efficient route to live is about automation: automation of environment setup, automation of testing and automation of deployment. However, this isn't just about automating the downstream processes. It is much more about "shifting left", enabling the upstream teams to validate as much as possible at source, and ensuring that new errors aren't introduced on the journey downstream.
It is severely depressing the number of times we see testing functions (for example) supporting Agile by automating their regression pack which is only ever run after the sprinting is complete, and only runnable and modifiable by the test team.
But it isn't just about automation – it's also having a single, collective goal for the whole end-to-end process. If this isn't the case then teams will tend to reinforce existing silos and implement local optimisation. If development teams feel they have achieved their done criteria, then the inability to put completed work live is often seen as a "blocker", another variation of the us-and-them mentality.
The advent of cloud has exacerbated this tension between development and release, because development teams are now in a position to create their own independent environments to their own specifications. Although development can absolutely move faster, it just moves the problems downstream, putting additional pressure on the team responsible for ensuring operation-readiness.
This highlights another (anti-)pattern which is beginning to become more prevalent where, even though the route to live is acknowledged to be important, the development teams are ramped up and start driving forward while the release capability is treated as a separate team, and often follows along behind. This approach reinforces the division between development and release, and embeds dev-done in the mindset of the development team.
A further issue is that, if developers have complete freedom, then what is to stop them implementing things which aren't secure, scalable or standardised? Traditional release teams have skills and mechanisms in place to address these challenges. Unfortunately, these mechanisms are focused only on stopping bad things from happening, and are inherently slowing down the release process.
We need to be careful though that, in the quest to speed things up, we don't throw the baby out with the bath water. Again, the proper solution is to "shift left", to build repeatable environments that make it "easy to do the right thing, but hard to do the wrong thing".
To a certain extent, Scrum itself has caused some of these problems. Scrum has no specific techniques for engineering, unlike its predecessor Extreme Programming (XP) where engineering was front-and-centre. Scrum also explicitly states that sprints only intend to achieve "potentially-shippable product". Although it wasn't the intention of the creators, it made it possible to "do Scrum" without doing anything different technically. Frameworks such as SAFe have recognised this deficiency and directly incorporated DevOps.
DevOps is the embodiment of the engineering practices that bring down the cost of change and the route to live. The tools to facilitate the practices have developed profoundly over the last couple of decades.
To get the true, intended benefits from Agile, DevOps needs to be a fundamental and fully integrated part of the process.
Find out how our DevOps+ practice can support you in unlocking the full benefits of Agile at your organisation.