Why Dual Track Agile?
“Our job is to consistently deliver new value” – Marty Cagan.
Have you ever felt that you spend too much time in Sprint Planning ceremonies which are filled with chaos and lack of direction? Teams ask Product Owners questions which they don’t have answers to, and the acceptance criteria is elusive if at all present. To address these problems of lack of requirements, vision and viability, many organizations have started looking towards Dual track Agile. Dual track Agile is a software development approach which is gaining popularity around the globe, especially in teams where the business value management aspect falls short, characteristic of many Agile teams today. Adapting your organization to have a product focused culture will result in products that your customers love, and that you love developing.
What is Dual Track Agile
Dual track Agile, or Dual Track Scrum as some call it, is, as the name suggests, two tracks of Scrum, executed on the same rhythm. This means Discovery Team runs a few sprints ahead, one track focuses on Discovery while the other track is appropriately called the Delivery track. Dual track Agile introduces the concept of having a strong UX design team that works with both tracks to ensure tested user experiences flow into the teams for consideration in building the perfect product.
Today we find in many Sprint Planning ceremonies that the user stories do not meet a pre-defined definition of done: they are vague, with no acceptance criteria and sometimes the Product Owner is unable to explain the bigger picture and express the value it would un-tap. No effort was expanded on actually checking whether the requirement is viable through customer testing, neither was it validated by research. Needless to say, this chaos wastes many people’s time and makes for an unexciting life at work.
The lack of design have its own problems down the line, such as design taking place during coding perhaps even in the code. As the direction of the product change, all this has to be reworked, one of the 7 sins of software waste. Naturally this lack of design comes with technical debt and lot’s of costly rework.
In the Agile community teams spend between two and eight hours grooming the backlog per sprint, which is the process of team collaboration around the requirements for mutual understanding of the upcoming work. Many Product Owners in today’s organizations are ill equipped to test business value and viability. Add a dose of SME illiteracy and you have a lethal bomb owning the product.
The idea behind dual track Agile is that you usually have two sprinting teams, flowing at the same cadence or runs a few sprints ahead. One team, the Discovery team, is responsible for understanding the business cases, target market and asserting viability through research and testing. Our job on a project like this is to continuously innovate through continuous discovery. Another team then works on getting the product out the door.
Dual track Agile certainly shows huge potential in increased sprint throughput, increased velocity and product quality that shoots through the roof. During Discovery, it is imperative that Product Owners discard features of little value as soon as possible. The Standish group reports that 64% of developed features are hardly or never used.
Products are also not enjoying the return on investment they deserve due to misalignment with customer needs and bad, poorly thought out user experience journeys.
The Discovery team purely focuses on validating the needs first and works hand in hand with the user experience team to satisfy the customer’s expectations.
“You have to start with the customer experience and work backwards to the technology” – Steve Jobs
As we are working in iterative cycles of discovery, testing and building code, no feature should be fully developed in one sprint, as this contests the short value adding feedback loops which we use to re-calibrate our plans and make our product great. Having well defined, validated user stories to work from, will reduce the amount of sprints required which translates to decreased cost, and higher morale. These user stories are defined by the Product Owner in collaboration with testers, UX designers etc. No siloes or mini waterfalls can support dual track Agile.
Are your backlog items cost effective?
From my various client engagements a trend emerges to populate as many things on the backlog as possible (placeholders), without any validation taking place. Purists would argue that these need to travel through the cone of uncertainty to reach the definition of ready for the Delivery team, and not invest too much research and validation upfront.
Through Lean thinking methods, like Lean Canvassing and low investment (paper) prototypes, we are now able to eliminate a fair chunk of those backlog items before they get stale on the product backlog. In the Discovery track we use another Lean idea, being the Minimum Viable Product (or MVP). That is, delivering just enough of the product to have the consumer perceive some kind of value, a hook that will make that person come back for more.
Enhanced customer experience
Having the customer on-site working together with the development team (indicated in Scrum and XP frameworks) sounds great, but my observations specify that this free-for-all on the development floor is a breeding nest for disruption of productivity. Create certain time boxes where developers could interact with organizational counterparts, like UX designers, product proposition people and analysts as examples.
User experience teams work closely with the Discovery team and customers to gain valuable insights into the minds of the customer (continuous discovery), which is incorporated into the prototypes (continuous innovation), and retested.
How do we start with Dual track Agile?
The best time to have planted a tree was 20 years ago. The next best time is now ~ Chinese Proverb
It is really simple, you just start. There are already business oriented people that (hopefully) look after the interest of the customers. And off course you already have the technology team, the â€œIT peopleâ€.
You start by cultivating a common understanding that our testing of any feature before commencing any work on it is vital to the success of the project, and that Product Owners and Analysts creates great user journeys and experiences for the customer. Feedback is constantly discussed in the teams, and with customers.
The Discovery team (UX and Business in above image) will document their findings, and be responsible for creating user personaâ€™s, exploring and validating features and defining acceptance criteria for the user stories. The Product Owner continues driving relentless ROI on the backlog and provides clear vision and priorities to the rest of the team.
The user stories created are distributed to the Scrum teams, discussed and decomposed in backlog grooming sessions, and then implemented. Once a feature is completed, it is deployed to a Demo environment where a target segment of consumers as well as the Delivery team can play with the software, and provide feedback in very succinct feedback loops.
Based on pre-defined success criteria for this wring-fenced alpha testing customers, once these tests pass, the product could be expanded on further until the MVP is production ready.
Please share your Dual Track Agile experiences with us by hitting us up on Twitter @Agilocity_ZA using #DualTrackAgile.
More insights into this exciting world:
Marty Cagan on Continuous Innovation: How to create products that customers love
Jeff Patton Discusses Product Development, Agile, and Story Mapping