Gavin Bramer and Konrad Empacher recently led a great session on ‘Rapid Feature Development’ with a focus on Health and Social care in our Healthtech Surgery webinar series.

Coronavirus (COVID-19) Has impacted how many organisations see their IT requirements continue to be successfully delivered, thereby ensuring Businesses remain competitive, efficient, and current.

Delivering on your features is more critical than ever due to the uncertainty we find ourselves in. Within the healthcare arena, we continue to ensure that we deliver the right features quickly and to high quality standards, giving ourselves the opportunity to learn, experiment and fail fast. Key to our success is that we collaborate, reflect, and continuously improve and that this methodology lives on past short term tactical and delivery challenges.

During the session we took the opportunity to discuss the key parts of successful feature delivery as we see it, how we apply our teams to these challenging range of healthcare opportunities and what we might do differently in the now remote delivery landscape.

It’s business as usual at BJSS – albeit with a far more refined approach to ensuring clarity of understanding and precision around quality delivery, specifically in the context of leveraging remote or distributed teams.

People have reacted in an impressive way and their support for each other’s contributions is telling, Businesses have reacted in a positive way and much of the typical behaviour around hierarchy or position is no longer a draw, the “boardroom theatre” is no longer a valid currency. We have seen great levelling, as we are now all in caps, t-shirts and dealing visible with challenges in the home. We believe this enables a less reserved flow of relevant information and improves inclusivity.

That’s not say there are not severe impacts to many, but there are many positive aspects seen by all, we should make sure people have time, and are supported in managing their time.

With that lets take a look out some of the key components of Feature Delivery in the Healthcare arena, as we respond to the realities of remote technology delivery achieved in a non-physical setting and some of the challenges and benefits, we see.

Two key areas of the Agile Delivery methodology come into play, these are the Define and Deliver phases and depending on your elected approach, these could be deployed against either Kanban or Scrum.

The define phase includes aspects such as, Discovery, Planning, Stories, Estimation and Prioritisation.

Within the Healthcare landscape, we have seen a massive shift from the reliance on traditional analogue and in-person processes to digital platforms for example the public cannot meet professionals face to face, they may be required to upload or input data remotely to facilitate the decision-making process. Ensuring we deliver timely to high quality in this dynamic environment has re-enforced the importance surrounding the precision of the Define stages of Delivery.

In order to support the shortest routes to market, we need to leverage accelerators that already exist, this saves duplication of effort, latency in assembling requirements and covers not only technical or tooling accelerators such as the re-use of the NHS Service Manuals or the Developer API’s but additionally extends to how we onboard a strong skills base, spin-up the relevant delivery tooling and tap into subject matter expertise.

With accelerators in place, we can then focus our attention on enshrining the correct Definitions of Ready (DoR) and the Definitions of Done (DoD) utilising the full spectrum of the Delivery team to ensure all parties are agreed with the desired outcomes. This ensures we maintain high levels of understanding of the end state and persist quality standards.

The team curated answers to the questions our audience asked.

You talk about failing fast, this seems like a negative approach can you explain the rationale?

Agile delivery revolves around rapid development, adaptability, and continuous improvement, the concept of failing fast relates to presenting an idea, determining if it will make a return on the investment and either continuing or discontinuing the idea, this approach ensures we do the right thing before investing too heavily in anyone idea or feature for example. This feed-back loop is a fundamental aspect of Agile success.

Perception and buy-in to this concept are fundamental – and makes it work. If for you, your team, your organisation this concept will be negatively received, just use a different terminology. For example by talking about and accounting for avoided risk, avoided cost, avoided clinical error etc. Experimenting and testing hypothesis are other ways of talking about this topic.

Has the wholesale move to remote delivery impacted what can be delivered?

Whilst its more challenging we have seen little major impact, in fact we see trends of delivery velocity improving as some of the distractions such as commuting, open office environments are being limited, along with improved work-life balance and more targeted scopes of work have ensured delivery keeps its pace.

But there must be some negatives impacts?

I think these will be harder to recognise but could be important and should be considered. One prediction is that remoteness will make jobs where detailed understanding of business and user needs more difficult. For example, Business Analysts and Product Designers. More investment here may become necessary.

Do you see it becoming easier to implement change in the Heathcare industry?

Positively there’s a good chance that some inertia will be substituted with far more stream-lined approaches to all aspects of engagements and there is a real appetite to move away from many of the traditional barriers to delivery, the existing crisis has been a catalyst for change. Key to this, is ensuring the inclusion of trusted suppliers and evidence-based approaches.

What the main benefits of delivering features in an Agile way?

• Stakeholder Engagement – Everyone has “skin in the game”
• Transparency – Leads back to the “fail fast” and collaborative approach
• Early and Predictable Delivery – Approaching sometimes large projects in “thin slices” means we can commence with what we know rather than waiting to document every outcome
• Predictable Costs and Schedule – Driven out of the “define” phase which is iterative
• Allows for Change – Again this leads back to the “fail fast” and collaborative approach
• Focuses on Business Value – The approach to “user stories” ensures we always link deliverables back to wider Business critical success factors or key performance indicators to ensure alignment with business value. We constantly probe the Why, How, what, who, where and when
• Focuses on Users – Users or consumers of the end product are involved in the entire process as required and therefore this mitigates against surprises and ensures that what they require is delivered rather than what the technical teams may think they require
• Improves Quality – Delivering in iterations reduces the risk of massive test effort at the end of the development cycle and therefore quality is easier to maintain.

Is there room for enhancements once you have delivered the product?

There is and there should be in many cases. It’s natural that teams and organisations want to finish products and finish projects – and often funding and teams are tied to static dates. This isn’t easy – but – by building in continuous improvement, and experimentation into your solution you make the overall build longer but create a better product.

With sprints in Scrum ideally you are constantly reevaluating what you’re building. But often unavoidably, a lot of the lessons you can learn will only come after a production launch. There are lots of great resources on Product launch, live and retirement phases, for example: gov.uk/service-manual/agile-delivery/how-the-live-phase-works.

And do you go from define to build in sprints?

Teams do this differently; some very mature Product teams can maintain a discovery and delivery cadence very tightly aligned. This often involves engineers; testers being heavily involved in these discovery activities – for example supporting user research in the first part of a Sprint. Sometimes this isn’t possible or practical, and for some teams a larger discrete discovery phase before moving into traditional springs would work better.

Thanks for the informative deck. I agree setting goals is key – what kind of metrics do you recommend monitoring per goal?

There are lots of approaches out there. Market share, customer satisfaction, drop-off rates, financial performance etc can all be described in many ways and there are lots of frameworks to use. Often measurement doesn’t come in early enough in the process. Key for me is to choose a method that lets you clearly connect your outputs “up” to overall organisational strategic objectives as well as offering the flexibility to be truly “rounded”. By that I mean not just focusing on traditional measures, like customer satisfaction – but also on concepts like team health throughout a project, code quality, positive influence on other teams in the organisation and so on. Each of those has a potentially negative effect if not observed, a miserable team who are productive but disband, major tech debt that causes great problems later, and silo-ing of valuable expertise within a team.

Thanks again for joining us and if you missed the session, you can find the recording here on BJSS' YouTube channel.