This post was written by Matthew Skelton co-author of Team Guide to Software Operability.
We were featured in a Computer Weekly article ‘Five pitfalls to avoid when doing DevOps‘, as part of the Rackspace DevOpsBreakfast panel discussion on 19th August. The five pitfalls are:
- Seeing DevOps purely as an automation activity
- Having a weak case for doing DevOps
- Not involving compliance and audit teams
- Taking a prescriptive blueprint and being rigid
- Overselling the concept
In particular, we highlighted that seeing DevOps as mostly about automation – and especially creating a dedicated ‘DevOps’ team for infrastructure automation – is missing the point. Also, the way in which the organisation deals with failures in the software systems needs to shift to a blame-free model, allowing the whole organisation to learn and improve. In our experience, a ‘big bang’ approach to adopting DevOps is unlikely to work; instead, an incremental, slow-but-sustained approach is best for most organisations, using a valuable but not mission-critical software application or service as a prototype or trailblazer, ‘planting the seed’ of new ways of working and giving space for the new practices to grow and spread.
Read the full article here: Five pitfalls to avoid when doing DevOps
Update: we also spoke to tech journalist Adrian Bridgwater for his Computer Weekly CWDN blog: DevOps is a learning process: “Successful DevOps adoptions address the interaction technology AND teams to build and operate software systems effectively.”
Skelton Thatcher 