Practical Considerations for Building Cross-Functional Product Teams
Brian Hardwick discusses cross-functional product teams, building the most effective one, and dealing with the implications of Conway's Law.
Join the DZone community and get the full member experience.Join For Free
“Many organizations try to take shortcuts to higher performance by… adopting methodologies, or reorganizing. But such efforts are neither necessary nor sufficient. They can only succeed if combined with efforts to create a generative culture and strategy across the whole organization, including suppliers and if this is achieved, there will be no need to resort to such shortcuts.” - Lean Enterprise
Although Productization of IT and Agile Scaling practices such as the Spotify Model are commonly accepted in the digital world, enterprises continue to approach these concepts with an over-reductionist perspective. In this article, I will explore some of the more technical constraints associated with re-organizing teams around Agile concepts (these are just a few), and contribute ideas to help organizations get better outcomes by moving towards these models in an incremental, co-evolutionary manner.
1. Implications of Conway’s Law. “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." Or taken in the inverse, once the architecture has been galvanized in code, so too is the organization constrained to mirror it. Yes, rules are made to be broken, but understanding the logic in these rules matters, particularly understanding the notion that architectures must co-evolve with organization change (and vice versa), which brings us to the second consideration to be applied in the evolution.
2. Heterogeneous Architectures. Small, cross-functional teams are difficult to organize around disparate technology stacks, and many organizations are faced with a menagerie of complex COTS frameworks that require distinct specialized skills to maintain and are invariably expensive and hard to find at scale even with help from large IT service providers. High-performance product engineering organizations understand the trade-offs and hidden complexity in platform decisions, favor framework ecosystems teams can reasonably be crossed trained around, and invest heavily in up-front training of product engineers on both reference architectures and release pipeline frameworks.
3. Product Development Flow and Cross Functional Teams. The science of product development flow must be central to team design. For illustration, let’s assume we have seven SCRUM teams and seven highly specialized engineers [complex package of your choice]. We might either (a) embed the specialist into our SCRUM teams 1:1, or (b) build a central Kanban group that services the teams. Which model is appropriate depends entirely on the variability of the work intake coming to the teams. If the flow is steady and predictable we would, of course, prefer to avoid the cost of externalizing dependencies on the Kanban team. However, if the work is highly variable we want flexibility to swarm to the work.
4.The Business Strategy of Small Batches. “You fix it you own it” is a good principle to strive towards and is a composite characteristic of productized IT services. Unfortunately, this strategy can not co-exist in the presence of large projects because teams can not be simultaneously optimized to support the product flow of large projects (SCRUM cycles) and high variability small batch flow (Kanban). Therefore, applying the merged concept to environments that deliver large project SCRUM will have the effect of introducing high variability to SCRUM in a manner that SCRUM is not designed to accommodate. In conclusion, “you fix it you own it” is a great model for teams that work exclusively in small batch sizes, and should support a justification to move away from the IT mindset of large capital projects (where continuous delivery strategies are introduced at least).
In closing, I would like to share my own context for why I authored this post. In my recent experiences on larger digital transformation programs, our teams have been directed to snap into new models of delivery without appreciation for the other factors that must co-evolve to make these concepts work. This comes up fairly routinely for me these days, and I suspect for many others as well, so I hope these perspectives prove helpful to others approaching similar inflection points.
Opinions expressed by DZone contributors are their own.