Run dual-track scrum

Now that we’ve refined the initial set of requirements for the product, it is time to regroup with the team and review the processes for collaboration. There’s nothing particularly unique about how we practice Agile—we believe in all the core principles set at the Snowbird ski resort by the authors of the Agile Manifesto.

How we differ from most large enterprises is that we have built the necessary organizational structure to foster the behaviors necessary for Agile to flourish. The two most important themes that originate from our values are trust (aka transparency) and ownership. What we’ve found is that teams do the right thing as long as they are given the opportunity for ownership and are trusted with the freedom to act. In this chapter you can review our best practices for Sprint 0, kicking off an initiative, running rituals, performing a state of the union, and many others.

Most of our projects leverage scrum as the Agile framework. We define a story map, convert it to a refined backlog, and refine further as we iterate. Large greenfield initiatives with vast scope benefit from dual-track scrum—a framework which generates just-in-time requirements for the delivery team while constantly scouting ahead and preparing a future roadmap. The same team performs both activities—delivery on one track and discovery on another.

For example, dual-track is an ideal framework to use when building a completely new product offering. As our industrial supply customer discovered, reinventing a merchandising and publishing process is much easier when small incremental feature sets are released to focus groups and requirements are refined through real-time feedback. Trying to define all requirements for a complex multisystem workflow would get the team stuck in paralysis by analysis. While the core of the team was building an initial set of features, the team architect, designer, and product manager focused on discovery and spike activity that would unlock the roadmap beyond an initial few sprints.

A just-in-time approach is useful because a typical product team consumes only a limited amount of complexity and details when focusing on the release objective—anything above and beyond is wasteful to produce. This frees up resources and lowers the cognitive load. Dual-track does not imply that all strategy and planning is ignored—it simply operates with awareness that we may not know full product requirements during early stages of the product life cycle. As the product is released, tested with users, and reaches maturity, less ongoing discovery is necessary. In other words, one of the tracks may be less frequently traveled.

Using Lean Requirements, prototyping, and dual-track Scrum enables our cross-functional teams to delivery 4x more value in a fraction of the time. Multiple pivots throughout delivery are possible due to the nimble nature of the product roadmap.

Important dos and don’ts for Lean Requirements dual-track scrum:

• Don’t: Abandon cross-functional delivery methodology after completing a prototype.
• Do: Start by working on productizing and implementing the needed functionality while simultaneously continuing to define the requirements and design for the following sprints.
• Don’t: Skip the validation of our product.
• Do: Set up user-testing sessions every couple of sprints to demonstrate and test new features with the customer (e.g., feedback from the prototype qualified us to proceed with further investment).

Make a judgment call as to whether it’s viable and necessary to include discovery and user testing in your sprint plan. A small team may benefit from user testing and discovery every four sprints because the amount of work being shipped is relatively small. A squad of five teams working on a major product ship a significant number of features in a single sprint—more frequent discovery and testing sessions may create value.

Use discovery as a means to course-correct the product and improve the release roadmap.

The team does not start Sprint 1 with vague requirements. All the previous best practices of service blueprint, story mapping, and estimation still apply—even evergreen products need a release strategy.