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 any one 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, or 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 it's 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, and open office environments are being limited. Improved work-life balance, and more targeted scopes of work, have ensured delivery keeps its pace.
But there must be some negative 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 which require 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 healthcare industry?
Positively there’s a good chance that some inertia will be substituted for far more stream-lined approaches to all aspects of engagements. 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 are 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 – Sometimes, approaching 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. 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.
How 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 and 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 Sprints 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. What's key 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. For example, 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.