Recently, I attended a Meetup on Dual Track Scrum (DTS), presented by Aaron Sanders, and since unfamiliar with this new Agile flavor of delivery, have done some additional research on the topic and here are my initial impressions.
Dual-Track scrum follows the principle that there should be continuous discovery by the product development team in parallel to the delivery. This discovery is normally led by the product owner, the lead developer and the UX/UI expert, but can vary to the key roles in product development based on your delivery framework. Hence there are two parallel or dual paths: discovery and delivery.
One key success factor is to ensure that collaboration of Dual Track Scrum is understood by all stakeholders involved in delivery, from the delivery team to the CTO/CIO, all the way through sales and marketing.
Conceptually and from what I’ve researched, DTS greatly reduces the problem personally experienced with insufficiently documented backlogs that are frequently too scrambled to be DEEP (Detailed, Emergent, Estimated, Prioritized) enough for Sprint Planning sessions. If this is a problem within your organization, DTS would be an excellent suggestion to try. However, it is worth noting that some companies don’t have the resources to support this approach and hence getting leadership involvement to bolster resources to implement DTS would be necessary, a task easier written than performed.
At a glance, my current concern with DTS involves scalability. When mixing in Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS), Dual Track Scrum has an unclear place. However, it would appear that DTS would scale with some adjustments. For LeSS, there are Area Product Owners and Area Product Backlogs. These would be scaled with dual tracked teams and some adjustments would be made for the level of Product Backlog discovery and grooming. With SAFe, the role of Product Management can be extended for DTS without much resistance, understanding that flexibility is key.
My thoughts on DTS are positive and recommend if your organization has trouble keeping the product backlog detailed enough and/or your delivery teams are having to do an inordinate amount of rework after each Sprint Review to seriously consider Dual Track Scrum as a viable alternative.
In my next blog, I shall go into more detail of Dual Track Scrum with the discovery track.