How can we implement "Built-in Quality" across an ART with ten different development teams?

All answers to this question.

Built-in Quality isn't just a buzzword; it’s a set of mandatory practices. At the team level, you must enforce Test-Driven Development (TDD) and Pair Programming. At the Program level, you need a dedicated "System Team" that maintains the CI/CD pipeline and the staging environment. If a team's' code breaks the main build, the entire ART should treat it as a P1 incident. You should also implement "Architecture Runways" to ensure the infrastructure is ready before the features are built. Without a shared Definition of Done that includes integration testing, you are just doing "Waterfall in Sprints."

   Answered 2024-05-07 by Dorothy Lewis

Are you doing "Continuous Integration" across the whole ART, or just within each team? If teams only integrate once every two weeks, the System Demo will always be a disaster.

   Answered 2024-05-11 by Richard Moore

• Richard, that was our mistake. We were doing "local" integration. We’ve now moved to a "System-wide CI" where every pull request is validated against the full solution. It was expensive to set up the automation, but it saved us hundreds of hours of manual debugging during the "Innovation and Planning" (IP) iteration. Now, the System Demo is just a formality because we already know the software works together.

     Commented 2024-05-14 by Daniel Harris

Collective Code Ownership is vital. If teams are afraid to touch each other's' code, you will always have silos that prevent true "Built-in Quality" at the system level.

   Answered 2024-05-17 by Elizabeth Young

• Exactly, Elizabeth. We started doing "Cross-Team Code Reviews" and it helped spread the domain knowledge. It made everyone feel responsible for the whole solution, not just their slice.

     Commented 2024-05-19 by Kevin Foster