Is Dual Track Development , a Dual Track Agile(with Scrum)?
Have you heard the term “dual-track development” before, if no, then this is the article for you to get some traction.
Dual track dev is or focuses on cross-functional product team which breaks its daily development work into two tracks
Here are some of the features of this kind of dev:
a) It does not require that the Discovery Team should define all product backlog items before the delivery team can begin its Dev work.
b) Dev work focuses on design ie dev and quality
c) Discovery work focuses on fast learning or validation
d) Discovery and Dev are assumed as two tracks since it’s two kinds of work,
e) This assumes that discovery is an essential part of Dev .
f) While a PO , dev designer, engineer may lead discovery, part , whole team could be involved in discovery tasks
g) Keep discovery work and progress visible to the whole team.
h) Measuring and learn even after shipping or after move to prod.
i) Can improve release velocity with high collaboration
j) Incorporates quality, scalability, performance, localisation etc quickly into the cycle
k) timebox discovery cycles
How it works (potentially)
Discovery Track :
1) Engage stakeholder ie get buy in
2) Develop personas or Epics or user stories
3) Conduct MR ie surveys, user interviews, analysis, etc
4) Prioritise, check feasibility
5) Move ‘items’ onto Delivery Team ‘backlog
6) Measure ‘“Discovery Velocity” ie for each cycle , idea converted into backlog
7) Create ‘Release Backlog’
1) Build wireframes, etc
2) Design, Dev use stories
3) Engage users for validation
4) Use feedback for product inputs
5) Measure Dev Velocity
6) Move to Prod or Create MVP
Sprint Planing: It is the same process, however throughout the sprint there is going to be one team doing discovery work, like analyzing opportunities, performing user testing, prototyping or designing, while other team does coding software, testing or setting up infra/ servers.
Daily Scrum: The daily Scrum happens as usual but followed by daily discovery meeting. Also everybody should participate in both, however, sometimes that’s not possible. so make an agreement.
Sprint Review: Usually Plan for 1–3 hours for review meeting and also a detailed discussing might not be of interest to customers/ stakeholders, so plan for a shorter review. Focus more on Delivery here more than the discovery.
Retro: This is BAU and done after Sprint Review.
One can use Scrum or Kanban for panning such kind of dev work. Let’s check Kanban model in the next article.