Bridging the gap

John Wright
John Wright | 9 June 2017

In a recent blog article 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 of 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 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. The Development teams don't always believe that the Service Operations teams will embrace Continuous Delivery into production, knowing that they will always want to review the solution, introducing a manual step before anything can go out into production.

So how is this gap bridged? How do you avoid the almost inevitable Service Operations delay?

  • Start with early engagement between Service Operations and Development, don't just build stuff and assume it can be deployed.
  • Ensure the Product Owners and Developers actively seek the Service 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 solutions that might not be immediately scalable or resilient being tolerated, 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. Know that the end-to-end deployment process works and can be trusted, this will build confidence on both sides.  Build in the basics for metrics and health-checks into the application up-front (then incrementally improve these) 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 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.