It’s amazing how the most innocuous statement can get the mind racing. One of my teammates went to a Lean Coffee meetup here in town and when I asked how it was she simply gave me the phrase “dual track Scrum”. It had been a while since I’d heard someone mention dual-track Scrum or dual-track Agile. Hearing it again got me thinking about its implication to Agile software development. (Thank’s Rose).
In case you are not familiar with the concept, read Marty Cagan’s article on the subject. For the record, I’m a big fan of a lot of Marty’s stuff. In a nutshell, dual-track Agile is characterized by a Discovery track and a Delivery track that run concurrently. The Discovery track is focused on generating good backlog items (probably meeting teams definition of ready) while the Delivery track is focused on developing and releasing software. The output of the Discovery track is input for the Delivery track.
Dual-track Agile is implemented by many Agile teams in many different ways. Some teams just have a single role on the team creating validated backlog items; others employ an approach similar to the “3 Amigos” where multiple prepare the next set of backlog items to be worked and some scaled Agile approaches have a completely separate team responsible for creating validated backlog items. My least favorite approach is the approach that has been popularized by some scaled Agile frameworks.
So why do teams practice some form of dual-track Agile? It’s to prevent the delivery track from spinning on backlog items that are to be worked on next. I liken it to a scout or advance team going ahead and preparing a campsite for the rest of the team so that when the rest of the team arrives; it can focus on setting up the camp (instead of clearing brush, fetching water or getting firewood).
Agile Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile software development is characterized by regular feedback from customers (stakeholders) as feedback guides the team on what to work on next based on what has everyone has learned from what has been delivered. This is why principle number 1 is so important. Often people see it to be important only from the perspective of getting something into the customer’s hands. This is true but incomplete in my humble opinion. An additional reason why we want to deliver valuable software early and continuously is so that we can learn what really needs to be done next.
If our backlog is largely ordered independent of customer feedback then our team is not exploiting all that Agile software development has to offer. Our goal has become to get through our backlog as quickly as is possible – some may consider this to be a project. Value has largely been predetermined upfront. Some may argue that Agile doesn’t make sense for us if we’re working in this manner while there may be some truth to this, I wouldn’t advocate abandoning everything Agile if a team finds itself in this situation. We may just need to make the best out of the situation while realizing that there is a huge aspect of Agile software development that is not present in the way we work.
The output(s) of the [Sprint] Review (or similar practices) are supposed to serve as meaningful input into the [Sprint] Planning process subsequently guiding the team on what it should work on next. For example, the Scrum Guide states the following:
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
If your teams [Sprint] Review do not serve this purpose then [Sprint] Planning is largely pre-determined based on other factors that most likely do not include customer feedback on what has been delivered.
If as a team we are pretty sure on what we will work on next before completing what we are currently working on, dual-track approaches might prudent. They will probably reduce (what is correctly classified as) waste in the process and improve our cycle times. However, there is the danger of operating in a “waterfall-like” manner with handoffs especially if another team is responsible for creating validated backlog items.
So here is my question for us. If you are thinking of using dual-track Agile, why do you think it will work? Is frequent customer feedback guiding what the team works on next or do you have a backlog of items with the order of delivery largely predetermined and the team is just making its way through the list as fast as it can (showing progress as it goes)? Is this what it should be? Is this the best it can be? What do you think it should be? How do you intend to change things? Can you?
Remember that “a little learning is a dangerous thing”. Progress is dependent on the unreasonable woman or man.