Dual-track Agile: How to optimize product development?
Agile product development for external customers can be very challenging. Primarily, because from the customer perspective, it can be hard to understand the concept of not having a fixed scope or a fixed timeline for getting it done. When clients hire you or your company for developing their next digital product, they have an urge to know exactly what they will receive and when. Now, if we’re talking about a MVP (where there’s no much room for de-scoping features) and a fixed timeline, wouldn’t it look like a waterfall project disguised as agile?
The short answer is: no. At least, not necessarily. It will all depend on how you will handle this as a Product Manager. You can choose to run Discovery totally separated from Development, circumstance where I don’t see much difference from a waterfall approach, considering the only Agile aspect of your product development would be the adoption of development sprints and its ceremonies.
A different approach is to bring the customer closer to your team. Having them actively engaged through the whole process, aware of what’s being done, following up development and making trade-offs, as needed. Sometimes, by their own initiative. Mitigating the frustration that generally follows when this kind of decision needs to be made.
Dual-Track Agile can help you a lot bringing your customer together. Basically, you’ll will have two distinct, yet intertwined, tracks: Discovery and Development. Even though it can sound like additional work, tasks and meetings to your team, it will improve your team’s efficiency through many aspects I’ll bring out later.
The key thing here is to have your customer engaged in the discovery track. Getting customers engaged when they’re not familiar with Agile. However, it doesn’t take long for results to show up and and for them to perceive value.
For that to work, it’s critical to have roles and rules well defined beforehand. Let the customer know what to expect and when. This will also help them seeing the progress being made along the way.
It’s very common for products where the customer is the SME (Subject Matter Expert), to get surprised by business requirements that were not initially identified — or at least not mapped as required for the MVP — to be found out as actually required after we have started developing. Probably, this kind of situation will affect the original estimates. Therefore the need of having the customer onboard from the beginning.
Discovery track is where the previously mapped features will be detailed and refined. It’s very likely that the initial estimates are based on very high-level requirements. Generally, they will be based on features such as “order a pizza”. However, it will be on the discovery track for that feature that it will be up to you to bring it to a lower level, letting the customer see that even such an obvious feature — at least for them, who are used to it on a daily basis and have all business rules and logic in their heads— might turn out to be not so obvious for those who will have to build it. The customer may already know how to order a pizza, and even do that “automatically”. But when this becomes a feature for your product, you need to know several things such as: how will the pizza be ordered (web/phone)? Who will receive the order? What is flavor and size? What should we do when there’s no answer from the pizza provider or the flavor and size are not available?
That’s what we must do on this track: question all details of the process. Map, identify the business rules, draw flowcharts, identify gaps, blockers and non-functional requirements needed for a given feature. Perhaps even predecessors that need to be in place for that feature to work or have value. Most of these answers will come from your customer. Thus the reason for making them part of the process. It’s also on this track that we’ll have our UX Designer working on prototypes and validating them with the users.
Only when the feature is well defined and clear enough, it shall move to the next track: Development. By that point, dev team will already be familiar on what’s expected and why. And this will make the difference, as their velocity tend to increase significantly, since the feature will get to them already refined and validated.
These are the benefits you can expect when adopting Dual-Track Agile:
- Customers get more engaged, as they feel being part of the process;
- Customers comprehension that requirements that may seem obvious and simple to them, can turn out to be actually more complex than expected when you exercise documenting the business rules and processes behind them;
- For being part of the process, customers are constantly up-to-date regarding the progress being done, without the need of having regular reports that can be very time consuming to make;
- Team’s velocity increases when they don’t have to spend a lot of time clarifying features/stories;
- Trade-offs tend to be less painful for the customer;
- Results and benefits are noticed in short term, not requiring much efforts for your customer to perceive value in doing this.
Of course, results can — and will — vary depending on the product, project, customer, etc. Remember: “It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.”
― Marty Cagan
