Middleware is tricky. It’s extremely technical, solutions require a lot of moving parts, a lot of collaboration and a substantial amount of dependencies across people and technologies. This in itself can lead businesses to want to take a ‘less risky’ approach to developing the solution by managing the projects in a waterfall method. But is it less risky? We at Healthcare Gateway have been leveraging Scrum to develop our interoperability solutions in an agile way for several years now and this is what we have learned.
In our case, we are between systems that provide data and systems that consume data, and these are plentiful within the landscape of the NHS.
Scrum advocates cross functional teams, everyone in the scrum team should have the skills to do all parts of the work required. You cross train each other in specialities and work on removing single points of failure so the team is sustainable. For this concept to truly take hold you need to embrace the agile principle of ‘Business people and developers must work together daily throughout the project’. Soft skills are your superpower! Not all integration projections are built equal and the difference between developing a solution and delivering a solution is in your ability to collaborate and communicate effectively across multiple internal teams and also in our case, across multiple external parties. Creating alignment here is crucial to the successful delivery of a project that meets the customer’s needs. Utilise daily stand-ups, create alignment in your roadmaps across development, product and commercial. Create tribes or design trios to get ahead of the impediments and requirements but most importantly take time to acknowledge when something isn’t working and use those soft skill superpowers to learn and create better collaborative solutions.
One of the most important factors in a Product Owners role is to understand what to deliver each sprint that will provide the most customer value. This can sometimes be tricky when developing middleware solutions. “How do you deliver a demonstrable potentially shippable increment each sprint with no front end?” This question arose time and time again not only in our teams but also in my CSM training from teams across the country not only in middleware but also in those using scrum in IT and hardware.
You may not have a front end, but you do have the ability to develop an end to end connection between the two systems you are trying to connect. Start with a basic connection, basic test data, basic security and then iterate.
One of the biggest challenges for us and our development teams is the vast number of systems we develop interoperability for. This limits our ability to test how our solution for data providers may function across multiple consuming systems with their own specialist eco systems of security protocols, UIs and requirements. Providing your development teams time to build mock systems, mock providers and create a space in which they can test and demonstrate their work provides enough confidence in their solution to continue on while in the interim removes the impediment of access to supplier / source test systems.
We’ve worked on our sprint review a lot with our teams over the last year, working from home during the pandemic has in some ways helped us innovate and harness our collaboration power more effectively online. We’ve looked more closely at what the scrum guide requirements for sprint reviews are and put what we can in place but it brings us back to the question of “how do you demonstrate middleware solutions in a non-techy way?”
Internal stakeholders can include a wide variety of people from across the business so while the demonstration in an internal sprint review can be more technical, you still want to encourage the Scrum Team to demonstrate an end to end potentially shippable increment covering the technical benefits of the increment in a more user centric way. The benefit of this is buy in at every stage. We want our internal teams to be excited about what we are building, we want them to talk about it, question it and feedback. For this our teams have been using tools like swagger and postman to provide the front end demonstration of data moving from source to target in a digestible way, incrementally demonstrating and explaining the additional functionality that has been added and why.
External stakeholders for us are our partners and end users. Demonstrating to these stakeholders can sometimes come a little later. This is due to access to test systems, data and moving away from mock to real world testing. Setting up later demonstrations out of sprint reviews so far has worked for us here, but we are always pushing ourselves to reach that goal of having our end users feedback directly on sprint reviews to further close that feedback loop and decrease our time to market.
By submitting this form, you agree to our privacy policy.
To find out more about our solutions, get in touch.
By Zoe McLean, Agile Coach at Healthcare Gateway
Zoe became the Agile Coach for Healthcare Gateway in February of 2021, after working as Scrum Master supporting the development team with agile practices. As Agile Coach, Zoe has been working with the wider business to implement agile methods and increase our overall agility.
