Skip to main content

Bridging the gap

09 Jun 2017

| Author: John Wright

Share

Bridging the gap

In a recent blog post, Laurence Wood talked about building trust to create successful delivery teams. It is something that came up in a recent conversation about why some Agile teams don't quite deliver on the expectations they set with the business stakeholders. 

We were discussing a large public sector project, one that has fully embraced Agile delivery. It has created a very dynamic and engaging development environment and set-up many delivery teams who collaborate well across the portfolio. However, it has taken a very long time to get that first delivery into production and we were discussing what had prevented early releases. As we talked we realised 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.

IndigoBlue have, for a long time, provided guidance on avoiding a bumpy ride and improving the flow from the business stakeholders into Agile delivery teams by optimising portfolio management and managing the resolution of uncertainty (principles covered extensively in our governance framework, Adapt 2.0. 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 the 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 in order to build 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 feature increments can be 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.

IndigoBlue's DevOps consultants and Architects have been the catalyst within many large public and private sector organisations in creating trust between Service Operations and Development.

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.

DevOps Consulting

DevOps consulting

Find out how our consultancy helps your organisation scale up with confidence to meet ever-growing business and customer demand.

Find out more

Subscribe to receive our email updates

Author

Author profile image

John Wright

John is Head of DevOps and Public Sector Services at IndigoBlue. He joined IndigoBlue in 2006 as Senior Agile Consultant and has been running or coaching Agile teams since the late 1990s. 

CONTACT US

How can we help your organisation?

+44 (0)20 7692 4832

How will we use the information about you?

When you complete this form and submit your details, you are trusting us with your personal data. Our Privacy Notice informs you of what personal data we collect, why we collect it, and of your rights in relation to your data. By pressing submit, you indicate that you have read and accepted the terms of our Privacy Notice and that you consent to our processing of your personal data as described in the Privacy Notice.