Dual-Track Scrum

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

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.

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/

Great link, Steven! Thanks for sharing!

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.