The Product Moment: Triple Track Agile

How do you combine waterfall processes with agile software methods? Here is an introduction to some concepts I have been trying throughout my career.

About the author: I am Brad Boyer. I am the Chief Architect for Volkswagen Automotive Cloud. I have 23+ years building digital products in startups, growth stage, and Fortune 50 companies. I have built pure software products, petabyte per year genetic research machine learning systems, defense communication platforms, award winning telematics products, and autonomous/connected vehicles sold globally.

I am continuously trying new methods while learning and collaborating with industry leaders like: Marty Cagan, Jeff Patton, and David Bland. I like to share ways I find to creatively get things done, enable empowered teams, and deliver products people love. Below are some lessons I have learned in hopes of helping others accomplish their goals with very large products that use hardware, mechanical, and software systems.

Over the past 4 years I have been exploring and applying methods for

teams to globally deliver large scale projects without losing the iterative exploration of scrum-based agile processes.

When you are building with 30,000+ engineers globally and trying to deliver long-lead mechanical and electrical systems simultaneously with iterative software loops, it is easy to lose the essence of experimental discovery or even get lost in the discovery processes. Finding a balance to coordinate all these spinning plates

and not just building to order, but empowering teams to build to customer delight is not an easy task.

Imagine coordinating software deliveries for infotainment, body computing, engine controls, and safety. On top of this you are coordinating thousands of people, vendors, and suppliers to deliver plastic components, metal body components, wiring, electric drive systems, autonomous safety components, internal combustion platforms, all having shared and independent requirements. Waterfall methods are still dominant in these industries because delivery windows are immovable and many components have independent testing and validation cycles with long lead times and competing production line dependencies. Miss a window, miss a vehicle launch by potentially 3-5 years.

It is the same for many industries. Whether you are building plains, trains, or automobiles. As richer features are required by customers, many of these large product platforms share multiple dependencies to meet the delivery window, but need short term discovery loops to explore feature viability and customer/stakeholder delight. The essence of investigating a new customer need/hypothesis while ensuring a long lead item will be ready on time is a tricky an sophisticated problem to solve.

So what can you do?

Enter triple track

You are probably looking for the back button or thinking of closing the blog now, but hold on its worth a read here, I promise.

I don't know about you, but when I attend training or webinars on building using modern product methods, many of these examples are fairly simple scenarios and very customer, captive audience facing. When you are building systems that require thousands of people to coordinate across the globe, these examples begin to fall apart.

How do you blend Program Management with Product Management?

Try treating your program milestones as a product roadmap and focusing on the empathetic journey of your teams.

In the traditional dual-track agile process you create two loops: discovery and development/delivery. In discovery, teams focus on relentless testing with customers and experimenting constantly. The learning is then passed to the potentially shipable track and then product increments are released. This cycle-time can vary from hours to weeks, depending on your team, product complexity, and build pipelines. The problem with this, in large companies and large systems, is the software teams can typically outrun the "hard" product teams. You can overcome some of this by creating testing harnesses, digital twins, implementing unit test rigor, and having system tests in place with even simulation hardware. That is not the problem I am discussing here. The problem that I am addressing here is when you apply the Dual-Track agile method at scale and do not map the overall programmatic key milestones you get lost in the discovery loop. In addition, when you apply scrum or SAFe methods you may help out the software teams, but the hard product teams still struggle to work with you and deliver with you as a whole team.

Here is a hypothetical example:

You are creating a new boat platform. This new boat has an electric drive. I know, I know this is probably a crazy idea and a bad example of a electricity and water mixing. But let's continue... This boat has multiple large scale, hard and soft systems. Electrical motors, electric drive controllers, the battery system, steering and navigation systems, and much more. You also have firmware and software that coordinate across and interact with these hard systems. When the team starts from day one, each team begins diligently experimenting in the discovery track. The battery team explores requirements, they are given cost constraints and maybe even vendors they must work with. The firmware team begins understanding the constraints of their memory availability, the I/O of their processors, the speed of the compute cycles, OS selection, and much more. The software team is developing remote navigation systems with over the air software updates, and 3rd party content and data services. They all begin seeking and hardening requirements through interviews, experiments, and even prototyping.

STOP....

Take a step back and look at this: You now have over 100 people on different teams, with different approaches, and different backgrounds, skills and expertise all seeking to build the same thing "an electric drive boat". They are all focusing on their piece of the puzzle, relentlessly experimenting, seeking to understand and delight. So who knows the entire puzzle? Who has the box cover of the picture of the puzzle? This is why a third track needs to be implemented. The programmatic track.

