This presentation covers key aspects of Dual Track Agile and provides real-world examples and case studies. It also gives some background on the Discovery and Framing framework and is meant for practitioners who have been using Lean-Agile methodology for at least a year.
While the slides do not describe UCD (User-Centered Design), Pair Programming, TDD (Test Driven Development), or DDD (Domain Driven Development), these concepts are assumed in the approach. That's how VMware Pivotal builds great products.
The approach described here is only ideal for Lean-Agile methodology.
If you are the pivot, the most valuable slides might be 4, 8 and 16
The image looks linear but since we use lean agile, think of it as iterative with feedback loops back and forth
The reference to pathological and bureaucratic culture structures is based on this research: https://qualitysafety.bmj.com/content/13/suppl_2/ii22
When time is an important factor: managing to time is a losing battle for product teams. But it is a reality that has to be faced often. Isolate the assumptions that will have the most impact on time and start working on them sooner rather than later.
When you have important stakeholders who are “experimentation” skeptics
When the value stream is complex and no one on the team is an expert in the domain or domains it crosses: large enterprises always have complex value streams. The D&F in these situations rarely lasts 4 weeks. To give the team time to get up to speed on the domains that are part of the product, take out D&F as a dependency for code on day one, or asap.
When you need to deliver outcomes at scale: when all the hypotheses around the problem point to a solution that will impact many teams or customer segments. Again this is a case where D&F will most likely take longer to get to inception (and alignment of all the stakeholders).
When you are one lean agile team working within a pathological or bureaucratic culture that you need to cooperate or bridge with: has anyone worked on a project where your key customers don’t answer your emails for weeks? Or refuse to meet for weeks? It happens, and depending on the engagement sponsor you might have no power to influence your stakeholders to move any faster. Don’t hold up the whole team, start building based on what you know while you continue driving the D&F activities with “low-cooperation” users.
When validating the “path-to-prod” is a high priority assumption: I see this one in 80% of my projects, where the team need to build their own pipelines. Do that, it will be necessary if you want to ship code… at least 80% of the time.
Typical pressure I see in “legacy” enterprise settings: business is skeptical that IT can deliver valuable software. So we need to disprove that right away to gain continued cooperation.
Content for non-pivots to familiarize them with D&F
The cognitive load is real.
Do the basics well: anti-goals define early and don’t forget them, keep your assumptions/risk updated, prioritize the backlog
Resources:
Event storming and Boris (minutes 1-31): https://www.youtube.com/watch?v=neL3OQ1GRhY
Service blueprint: https://www.slideshare.net/KuldeepKulshreshtha/take-a-holistic-view-of-your-product-with-service-blueprints-at-uxsea-summit-2018
Boris name based on the song Boris by the Who, it talks about a spider called Boris