We have limited Spanish content available. View Spanish content.

Doing Agile Right

Doing Agile Right

Converged Backlogs

Converged Backlogs

Until recently, most organizations separated development and support activities and resources, often with unintended consequences that fostered poor behaviors and limited accountability.

Separation between project delivery on one hand and maintenance and support on the other made more sense with a project-oriented (as opposed to product-oriented) approach, since it allowed a cleaner separation of concerns—namely, more experienced and higher paid developers focused on development, less experienced ones focused on maintenance and fixing bugs. Support resources were either a career entry point or a labor arbitrage opportunity.

Separate backlogs inevitably led to conflicts between innovation and stability. Developers who were focused on adding innovative features were less accountable for writing quality code or performing testing. Support teams felt as though new features (along with many bugs) were thrown over the wall for them to support and maintain, threatening stability. This made the support career path less attractive: slow progression, limited skills development and a career spent fixing production issues.

Product and Agile approaches are different; they break down the wall between development and maintenance/support. Adopting a converged backlog combines development and maintenance/support on a single Agile team responsible for the full life cycle of a product. New approaches and tools, such as infrastructure-as-code and test-driven development, make converged backlogs easier to manage.

A combined approach delivers a range of benefits, including greater accountability and ownership, improved quality of code with fewer bugs, and higher morale with greater opportunities for professional development.