Acme, a software company, has a technical excellence problem. Its customers report more problems than the product teams do. Two managers, Cindy and David, want to bring specialized training in for product teams. (They want to help their teams learn to use Test-Driven Development, TDD, and Acceptance Test-Driven Development, ATDD. Cindy and David suspect that […]
The larger your product, the more likely you have components teams. I often see component teams because of the architecture of the product. In this first image, the Integrated System Program, the rest of the product uses the Platform of Common Services as components. Also, the teams find it tempting to think of the common
Continuing the series on dependencies… Maybe you don’t have the problem where the team creates internal dependencies with their process. And you don’t have to wait for someone outside the team to approve your work—an organizational process. But you do have a combination of platform/component teams and feature teams. I see this most often in
Does your organization have an enterprise architect or Chief Product Person? We create these positions to check that the teams don’t try to implement something “wrong.” However, a single person in this position creates bottlenecks and dependencies. (A committee might create even tighter bottlenecks.) Those dependencies slow the work. If a person delays the work,
Even when managers try to create cross-functional teams, the teams still have dependencies. Dependencies slow and make finishing the work more difficult. Too many teams have a built-in dependency creator—code review. When we take time to perform code review after we write the code (or the tests), we create dependencies between the people on the