Pairing & Co-location
How to sustain modern software development practices in a team? How to upskill specialists into full-stack developers? How to eliminate single points of failure?
"Pair programming is a dialog between two people simultaneously programming (and analyzing and designing and testing)
and trying to program better" - Kent Beck.
Kent Beck published extreme programming (XP) methodology in 1999 (1). I highly recommend the book for its mindset and a modern approach to software development. One of the most controversial XP practices is pairing.
Pair programmers keep each other on task, brainstorm, clarify ideas, help each other to get unstuck, rotate pairs, use test-driven development (TDD). Anybody on the team can pair. For example, a product manager and a designer often pair on various tasks. However, XP developers pair for at least five hours a day. They may rotate pairs every morning, preferably on a new story. Some teams rotate every couple hours; others rotate when they finish a story. XP teams have an even number of developers, frequently two to three pairs. Teams may be "odd" for a day due to absences. Developers may pair across "odd" teams to help out. Long-term team rotations help bring a fresh perspective to both teams, especially when a developer returns to his/her original outfit.
What are the benefits of pairing? Instead of deepening expertise in specific code components or a language, every programmer becomes a full stack developer. The shared business context and technical skillset make teams more resilient to staffing fluctuations and inform a holistic understanding of the software product. Pair programmers improve code quality by holding each other accountable for the team's practices, such as TDD, "built-in" code reviews, continuous tech debt removal, and CI/CD. Pairing and rotation is a great way to learn for new team members and to transfer knowledge during product handoffs (from H2 to H1). Conversely, adding a specialist to an XP team upskills the team and the specialist after several weeks of pairing and rotations. For example, when a need arises, adding a machine learning specialist or a cloud migration architect for a few weeks to an XP team would be so motivating and effective!
I will provide more details on enablement and team rotations separately.
Engineering managers in traditional IT organizations tend to scale projects to huge headcounts prematurely and in multiple geographic locations. Such an approach may sometimes work for Horizon 1 in mature enterprises, but not for H2.
PMO will drive huge multi-location teams to deliver large volumes of output on-time and on-budget (a "feature factory" pattern) while often neglecting to solve a customer problem or even measure outcomes.
"The most efficient and effective method of conveying information to and within a development team is
face-to-face conversation", -Principles behind the Agile Manifesto
However, a much better practice, especially in H3 and H2, is the co-location of more experienced (and better compensated) people in a small team. The main benefit of co-location is a faster communication loop. A small co-located cross-functional team removes blockers and makes decisions much faster. Size constraint forces a team to prioritize work based on intended product outcomes. Although remote pairing works surprisingly well, pairing is more effective when a team sits together.
I will provide more details about "balanced" teams and roles separately.
Pairing and team co-location are two of the core practices of XP teams working on product discovery (H3 and H2). Placing multiple co-located teams in an innovation lab allows for cross-team rotations and dynamic resource allocation by portfolio boards based on lean product/portfolio practices and data, such as sPDLC appropriate product KPIs, holistic portfolio KPIs, balanced portfolio horizons/pipelines, and outcome-based roadmaps.