Dual-track delivery
Dual Track Delivery is when Design and Development teams work together, in an iterative way, to get ideas and features in the hands of users as quickly as possible.
What Dual Track Delivery looks like
There are two parallel tracks for Dual Track Delivery: A Discovery Track and A Delivery Track. A feature is passed from Discovery where it is defined, to Delivery where it is built, and back Discovery where it is measured. This is a repeatable process that you continue until you have completed your project.
How it all works
Identify the parameters, scope and users
To start you need to identify the framework that you are working to — this approach works best in Agile frameworks like Scrum or Kanban — for this example I’ll be using Scrum. You also need to identify how much time you will give yourself to release each feature — for this example I will use Sprints and a Sprint will be 2 weeks long. Do what works for you though.
Next you need a list of prioritised features — for this example I’ll be using a Backlog. How those features are identified and prioritised is up to the client, but I do recommend completing product strategy before you begin this process.
You also need to identify who your pilot group is. These people will be testing your features as soon as they are released.
Sprint 1: Get prepared
The first Sprint is all about getting prepared for the release of the first feature.
For Discovery you need to identify the following (for the top prioritised feature only):
- what the technical specifications are,
- what the functionality specifications are,
- what the feature will look like,
- what the interactions are,
- what the visual cues are — hover states etc,
- if the feature is user friendly,
- what the definition of done is,
- can the user complete the entire task from end to end — The thin vertical slice.
- how long the feature will take to Deliver. If the feature will take longer than 2 weeks to Deliver, it needs to be sliced up into smaller chunks. Those chunks can be prioritised also — it might be better to have a slimmed down version of two features, over the entirety of one feature — this is totally up to the client.
For Delivery you need to:
Set up the development, test and production environments. I’d recommend creating a ‘Hello World’ page. There are other things you may want to do — that is up to you, but at a minimum the environments need to be working. You need to be prepared for the first feature to be tested — and you won’t have time to do this in the next sprint — because you will be building the first feature.
I’m not a Developer and am not an expert at setting up environments — but I can say from experience that the lack of a test or production environment can often kill the agility of a project. Without a test or production environment the features can’t be tested and your Agile Project will become a Waterfall Project.
You also want to set up analytics, so that when features are released into the wild, they can be monitored.
Sprint 2: Start delivering features
For Delivery you need to build the first feature (discovered in Sprint 1) and deploy it to the staging and/or production environment.
For Discovery you need to discover the next priority on the Backlog (see Discovery activities in Sprint 1) and make sure the ‘Hello World’ page and the analytics tool is working in test and/or production environment.
Sprint 3: Deliver more features, but also measure the value you have
For Delivery you need to build the second feature (discovered in Sprint 2) and deploy it to the staging and/or production environment.
For Discovery you need to discover the next priority on the Backlog (see Discovery activities in Sprint 1) and start measuring the success of the feature released in Sprint 2. To measure success, you can:
- review the analytics (quantitively research), and
- interview the pilot group/live users (qualitative research).
If at this point you realise that something needs to change, it is added to the backlog ready for prioritisation. Just because the feature is in production, doesn’t mean it is more important than any of the other features on the backlog. Talk to the client, and the team, and identify what the risks are for not changing the feature in the next Sprint.
Sprint 4 and so on: Rinse and repeat
From now on you keep working your way through the prioritised backlog, in the same way as Sprint 3, until you have completed all tasks or until your client says ‘Stop!’.
//
Why so fast?
It is important to release features quickly to:
- identify if they are a good idea or actually needed,
- identify if they work,
- identify if you need to pivot,
- receive a return on your investment early,
- receive valuable feedback early,
- make training and onboarding easier, and
- ensure you have enough time and money to make changes before the end of the project.
Doesn’t testing solve all that?
Yes, you can test your ideas and features before your build or after you launch. However, this is a controlled environment, and you won’t really know if a feature is working until it is used in real world scenarios. This is because not all:
- users are the same,
- environments are the same,
- scenarios are the same,
- the ‘same users’ are the same.
Not all users are the same
A person’s experience with a product will be different depending on the situation. For example, a person that is using a movie ticketing app will have a different experience if:
- they are by themselves during the day,
- with their children in the rain, or
- with their partner on date night.
Helpful tips
Before you go on the rest of your journey there are some thing I’d like to warn you about.
Who does what?
Discovery and Delivery are Tracks, not roles. Designers aren’t solely responsible for the Discovery Track and Developers aren’t solely responsible for the Delivery Track. The different roles work together to discover and deliver each feature — they support each other to:
- create the best possible solution,
- pivot when needed,
- reduce the risk of building the wrong thing, and
- constantly improve the process.
You’ve already run out of time
It is better to act as if you’ve run out of time at the start of the project, instead have it dawn on you at the end of it. I’ve seen many projects that started off gold plated, held together with sticky tape at the end.
Layers aren’t just for winter
Always work in thin vertical slices and layer on complexity as more time becomes available. It is better to have a simple product that works, than a complex product that doesn’t.
Don’t fill time
If you find yourself twiddling your thumbs, don’t fill the boredom with unnecessary tasks. It is better to pause, or support the other Track, than it is to spend time on features that aren’t requested. You might think you’re saving time, but if those features aren’t used, you are wasting time.
Don’t build for a time that might not come
You might be tempted to over engineer a server or flesh out all of the designs early — Don’t, it’s a trap:
- You won’t know what the future of the project is until you assess the feedback for each feature being released. Building for the future is a one-way ticket to Waterfall town.
- You might put an unnecessary bias on something — you’re more likely to go down the wrong path if you’ve already spent time on it.
- The client may decide that the project isn’t needed anymore — and you’ve spent their money on features they didn’t ask for.
Don’t get too far ahead of yourself
As a rule, I like Discovery to be about 2 Sprints of work ahead of the Delivery cycle. I can achieve this because there isn’t usually a 1-to-1 relationship between features being Discovered and features being Delivered. For example — it could take me 2 hours to design a log in screen, but it will take a lot longer to build it. If I get too far ahead, I can give myself more time to do more Discovery, and if I get too far behind, I can reduce the amount of Discovery I do.
Once I know what the team’s velocity is (velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum) I try to Discover enough to keep them constantly busy. 2 Sprints ahead also ensures that there is work for the developers to do if they exceed the expected ‘In Sprint’ velocity.
Discovery can only exist while Delivery time remains
Keep an eye on how many Sprints are left in the budget. If you only have 1 more Sprint, there is no point Discovering more features. You also need to leave time to measure the last features being released. I like to stop when there are 2 sprints of work left to Deliver– and I am 2 Sprints of Delivery work head.
The end?
The end shouldn’t be the end. Save a little bit of time to measure how things are going in 3 months — hopefully everything is running smoothly, but you might spot something unusual that was great in summer, but awful in winter.
The real end. Thank you.
