Accelerating delivery: 10 questions to ask your team

Posted on 27th June 2022

Written by Anikh Subhan, Delivery Principal Made tech

If you work in digital in the public sector, you’re probably aware of accelerated delivery. It helps to build projects faster, more efficiently, and with reduced risk.

If your team is new to delivery at pace, we’ve outlined 10 questions to ask yourself and your team to make sure you’re set up for success. But first, here’s a quick recap of the benefits:

Your team will learn early and often, putting them in a better position to get value out regularly, and build on their knowledge, expertise, and confidence. It also creates a safe environment for teams to learn, experiment and trial things to create well-rounded, diverse offerings.

You won’t need to rework things that don’t fulfil user needs because you’ll be using the right feedback and data to make decisions that increase the chances of creating the right product the first time round.

You’ll be able to narrow your focus onto the most important problems and priorities based on value instead of trying to resolve several priorities at once, which will reduce the chances of success.

You’ll be able to pivot more quickly at times when the data and feedback shows something’s not working as expected, giving you a faster time to market, and an earlier return on investment.

Now on to the 10 questions…

1. Do we understand the problem?

It’s a good idea to face the right way before stepping on the accelerator. The end problem you’re trying to solve is key. This question must be answered early, and an effective discovery phase will do that.

The whole team, including management and executives, should be aligned on the problem and its impact and risk.

Once the problem is fully understood and articulated clearly from the users’ perspective, your team can innovate with different ideas and options to solve it.

For example, you could carry out a product workshop focusing on the needs and pain points of the target users so everyone’s aligned, whether it’s at the start or even further down the line. This way you can circle back on your vision so you know it’s still accurate.

2. Do we know our users?

Knowing your users, the impact of the problem and its potential solutions on their lives, is essential. It lays the foundation for looking at designs and prototypes with a critical eye, while answering “have we built the right thing, and in the right way?”

For example, your team can listen in and participate in some of the user research, to see and hear things first hand, which will help close the gap between users and and problem solvers.

This way teams can prioritise quicker by having a shared understanding of users’ needs and the impact the things you’re building have in their lives.

3. Are we empowered?

To solve problems, your team must have trust in the leadership to accelerate delivery. A lack may mean that groundwork is needed.

This means removing overbearing governance so teams can work out how to best solve problems. Governance structures that allow for problems to be surfaced safely and let teams solve them are the ones most able to adopt agile and lean ways of working.

As a leader, your goal should foster good working relationships within the team, and with outside departments and organisations, to provide them with the right platform for successful delivery.

4. Are we autonomous?

Can the team put the tools and processes it needs in place by itself? It might be the freedom to switch from Scrum- to Kanban-based workflows, or from story pointing to t-shirt sizing user stories.

As an organisation, of course, you should have a sensible and appropriate set of defaults, some consistency, and standard notation where it makes sense. But if a team wants to experiment they need to be allowed and able to do so.

Retrospectives are a key forum for this. They should be driving changes in the process as often as needed. An autonomy here applies to a couple of things: it applies to ways of working but also to the thing they’re building.

Does your team have the space, freedom, flexibility and the support needed to be autonomous in arriving at the best way to tackle a problem?

This is critical because getting leadership to provide them with what they need will in turn help them to move blockers and clear a path forward for them, and enables a successfully accelerated delivery.

5. Are the right people involved?

Are the right people in the room (or, increasingly, in the Zoom)? Though it’s tempting to include only design and product people in the early phases, it’s best to assemble a multi-disciplinary team.

Including technology people and subject matter experts means a range of perspectives are taken into account, as well as helping to identify what’s possible, and reducing risk later on. It also helps people in all roles build context and understanding of the product, problems and goals for delivery.

Define who should be at meetings, why, what value they’ll bring and gain, and what their role is. Once this has been established, aim to get the team excited as well as positive and engaged from the start, and strive to make sure this energy is present throughout the delivery process.

Cohesion from the start stops the delivery from stuttering throughout when you might need to get people on board, and understand other constraints.

6. How well do we collaborate?

By building multi-disciplinary teams around the projects being worked on, and removing as many barriers to communication and collaboration between designers and developers as possible, you can reduce iteration cycles from days or even weeks down to mere hours.

This could be a longer term goal for those teams who are at the early stages of their journey or new to this level of collaboration.

These days with many being remote, we need to think about collaboration differently. We need to make sure people have a sustainable amount of time to do things in the right way.

It can be more intense but you should mitigate this by making sure people can take regular breaks and still have their individual brainstorming time.

There are a range of tools out there like Figma, Sketch, and other rich prototype tools out there that can help teams collaborate remotely.

7. Are we diverse?

The more diverse your team, the more experience it can draw on. That means demographics, backgrounds and experience – all essential to bringing different perspectives and reducing bias.

It’s equally important in your personas and user groups to make sure your products address the needs of all users rather than some.

8. How quickly can we iterate?

Rapid iterations are central to accelerated delivery. Automated deployment and testing can significantly shorten release cycles.

For example, with a previous team, we explored a few different testing strategies and managed to automate the whole test suite. We had no manual tests apart from some basic visual and sanity checks, and every change would run through these. Once all of the tests were successful we would deploy to production and go live, and this happened multiple times a day, which helped us to get things out quickly.

Gathering data in as close to real-time as possible helps you iterate quickly, and in the right direction. By demonstrating that rapid release cycles are possible, you can build trust in your organisation that accelerated delivery is the right approach for more substantial projects.

9. Are we working towards the same goal?

Design teams working ahead of a dev team can create a false economy. Creating hand-offs, along with the back and forth around briefs that that entails, is a recipe for duplicate effort.

Remember the goal here is to minimise rework and reduce waste so you can deliver value faster, and you’ll be in a better place to achieve this if everyone receives the same brief and context, works on the same problem, at the same time, and plans and defines goals together.

For example, this could look like doing stand-ups, planning, refinement, showcases and retros all together so you’re a fully multi-disciplined, cross functional team.

10. When can new joiners start to contribute?

Making sure new team members are productive from day one is about more than productivity – it makes them feel valued, and sets the right tone.

This means having the right information available at the right time, getting people started and getting onboarded efficiently and effectively.

When new joiners struggle to contribute, it may be a sign that better ways of working are possible. For example, you could break up projects into small tasks and encourage others on the team to work with new joiners to get them off to the best start.

It’s about creating an environment where everyone can make a valuable contribution to the progress of the delivery. Plus you get the added benefit of avoiding knowledge silos which reduce the risk of institutional knowledge loss when someone leaves.