Skip to main content

Dual-Track Scrum

Last post 11:33 pm October 8, 2018 by Thomas Owens
5 replies
01:40 pm July 23, 2017

What are your opinions on Dual-Track Scrum?  I've only recently been 'exposed' to it and I'm struggling to find any real case studies on it.  

It seems to me, from what I understand, that it is a way of justifying team's to not be fully cross-functional.  It also seems that it may be a decent way of temporarily managing development while an organisation tries to work towards full cross-functionality, but is not quite there yet. (Emphasis on temporary)

Anyway, I might be off on that, and if someone could direct me to case studies or anything where there's actual data to support it, that would be great!

 


02:00 pm July 23, 2017

No edit, but am I also correct in saying it's sneakily adding 'phases' or 'stages' back to development?  


05:55 pm July 23, 2017

That seems like a fair assessment. A "special" sprint antipattern may well emerge along with the role silos to support it.

In Scrum, if a hypothesis needs to be validated, just use a Sprint to frame and deliver the corresponding MVP.

On the other hand, if scope needs to be better understood before work can be planned into a Sprint, improve Product Backlog refinement such as by means of investigative spikes.


07:52 am July 26, 2017

Hi Ian, on the face of it may feel like it's running against the traditional scrum/agile grain.  Your suggestion certainly fits with everything we know and love about scrum, but it does get messy in practice.  Confused sprint goals and interruptions to producing shippable increments are a couple of the side-effects.

I've been researching to try and find a better way of incorporating user research into the cycle.  A lot of Jeff Patton's (he came up with the idea) assertions make a lot of sense.  Keep an open mind, give it a read.

http://jpattonassociates.com/tag/dual-track-development/

 


01:29 am June 10, 2018

Great link, Steven! Thanks for sharing!


11:33 pm October 8, 2018

I've been looking into dual-track agile to solve some problems that I'm facing, and I believe that it shows promise in some cases.

The two tracks in dual-track agile are discovery and delivery. Discovery is all about defining the problem, defining the desired goal or end state, understanding stakeholders and their processes, exploring solutions, evaluate the initial solution set against the problem and desired goal, narrowing down the solution set and validate with stakeholders, and creating requirements for the built product. Delivery is about taking the chosen solution and turning it into a consumable product through design, development, test, and delivery.

Different people tend to be the primary actors in each track. Discovery would tend to involve product managers, user experience designers, business analysts, and other similar roles (every company has different terms for these people). Delivery, at least in complex software, involves software engineers, testers, operations, release engineers (again - lots of different titles and roles and positions). However, there's going to be cross-over. During discovery, software engineers will likely be needed to ensure that solutions are technical feasible or to help evaluate technical tradeoffs when deciding between two or more solutions. Also during discovery, testers may offer insight into tradeoffs between solutions and help to ensure that the requirements created are good enough to be useful. During delivery, new ideas may surface and product manager and user experience engineers or designers would need to weigh in on changes to the product. They can also support the testers to help make sure that the requirements are well understood and that testing is adequate.

I can definitely see some risks with dual-track agile that you would need to watch out for. For example, you'd want to make sure that your development teams are cross-functional - make sure that your development teams have all the roles they need to function as a delivery team, which may include expertise from discovery teams. You'd also want to make sure that the discovery work is properly feeding into the Product Backlog of the delivery teams, assuming your delivery teams are using Scrum. I can also see a risk of sending all work through discovery and then delivery - some work may be small enough and well-defined enough that a cross-functional delivery team can take on the work within a Sprint timebox (if your delivery teams are using Scrum).

I don't think that dual-track agile is for everything. It may not be appropriate for all teams, all organizations, or even all types of work. But if you have complex discovery work, it can definitely lead to a more agile business as a whole. You may find advantages to having product managers and user experience engineers and perhaps even software architects working on discovery ahead of the delivery teams. If you frame discovery as a process that produces a product (requirements, wireframes / mockups, and perhaps a design system) that is then used by delivery teams to make other products, it may become a little more clear.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.