Series: What is Agile? Dual-Track Agile
The first part of the series, What is Agile?
If I had a dime for every time I've heard a company claim that they are Agile or uses the Agile principles without knowing what it is and how they would benefit from using the methodology, I would be a rich man by now. Agile, SCRUM and DevOps have been buzzwords in the business for a long time, but why is it more important to claim to use a process instead of actually gaining value from using it? Let us figure out what it really means.
Dual-Track Agile is a methodology for developing software, where making sure if you are spending time developing the correct product is just as important as the development process itself. Instead of a Business Owner handing a PO or PM a task for the development team to execute, it all starts with a Discovery Track. This way the validated hypothesis can be discarded or added to the backlog in the Delivery Track (Hence: Dual-Track Agile). Whether the idea has been validated or not, is dependent on the KPI's your team has been given, the strategy you're delivering towards or the just value the team is trying to generate.
The validation is done by the development team as a unit. The process is often facilitated by the Product Manager but executed by the whole team. This way, if the hypothesis makes it to the delivery track, the team will have full knowledge on how and why the tasks are beeing prioritized. Using other processes, the knowledge often lies with the Product Manager and the Tech Lead.
How do we have an aligned Discovery Track?
Because the Discovery Track can get a bit chaotic and you need to validate hypothesis based on the same parameters, it's important to have an aligned process for the validation. To make sure of this, there are defined 4 questions the team needs answers to before the validation is complete.
- Will they use it?
- Can they use it?
- Can we build it?
- Will the stakeholders support it?
Will they use it?
This is here we need to talk to users and begin testing. This is also the time for figuring out what the success scenario is. Often it's not enough that they will use it. You might what to know how much they will use it.
Instead of creating complex designs or big prototypes, it's often easier just to go out and talk to users. I remember an example the guys from Silicon Valley Product Group told me when looking into gathering data using a drone on a project. First, let's see if anybody is interested in getting and using the data. If so, then we'll solve the issue with getting the drone to work. A development team often has a tendency to focus on the biggest (and most complex) tasks, even though it's often not the best place to begin.
Can they use it?
Start prototyping. We know that the users would use it if it existed, now we need to figure out if the thoughts we're having align with the users. Create a UserLab. Have a little get together with some users and go through the first wireframes. If you have a prototype, this would be a good time to get feedback on it. In this step, it's natural that the UX/UI designer takes the lead. But it's still important that the whole team knows the outcome of the session.
Can we build it?
Of course, we can build it! It will just take us 6 months and then we're done. This is the time to figure out if it still makes sense to take on the task, even though we know that the users want it. The team often looks into different technologies in this step and figure out how many resources that have to be put into it. If the timeline of the team is 3 months, then it might not make sense to begin developing a 6 months project. Perhaps there are som easy wins in the opportunity backlog that should be looked into instead.
Will the stakeholders support it?
Is the task we're looking into something that the management team would approve of? Have we cleared everything with the legal department? Are there any thirds parties that we need approval from? This is the step to make sure that such questions are answered. Basically, the team needs to have its stakeholder management in place. Often this is facilitated by the product manager, but as usual, the whole team needs to be informed and aligned. Do not underestimate the importance of this step. This can save the team a lot of time and effort if done properly.
Now we are ready to begin delivering
When a hypothesis or task is validated it is moved to the delivery track. This is where the team harvests the benefits of a thorough discovery process. Everybody is aligned on why and how the task is being executed and that we expect to accomplish afterward.
Why is Dual-Track Agile the way to go?
Everybody is aligned on what is being done and why the decisions are being made. The team is never spending time on developing products which are destined for failure.
The two tracks make sure that when new knowledge is acquired, it's easily distributed to the whole team and the involved stakeholders.
You always have data to back up the decisions. It's easier to make sure that the team is working on the right tasks when the data is in place for everyone to see. This will save you time on alignment meetings and discussions on why one idea is better than the other.
When the whole team has been involved in the discovery, the team is more motivated to execute the prioritized tasks.
What do you need to keep in mind when using Dual-Track Agile?
Make sure that the knowledge obtained by the team is accessible to everyone. Often it will help to have the backlog and the hypothesis visualized on a board for everyone to see. This will also save a lot of time spend on stakeholder management.
Make sure to show the results and learnings gained by the team. This will help justify the time spend on discovery and by sharing the knowledge other development teams might be able to gain inspiration and use your results in their discovery phase.