The Devbridge way works

The easy way out would be to state that Agile solves most of the problems, but that’s hardly scratching the surface of what it really means to be product-centric. While Agile is beneficial, it doesn’t work without a proper organizational structure to enable autonomy. A healthy organizational structure needs progressive funding techniques to enable experimentation. Experimentation will hit a bottleneck if fundamental engineering best practices are not in place, such as automated testing, DevSecOps, and CI/CD. To understand the Devbridge way you need to consider placing the product at the center and then integrating three mature disciplines as part of a single cross-functional team: product management, product design, and software engineering.

We employ nimble, cross-functional teams that iterate over the product scope and ship functionality in sprints (one- to two-week blocks of work). The team focuses on delivering a fully functional fragment of the product by the end of each sprint for demo and acceptance by stakeholders. An article published by Microsoft Research states:

Over time, consumers of software and software-intensive products increasingly welcomed more frequent software releases. Simultaneously, software began to be distributed electronically, and software-as-a-service (SaaS) increased in popularity. Traditional methodologies were viewed as too slow, not customer-focused, not adaptable, and too bureaucratic to handle the new software reality. In response, Agile methods emerged in the mid-1990s, and the Agile Manifesto was published in 2001 to propose methods to allow faster software development and release.

Avoid waterfall failures

At the core of all iterative delivery methodologies you can find the following best practices that help avoid failures of waterfall:

• The build-measure-learn loop. We ship working software every two weeks and are able to demo, validate, and gauge the success of that piece of work with our clients and their customers. Measuring and learning along the way allows the team to pivot the product and refine requirements to meet business outcomes. Product designers perform user testing with 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 risk, fail, and succeed. All team members are aligned and working toward a single goal.
• Just enough requirements. The team 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 enough context, prioritize, and start iterating. The initial story map turns into backlog that is further refined throughout delivery.
• 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 microfailures 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.

Dual-track scrum

Most of the product teams at Devbridge operate using a dual-track scrum methodology—a simple agile delivery framework that facilitates collaboration and problem solving. 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). Every two weeks working software is delivered during a demo, learnings are captured, and backlog is further refined to deliver maximum value aligned with business outcomes. The dual-track nature of our process deals with long-term ambiguity and complexity—part of the team is constantly scanning ahead and laying down the tracks for the full team to run on. While the build may start 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.