Build iteratively
Having the proper cross-functional resources in place throughout sets product organizations on the right course to build products successfully. At the core of all iterative delivery methodologies, you can find the following best practices to avoid failures of waterfall:
Just enough requirements: The cross-functional team with representation from each discipline works with the business to establish a high-level product strategy with agreed upon outcomes. Then a more immediate exercise is facilitated to define a set of Lean Requirements (often captured by a story map) that help the team to build up enough context, prioritize, and start iterating. The initial story map turns into backlog that is further refined throughout delivery.
The build-measure-learn loop: Ship working software every two weeks. Demo, validate, and gauge the success of each piece of work with stakeholders and customers. Measuring and learning along the way allows the team to pivot the product and refine requirements to meet business outcomes in lockstep. Product designers perform user testing with the working product and real customers, further refining the value generated with the product.
Complete ownership: Design, technical, and strategic decisions are made inside the team to meet business outcomes. The team feels empowered to take risks, recognize and learn from failures, and celebrate successes. All team members responsible for the product are aligned and working toward a single goal.
Minimized failure footprint: At no point is the product being built in isolation, which eliminates the risk of the business getting a product it did not expect. Furthermore, any ambitious aspiration from the team can be tried and, if not feasible after an initial sprint, written off. These micro-failures are never fatal in the context of the overall product budget, yet allow the team to be creative and push the boundaries of the product.
Change funding strategies: Consider using a theme-based funding approach. A single product may have several themes, such as faster onboarding or loan approval. A theme is associated with business outcomes, and funds are allocated to reach those outcomes, not on purchasing specific features. The team is then equipped to make incremental decisions to get to outcomes, instead of mapping the budget to estimates.
Dual-Track Scrum is ideal to manage ambiguity, and high complexity—part of the team is constantly scanning ahead, laying the groundwork for the full team to build on.
Most of the product teams at Devbridge operate using Dual-Track Scrum methodology that facilitates collaboration and problem-solving ambiguous, large product builds. The team establishes a product backlog and picks up the highest priority user stories to be implemented within a two week sprint (duration of sprints varies based on product). The dual-track nature of our process addresses long-term ambiguity and complexity head-on.
Every two weeks, working software is delivered during a demo, learnings are captured, and the backlog is further refined to deliver maximum value aligned with business outcomes. While the build starts with just enough requirements to develop alignment, dual-track assures that there’s enough in-time research and thinking to define the runway as the team starts moving at full speed and exhausts the initial set of requirements.
