Reinforcing Stream Aligned Teams

Recently a colleague, James, told me about a scheme his employer is currently implementing. Stream aligned teams are on schedule, but don't have enough capacity to deliver new features the business wants and need support to meet the organization's needs, but they don't anticipate needing the support long term.

They decided that they are going to implement floating supporting teams that will come in, build the product/feature that the business needs and throw it over the wall to the original stream aligned team to support and maintain.

This is something that's well understood to be a bad move in the history of the software industry. Even with the best intentions you're not going to have knowledge transfer, and the group that wrote the software won't get to see how the choices that they made in the architecture and design process pan out, inhibiting learning, encouraging finger pointing, and eventual rewrites.

When I heard this I was surprised that a very successful organization would be suggesting such a well known blunder as a solution to their problem. A better way  they could approach this problem is to create a new stream aligned team that owns this new product.

Or if they're confident there won't be enough work to justify a new team building and maintaining this product they should split the supporting floater team and the stream aligned team in half. They could then recombine them to work on the core products as scheduled and the new products, while ensuring that knowledge about this new product is transferred. This is ensured because folks that built it will be re-embedded in the stream aligned team at the end of the project, when the floating support team is extracted and brought onto their next project.

This second approach will result in extended timelines comparatively, but a much better maintenance experience if you must proceed without a new stream aligned team.