Agile, Digital and Devops are three words you hear a lot in big organisations these days, usually hot on the heels of talk of transformation. Whatever they mean, they are certainly things that companies covet. But how are they connected?
Agile began with the famous manifesto, created in 2001 by a group of software practitioners who had been having some success with new techniques to improve delivery.
In the mid to late nineties, it’s fair to say many, if not most, software projects ran into some form of difficulty, usually due to breakdowns in communication between customer and supplier(s). With hindsight this was not surprising since software had increased in power and compexity by some way and so delivery projects were having to contain and manage that compexity whilst at the same time bend its use to meeting often shifting requirements.
Although there were, and are, many agile flavours, it’s important to remember that the manifesto was never about declaring the “one true way” to deliver software. Quite the opposite.
The manifesto recognises that many things we do to rein in complexity (document and plan, for example) can be counterproductive to managing it. Not that these things are bad per se, just that we need to always remember that we are human, and so are our clients, and no one knows all the answers ahead of time. We are pretty good at breaking problems down though and not too bad, most of the time, at talking things through.
Companies that stuck to the principles of agile: small iterations, lightweight processes, continous improvement, continuous monitoring, continuous integration, continuous testing, did very well out of it. Companies that adopted formalised methodologies derived from the principles not so much.
But as teams got better at delivering working software that actually did what was required, the contention became getting it to end customers. If you are going to continuously deliver then it’s really handy to get the benefit continuously too. Throwing, even fully tested, software over the wall to the operations team multiple times a day is only going to create a very long queue of undeployed features that are unable to provide return on their investment.
So it was natural for development teams to seek more control over operational aspects of their code. After all it’s always only ever been software, servers and infrastructure (and the parallel rise of cloud computing abstracted the complexity of taking that control almost to zero).
Development Operations or devops is less of a role or a thing than a simple merging of two groups that arguably should never have been separated in the first place. Whilst there will always be technical specialisations, the objective (get the product to the customer) is shared. Companies like Google and Facebook took this even further so that the “product team” also looked after incidents and outages twenty fours hours a day, refining devops into Site Reliability Engineering (SRE). Now it matters less who does it, just as long as someone does, and when the team that made the software also runs it, there is a dramatically reduced need for overhead and waste to communicate how to run it.
Once the agile genie was out of the bottle, devops and SRE were inevitable, as was product thinking because it’s much easier to motivate that team if they own their own dependencies and have a clear reason for their existence.
The next bastion to fall is digital. What worked for delivering the web experience (ubiquitous, easy to access, efficient, low cost, delightful and consistent customer experience) can be applied anywhere in the business. The customers may change but the principles of agile, devops, SRE and product centricity are timeless.
Companies are struggling with digital because they didn’t take the time to embed agile thinking into the organisation. Instead too many of them relied on consultancies pushing their agile framework (which surprisingly required more consultants to help implement it). They didn’t face into the devops/SRE challenge and fundamentally change the organisation to remove those barriers. They haven’t been changing their funding structures towards products over projects and having the CIO at the top table to lead that change. And because of this they are staring into the future without the basis for digital change.
For many there is still just about enough time to overhaul their businesses, but the longer they leave it the higher the chance their customers won’t be there when they do.