Service and project delivery is about solving problems and helping teams work together to get things done. Delivery can be done in lots of different ways, and needs to be tailored to the product, the team delivering it, and the organisation they work in. Some teams work better using agile methodology, some prefer waterfall, and others can use a blended approach.
Our delivery colleagues have created a set of standards that give us a shared understanding of delivery across the organisation. Head of agile delivery, Barry Traish, outlines the standards and suggests ways you can apply them to your own projects.
Use the most appropriate delivery method
Agile is the go-to methodology for many people involved in delivery, but is it always the right way to approach a problem? You need a deep understanding of whether a problem is ‘complicated’ or ‘complex’, and whether you need to learn and adapt as you go.
In the Cynefin framework, a problem is ‘complicated’ when you know the solution up front, its requirements are unlikely to change, and you’ve done similar things before. A problem is ‘complex’ when the solution is unknown, requirements are unclear, or they’re subject to change.
It’s important to choose the right approach to ensure you understand the problem and that the right thing is delivered, at the right time, cost and quality. Different types of problems need different approaches.
Most problems we face in DWP Digital are complex, because the world we live in is inherently Volatile, Uncertain, Complex and Ambiguous (VUCA). But if we have high confidence in what we will deliver then agile is an unnecessary overhead.
Continuously improve your ways of working and delivery outcomes
Your team should take regular opportunities to reflect on and adapt their ways of working throughout the life of the delivery. Team health checks, sprint retrospectives and lessons learned help you do this.
Team health checks give you empirical data that help you understand and improve how the team is feeling and working. They also give you a balanced assessment on the effectiveness of a team and how they can deliver.
There is no single way to run a retrospective, and there are many resources with ideas and advice, but there are some common principles. They should always generate a small number of actions, which are completed and visibly tracked.
Retrospectives should be done regularly – no less than once every four weeks. Not doing regular retros is a serious indicator of poor team health.
Deliver value early
Everyone in the team should understand the value of what they are working on, including how we measure value. They should have a clear purpose and direction, with an understanding of how their work connects to the aims of the delivery.
Put a working product in front of your customers as early as possible, as part of a phased delivery approach. This significantly lowers delivery risk and increases confidence. In agile, this may be through prototyping, Minimum Viable Products and iteration. In waterfall, it’s done through sharing designs and phasing deliverables.
Work in the open
Transparency builds trust. Collaborate by being open, honest and transparent, constantly collaborating with your stakeholders, and regularly demonstrate progress towards your shared outcomes.
Consider embedding a stakeholder representative in your team. Be realistic about both forecasts and progress – agreeing to arbitrary deadlines, reporting optimistically and then having to reset baselines helps nobody.
Within the team, draw up a team charter to create a shared understanding of your team’s working principles, and your commitment to each other.
Values are a core part of a culture. When people understand and live within shared values, they gain psychological safety, and the culture is conducive to teamwork and collaboration.
Understand your pace of delivery so you can deliver predictably
You should plan and forecast regularly, so you can set realistic expectations which you review, adjust and communicate, reflecting the pace and reality of delivery.
To do this, you need to set measures, and have access to your measurement data. Measuring progress and performance can:
- Help you predict, over time, what you are likely to deliver.
- Support you and your team in keeping yourself honest and fixing problems.
- Metrics can help you spot bottlenecks.
- Metrics increase transparency and through this, trust.
Taking a data-driven approach to delivery removes subjectivity from planning and improves the quality of decision making. Data can be persuasive, help inform priorities and provide assurance.
Manage your risks and dependencies
First, understand your risk appetite, then recognise that risk management is big. It takes time and skill to understand risk types and develop a risk strategy.
Aim to have a continuous cycle of identifying, reviewing and acting on risks and dependencies. This helps you to mitigate, remove, reduce, and accept risks and dependencies.
A risk could derail your delivery, so you need to recognise, monitor, and mitigate against it. If it isn’t managed, it’s likely to become an ‘Issue’ which will impact the delivery of your project. Remember, early delivery and transparency reduce risk.
Apply appropriate governance
Governance is like the brakes on a car – without them you’d drive very slowly. Apply governance proportionately, recognising its need outside the team, building relationships to ensure efficient compliance.
Governance will help you:
- Do the right thing
- Stay legal
- Make the right decisions
- Have sensible control measures
You may not get excited by it, but you should understand the context of governance, and challenge or adapt where appropriate.
Champion the technical fundamentals
Attention to technical excellence and good design enhances and enables fast, high quality, user-centric, valuable, predictable delivery. Not everyone needs to be an expert in all these things, but make sure you’re considering them and using them to deliver better.
Use technical practices such as test automation, CICD pipelines, test driven design, cloud engineering, microservice architecture, DevOps, alerting, YAGNI and minimise tech debt.
Use product and design practices such as accessible design, design thinking, prototyping, roadmaps, value stream mapping and user centred design.
Whatever your methodology, sticking to these principles will help you deliver effectively and develop your own understanding and expertise in delivering complex projects.
To summarise:
- Use the best delivery method for the problem
- Continuously improve and learn
- Deliver value early
- Collaborate by being open and transparent
- Plan and forecast regularly
- Manage risks and dependencies
- Apply appropriate governance
- Champion technical excellence
To get more articles like this delivered to your inbox, subscribe to our newsletter.
11 comments
Comment by Thomas Rose posted on
Very good. Is this the standard or do you have it as a document?
Comment by Barry Traish posted on
Thanks, Thomas. We've kept the standard simple, so this article has the main points of it. The standard itself is published internally with links to lots of further (internal) resources to help our delivery folks find out more, see what good looks like, assess their own abilities and access learning and development material. We may get round to publishing more of that material in due course, but we probably need to get it a little more polished first.
Comment by john mortimer posted on
It is good to see the word 'complex' in a blog like this. Evidence show that complexity is a very different proposition to deal with than logical complicated services. You highlight the need for different approaches and I certainly echo that in the change and service design work that has been going on since the 1960's. There are well tried and tested methods for dealing with complexity, that should be used. One that is certain from experience, if you deal with a complex service using methods that are designed for logical services, the outcome will fail to meet its objectives and even fail completely. Public sector change is littered with these examples, including in the DWP.
I would encourage readers to look past simply slotting in and modifying what you do to deal with complexity. The way that we understand governance, measures, and the whole design approach is different. Complexity requires fundamentally different principles that underpin the methods. Most importantly I think for this blog, is that digital approaches and digital tools fail to deal with complexity.
Systems thinking is a good place to begin to understand how to do this. Sensemaking rather than Analysis,
Emergent rather than Project management,
Human technology rather than Digital,
Here is an article from Apolitical that details this https://apolitical.co/solution-articles/en/we-thought-digital-would-save-the-public-sector
Comment by Barry Traish posted on
Thanks John. You make some important points and I certainly recognise many of the issues that you raise. The mindset shift to understanding the complexity lens is a difficult one for many people, especially when they have had past success with traditional methods, so I champion that change constantly.
I appreciate the challenge that digital fails to deal with complexity, and there's some good food for thought for me. Perhaps I see Digital in that wider end-to-end context solving human problems for people, but also perhaps my definition is too wide or I am overly optimistic.
Comment by john mortimer posted on
Barry, thank you for your thoughtful reply.
I hope you will agree with me that this is primarily about us learning and sharing together, to explore using evidence, what works and what does not. Much of what I see that gets hidden from view, are the gems that we should be learning from. It is about looking at examples of where we can learn from past work, that is not framed in blame and finger-pointing.
In the end, we can debate or sit in a room and talk. But what I find most helpful and refreshing is to go together to learn from the reality of what is occurring from those that are at the edge of this work at the sharp end, that is most unlikely to end up in research or academia.
Comment by Barry Traish posted on
I do indeed agree, John. One of the reasons for sharing this blog is to obtain feedback from others at the sharp end and with diverse experience in order to improve.
Comment by Luke Tagg posted on
Thanks Barry and team great insights and something I will refer our community of practice to.
Comment by Barry Traish posted on
Thanks for taking the time to read and comment, Luke. All feedback from your community is welcome.
Comment by Shelley Hardman posted on
Great to see this Barry. Did sharing of knowledge and experience factor in the thinking leading up to this? There is a key role all of our teams and our leaders need to play in creating conditions where those who are pioneers and forging into new ground (change leaders) need to pay it forward so those that come next (the followers) can adopt and adapt. All too often we can find teams reinventing the wheel, when we have so many common aspects to our services and the business capabilities needed to deliver these. Would love to chat to explore how we can collaborate to strengthen this leader follower way of working.
Comment by Barry Traish posted on
Indeed it did, Shelley, hugely. When creating the Delivery Digital Guide, which underpins these standards, our hypothesis was:
"If new and experienced delivery practitioners and other Digital Group colleagues had easy access to a continuously evolving DWP Digital Delivery Body of Knowledge the pace of value delivery will increase, there will be less reliance on word of mouth, consistency across teams will increase and learning for all will be easier."
Whilst our standards are there to ensure everyone is considering the ways they should be working, the underpinning knowledgebase is there to share current good practice without being prescriptive. As my colleague Ben Leighton said about creating it, "Don't try to be perfect or comprehensive, but if we each write down what we know on a topic, we will capture the entire organisation's knowledge." [He was actually more eloquent, but that's the gist].
Comment by Shelley Hardman posted on
Smashing Barry! I'll be in touch to learn more and see where our work can connect 🙂