This 100% for DevOps and Agile… I’d spotted an article on The Register and thought it was worth a brief post because I thought it was right on the point.
With DevOps/Agile, if you use the “process” to the letter of the book, you’re doing it wrong.
If you simply buy Software/SaaS Services, you’re doing it wrong.
This is firstly a culture thing. Tools should be open to change and addition, they should never be fixed and they should be often questioned – assumptions that made them right at a point in time will change, change with it.
The whole point is that an Agile team should have participation from everyone that can execute – i.e. hopefully a mixture of (in no particular order!) Developers, Ops People, Marketing Folk, Legal Folk, Business Analysts, Project Manager/Agile Lead.
The point being – a customer or someone in that group comes up with an idea, it gets debated/ranked/scored and ordered. The team then have the necessary culture that enables them to make the change through tooling and a frictionless process (because to execute, the team is self dependant).
The outcome for a business should be much faster time to market of new features and services – certainly for web/mobile/app/digital services. In terms of systems and infrastructure, the gold standard would be no outages, but for most, this turns into more frequent outages but for much shorter periods of time – think seconds/minutes vs hours/days.
This trick – from the observations I’ve got to make – is that it works in a different way in lots of companies, because behind the scenes, every company is a bit different. The trick is finding a comfortable point – for both the business and the technical teams within. Starting is better than not starting, because once you start and it clicks, the rest tends to start fixing itself!
When teams are coming from traditional approaches, for the most point, teams are initially resistive thinking the chaos that went before ITIL will occur – unregulated changes, massive outages, no control over what changes. The reality of course is usually quite different. What they normally see is a much faster process to perform simple changes, they’re peer reviewed and controlled enough, but there is less of a committee feel about what goes on and more of a getting stuff done type feel. The big stuff, the complex stuff of course doesn’t magically go through in one hit, but what tends to happen is it breaks down into smaller pieces making the change less daunting, in doing so the risk reduces (as does the blood pressure!).
If you’re struggling to get a DevOps Culture into the ways of working, or bringing your team into this mindset, it’s really quite easy. We help companies move across from ITSM/ITIL and Change heavy approaches to agile. Get in touch for a no pressure conversation, we’re a friendly bunch and are always open to a conversation around this kind of stuff!