Bridging the gap
John Wright
Product, Technology and Delivery Leader, Executive Level Consultant, Transformation Delivery, Strategic Technology Consultant. Book a chat below.
Recently I was looking back at the delivery of a large public sector project, one that had fully embraced Agile delivery. It created a very dynamic and engaging development environment and set-up many delivery teams who collaborate well across the portfolio. However, it took a very long time to get that first delivery into production and I considered what had prevented earlier releases. It became apparent that there was a battle between agility and control and that this was a common problem for many organisations, not just public sector projects, and something worth exploring further.
If you consider the release of software product as a flow from user needs, through iterative design and development, to deployment of tested integrated systems, then the key is to optimise the end-to-end flow. Often the Agile delivery process sits in the middle of this flow, and is constrained at one end by governance and prioritisation of user-needs against value derived, and at the other by separating the development and operations culture.
Many organisations focus on improving the flow from the business stakeholders into Agile delivery teams, optimising portfolio management and managing the resolution of uncertainty and optimising build/test pipelines. However, over the past few years, it has become increasingly obvious that there is a tougher battle to be fought when striving to optimise end-to-end delivery – building trust between the Development and Service Operations communities to enable robust, repeatable delivery into production.
Traditionally, Service Operations teams have focused on the efficient delivery and deployment of technology to production (be that internal systems or external customer-facing services). They have taken pride in automation of processes that take packaged and tested software and push it into the hands of expectant users. This is all good and important stuff, but it has created a divide between the Development and Operations teams. A divide that can be healed by improving communication and collaboration and building trust.
From personal experience, I have found that Service Operations teams struggle to engage Development teams in prioritising scalability and service monitoring requirements into the design of their software, resulting in a lack of collaboration in the design of the infrastructure to support and operate the software that has been built. On the other side, the Development teams don't always believe that the Service Operations teams will want to work towards Continuous Delivery into production, assuming that they will always want to review the solution, introducing a manual step before new features can be regularly and incrementally released into production.
So how can this gap be bridged?
- Start with early engagement between Service Operations and Development, don't just build stuff and assume it can be deployed. Share information from the start and work towards shared responsibility.
- Ensure the Product Owners and Developers actively collaborate with the Service Operations; seek Operations' requirements for automated monitoring, diagnostic information and audit information and prioritise them appropriately.
- Encourage Software Architects to engineer scalability and resilience into the design of the software at the right time and communicate this design to the Service Operations team so that they understand and can validate how scalability and resilience will be achieved.
- Provide Service Operations with an understanding of the demand that early releases of the service are likely to be exposed to (and the impact of any failure). This can lead to solutions being tolerated that might not be immediately scalable or resilient, with the confidence that appropriate design work will be implemented in future releases.
- Build the path to live early, even if this is never released to the outside world. Proving that the end-to-end deployment process works and can be trusted will strengthen communication and collaboration. Build the basics for metrics and health-checks into the application up-front (then incrementally improve these), working towards pervasive logging and monitoring so that everyone knows that Service Operations’ requirements are important from day one.
At Mozaic, we believe in the concept of Frictionless Delivery. By understanding the needs of the Service Operations teams early in the development process and working with them to automate the population of Service Management tools and re-structuring the change approval process the divide can be bridged.
By encouraging communication and collaboration and doing things that support the needs of both parties, we create an environment that supports incremental improvement. This attitude builds trust by earning it, where one team delivers something of use to another team, ensuring each other’s explicit concerns are dealt with at appropriate times, with rigour and discipline – gradually cultivating a constructive DevOps culture.
About Mozaic
Mozaic helps organisations assess and improve their digital strategy, delivery and operations.
We work collaboratively alongside IT management teams to design and implement radical improvements in performance and agility, using automation, tooling and by delivering new ways of working.
If you would like to know more about Mozaic’s Frictionless Delivery approach please give us a call on (+44) 0203 709 1625 or send an email to [email protected] .
John Wright great article. Highly recommend a read on #frictionless delivery.