Bridging the gap

Bridging the gap

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.

No alt text provided for this image

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] .

No alt text provided for this image


John Wright great article. Highly recommend a read on #frictionless delivery.

要查看或添加评论,请登录

John Wright的更多文章

  • Re-visiting Frictionless Delivery

    Re-visiting Frictionless Delivery

    In the past I've looked at optimising the product delivery process and focused on small elements of the process linked…

  • Realising the true potential of One Login

    Realising the true potential of One Login

    In my previous article, I discussed the subject of One Login, a landmark initiative from the Government Digital Service…

  • Making Better Use of Data in the Path to a Data-Driven Public Sector

    Making Better Use of Data in the Path to a Data-Driven Public Sector

    Data is more than just information — it’s a valuable commodity. And better sharing of that commodity is key to seeing a…

  • The One Login vision: Making it work

    The One Login vision: Making it work

    In this blog series so far, I’ve talked about the Government Digital Service (GDS) One Login initiative, one of the UK…

  • One Login: a watershed moment for UK Government Services?

    One Login: a watershed moment for UK Government Services?

    Exploring progress to date and how to de-risk adoption across government departments Back in 2021, the Government…

  • Becoming product-led

    Becoming product-led

    When becoming a product-led organisation there are a number of challenges that come to light: Understanding the market…

    1 条评论
  • Reflection on SR2’s panel discussion: Government's Shift to a Product Mindset

    Reflection on SR2’s panel discussion: Government's Shift to a Product Mindset

    25 November 2021: A thought-provoking discussion with industry leaders: Ben Davison, Digital Delivery Leader, Axiologik…

    8 条评论
  • Using ServiceNow for Good?

    Using ServiceNow for Good?

    Agility While Maintaining Control Coming from a software engineering background and striving to optimise flow and the…

    1 条评论
  • All Day DevOps

    All Day DevOps

    Details On November 6, 2019, we'll be participating in All Day DevOps, a live online, streaming event, featuring over…

  • Industry-academia collaboration

    Industry-academia collaboration

    Giving something back..

社区洞察

其他会员也浏览了