DevOps Executive Summit 2019
We attended the DevOps Enterprise Summit (DOES) in London at the end of June 2019 and below are some of the highlights we picked up on.
In the coming weeks we will publish more detailed blogs on some of these topics. If you want further information or our notes/slides please email email@example.com
In Italics is what we heard from various presenters and what follows in plain text are our thoughts on these topics.
- High performing organisations are pushing further ahead with improvements in key metrics. What was considered good last year is now average. Continuous improvement. the 3rd principle DevOps principle becomes the norm when DevOps is implemented properly.
- DevOps and outsource are not mutually exclusive as organisations bring outsource vendors into new engagement models and ways of working. Renegotiating win-win contracts can be less expensive than buying out the partner. DevOps is a reality to outsource partners and this is evidenced in their changing service models. They can lead or be led by customers to new ways of working. Otherwise, they may be perceived as an obstacle to progress.
- People really matter – where there are dissatisfied staff and higher attrition is where you are likely to find the seeds of technical debt. People who care about what they do produce higher quality outputs. Anonymous surveys are easy to run but note that you will only convince people to complete surveys on an ongoing basis if survey results are shared and action taken.
- Chatbots are being used by internal teams
- To capture unplanned work requests. Unplanned work effort should be seen as a constraint.
- In conjunction with machine learning to suggest solutions where there are alarm storms. Filtering the signal from the noise is a real issue for organisations with multiple alerting systems… and chatbots can do this easily and in conjunction with ML identify which recent change is likely to have caused the alert and operate a blue-green toggle.
- RPA tools are being used within automated test suites as data input ‘bots’. Robotic process automation is mostly employed to automate routine administrative tasks such as populating web forms from Excel or Word. This describes work which manual testers undertake. There is a low cost of entry here as most RPA vendors offer an Open Source introductory model.
- Pharmaceutical companies are embracing DevOps. We have engaged a number of pharmaceutical companies for whom safety-critical processes and FDA regulation seemed to be an obstacle, however, we were pleasantly surprised to see at least one life science company producing tangible results from their DevOps investment.
- IT organisations moving from project to product generally follow a similar pattern
- Silo titles and roles remain in the short to medium
- Create long life cross-functional teams tasked to build it, support it and prioritise increments by value.
- Project reporting is a reporting layer until management understands how to account for incremental change and value realisation.
- Projects commit budgets up front and never end. Products are only invested in when there are results.
- In our experience, the project to product journey starts with mindset then process and finally tools. All too often we meet clients who think this is a tools issue but in fact if you can side step organisation structure, and start with process and new leadership thinking … .results are more likely to be produced. Project to product is a recurring theme in our DevOps Simulations.
- Passion for ‘better’ overcomes inertia. Organisations need leaders who can inspire passionate behaviour. The leaders don’t have to be passionate themselves, but they must be able to identify and motivate selected team members to exhibit this behaviour.
- Integrating the business into a DevOps transformation is so important that if you do not have them on board you are probably wasting your time. Just changing how you engage the business will not suffice. A very common method for funding IT expenditure is to give budgetary control to the business thereby ensuring that the business must understand what DevOps is and how it can be of benefit. It’s important to speak in business language when talking about DevOps to business people and bear in mind their perception of IT at the outset is likely to be negative. Start with some empirical evidence of why a DevOps change might just work to solve relevant business problems.
- One of the UK’s leading banks released more features into production in the prior 12 months than in the previous 4 years together. This cycle time reduction is accelerating. A number of UK Tier 1 banks are deriving value from prioritised incremental releases. They have been able to overcome legacy constraints such as Conway’s law, creaking architectures, the frozen middle and regulatory oversight.
- High performing DevOps teams are connected to business metrics. But it’s not easy and the business metrics do not replace the KPI’s that are the heartbeat of Continuous Development and Continous Delivery.
- Sharing data is well understood as a means to remove silo but now there are opportunities to use ML to unlock value from new flows of data. This is an emerging area which we are monitoring and where potential exists for our product partners.
- The best practice is to have only 1 ticketing system for DevOps and SRE teams.
- Command and control leadership is at odds with agile ways of working. Ideally, there is a lean initiative on the business side which can drive lean into the IT process. Lean for IT is DevOps.
- One presenter identified SRE teams need to engage DevOps teams as their customer with metrics for
- Continuous Integration
- Continuous Development or Delivery
- Net Promoter Score
- There are no hard and fasts here as SRE and DevOps separation of duties need to be ‘cookie-cut’ for each organisation. We have seen SRE teams take on centralised tasks such as monitoring, troubleshooting and security. Fostering healthy competition between SRE and DevOps teams may fit with your company culture. Have the SRE team undertake level 2 and 3 support on pipelines where the DevOps teams use the pipelines and ‘patch’ them to get code shipped. The key is one bigger or governing business metric and then support metrics that are clearly understood by both teams.
- Minimum viable change – the least amount of work required to make a demonstrable improvement. Useful thinking to bring to organisations that are trying to break down waterfall mindsets. Another way to think about this is that organisations that are embedded in older ways of working tend to want to plan everything (including their agile transformation) before they act. Minimum viable change means acting and thinking in short iterative cycles and is a good way to break down older ways of working.
- Convention over configuration. Avoid multiple pipelines that are subtle variations of one another as it increases cognitive load for the teams that maintain them. DevOps teams tend to want to overcomplicate pipelines where SRE teams are more likely to have discipline and rigour. Make sure there is clear segregation of responsibility to ensure that conventions are adhered to. Otherwise technical debt in pipelines can accrue.
- A leading audit firm (top 4) endorses DevOps as evidence/audit data is captured by system logs. For example, an updated to a pipeline to comply with a new security standard. All code deployed through that pipeline is now clearly compliant with the new security. Audit tasks now relate to reviewing the pipeline changelogs which are captured in an automated fashion in standard databases upon which reports can be run. It is critical that Chief Risk Officers grasp this as the business case to automate more IT tasks is being built.