What is the programmatic track?

First, check your bias at the door. The word program I am sure triggered old school mindset and now you are tuning out a bit. Stay focused: This third track is similar to a product roadmap. In the case of the electric boat you have a launch date set. A press release at the big boat racing event.

You can't miss this date!

You've told all your friends how cool this is... The press releases are already out... They are serving your favorite BBQ and beverages... You take a roadmap approach:

What are the parameters, the must haves, by the show/race?

What promises have you made already?

- Pricing?

- Charge times?

- Speeds?

- Features?

These items help formulate your product vision and customer commitment. They map to your product roadmap. These performance parameters, pricing, and features need testing loops with customers and fleshed out to see if they can become a validated hypothesis.

The third, programmatic track begins with the hard products or long lead, immovable items that drive a deadline. The components that have tooling, more predictable elements, outside or regulatory dependency. A good work breakdown structure can help you with these components. Many large organizations have templates based on historical performance for these components. Don't stop at the WBS though. Take creative license with the WBS and find new ways of prototyping, testing, and discovering. Use the WBS as a guideline to map what is

driving the release dates and key milestone timelines. These are the goals of the journey.

Make sure you take into account the outside dependencies such as the testing windows for regulatory and safety compliance or availability for specific testing facilities. These testing cycles typically have known windows too.

Now for the slightly different part: Work with ALL the teams to show them key dates for prototype hardware, first tool releases, testing cycles, customer commitments, etc. Create an overarching story map for the project to deliver the product. Think about the road to delivery for each team. Map their journey together to deliver the overall product. This is the UX of the teams.

Each team has an empathetic responsibility and journey to the overall goal.

Now you are focusing your third track on the empathetic journey of the teams. Each team then breaks away to deliver their empowered method of delivering to the overarching story map.

This is a very high-level depiction of what I am discussing above. This represents the programmatic tracks and the empowered, self-owned team's work as it relates to the overall needs of the program/full-product dependencies. The empathetic team story maps are generated by each team once all the dependencies and long lead items are clearly understood. They then break out and describe their empathetic journey to delivering their portion of the product. The team's expertise in capturing the needs of the customer is expressed here in their independently owned map. These individual story maps can then be aligned to demonstration points where the product can comes together and demonstrates functionality as it matures.

The work performed for each element of the product is still accomplished using the discovery and delivery/development tracks. These can be adopted for hardware, firmware, mechanical, and software needs with a little creativity by the way.

The Discovery track still uses methods from Jeff Patton, Marty Cagan, and David Bland by focusing on they hypothesis to test, the assumptions you are making, and the experiments you can run to gather evidence. Whether it is creating a mechanical 3D print or interviewing a customer to discovery their UX need, it is all the same flow. Find evidence of your assumption or belief before building too much. Record your tests and learning records and then review them for the development track. Now you are working with validated learning. Your development track builds on your proven, tested results and is pushing the product forward with confidence. The teams are all aligned by their story maps and overarching work breakdown commitments. The product roadmap has clear demonstrable windows/needs that the customers, executives, stakeholders can see incrementally progress toward the final product start of production (SoP) or MVP goal.

Think of this at scale.

The example above is just one product, but think about what happens to boat example when you have multiple product lines with multiple models in each line.

You manufacture

- Speed boats

• Entry level to Full racing

- Diesel Barges

• River

• Freight harbor specialty

- Yacths

• Catalog order to Full custom

- Fishing boats

• Two person to Competitive fishing

Now your core components may be reusable on many models but this becomes an exponentially tricky space to deliver hard and soft products. Each product line having regulation constraints and testing constraints as well was manufacturing and supply chain needs. You must establish a clear understanding of the common platforms, repeatable programmatic processes for estimating work and balancing resources, as well as highly agile methods for testing and solving for customer needs and delights.

This is where triple track helps.

• Clear program goals are mapped out and explained to the teams.

• Teams interpret these goals and declare their program empathetic story map to ensure the goals are met.

• The teams and program agree to and continuously review the story maps in rolling window cadence.

• The teams mature the product using discovery and delivery loops, giving them independence to explore test driven hypothesis resolution and product incremental delivery as they see fit.

These steps work together to enable large program alignment but seek to gain customer delight, team creativity and empowerment.

There is a lot more to write about here, but this is the experimental method I have been playing around with for the past 3 years. So far, it seems to be working. It enables a large corporation that is very waterfall minded and driven to embrace team autonomy and empowerment while ensuring evidence of progress being made toward a common deliverable for large systems/products.