Conway’s Law: Avoid Component Teams¶

Old approach in team formation is to divide the teams by component of the systems where each team implements and maintains its own component(s). Long ago, Mel Conway has observed the effect of such team formation and has stated as follows:

“…Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization”[14].

The realized disadvantages are code smells such as, code duplication, unnecessarily increased system/code complexity and above all the coordination complexity in the large groups. In organizational perspective the most notable risks of such a team formation are following–

• Resource dependency
• Lack of cross-functionality
• Difficulty of scaling up or down the team
• Single point of specialization success or failure
• Sequential life cycle development
• Lack of knowledge sharing which incurs a learning debt
• Lower productivity and increased handoff and delay due to the physical dispersion and so on.

Hence, in LFDS, we should avoid such a team formation by promoting feature teams that focuses on end-to-end customer features.Following diagram Fig. 1 illustrates a strategy that reduces the risk of forming component team in large-scale software development by engaging all the feature teams in end-to-end feature development.

Fig.1. Task distribution in LFDS

The detected primary organizational benefit of this approach is the shifting of the coordination challenge from upfront requirement analysis, planning and inter-team management towards the coordination at the shared source code level[7]. Moreover, this approach complements with all the key characteristics of feature teams mentioned earlier while promoting and necessitating the clean code through consistent code refactoring [1], continuous integration [2] and code coverage [3] through unit and integration testing.

Acknowledge the contextual differences¶

So far, we discuss the scalability aspects of the LFDS team formation. However, the team members of a feature team are distributed across the globe in the LFDS model, which initially reduces the teams’ efficiency and velocity[6] due to the geographical dispersion, differences in culture, time-zone, and standards. An interesting survey is done by G. Hofstede, who surveyed IBM employees in over 50 countries to identify major cultural differences [15]. Only way to alleviate this distance and increase team velocity is to acknowledge and take these differences into account during initial product planning phase. Personal interaction and collaboration is an excellent way of getting familiarizes with the cultural differences of difference development sites. We notice in different literature [8, 9] that at the initial phase, the team members start working in a local site, which in turns, make them familiarize with each other’s contextual and personal similarities and differences. After working certain period together to achieve efficient communication framework by inter-personal interactions, higher productivity through team work, shared ownership and more importantly, building the trust, team members are distributed in multiple sites and scaled up, as necessary. As a result of this face-to-face setting, they can efficiently communicate and coordinate afterwards [24] and the organization can achieve feature teams with high performance and hyper-productivity, as observed in the several case-studies [8, 9].

Promoting Software Development Sub-culture¶

Promoting and synchronizing the teams with a shared vision requires the establishment of software development sub-culture such as, Definition-of-done [6]. Professor E. Carmel has addressed that in software professionals world-wide belong to software development sub-culture which is stronger than their national culture [4, 5]. Furthermore, the sustainability and improving of such standards can be effectively keep it up by establishing the community of similar-professionals (e.g. architects, database developer, UI specialists) from different teams periodically and promoting their collaboration. This way, whole organization can reach to a same standard, complementing to the process that works.

Strategy 2: Product Owners in LFDS¶

In Scrum, the Product-owners get involved in lots of inward-facing tasks- sprint planning, daily scrum [6] and outward-facing tasks- talking to users to capture their needs, answering questions from the team, communicate with the other stakeholders, developing product pricing and road-map and so on.

In a large-scale software development with multiple teams, product owner role is too difficult for one person to manage. So, we must find a way to scale it in the LFDS model. Ideally, one product owner should be responsible for one team, but no more than two teams. This is the most that one product owner can work with. Fig. 2 illustrates the product owner’s hierarchy in a large-scale product development with multiple teams where the product owners collaborate and coordinate among each other as a team.

Fig. 2.Scaling Product Owners [15]

Additionally, the layers depicted above can be added or removed depending on the scale of the product. As a consequence of this strategy, individual product owner can concentrate and resolve issue related to one or at most two feature teams, which enhance the inter-teams coordination through efficient communication and impediments resolution.

Strategy 3: Manage Prioritized Product Backlog¶

There should be one to one mapping between a product and product backlog. Main goal is to keep all the backlog items prioritized on the same scale. If the teams in the LFDSwork on items from the multiple product backlogs, then the backlogs items must be prioritize against one another. Fig. 3 depicts a Content Management software product backlog with two different teams – Content Management Team and Content Delivery Team.

Fig.3. A prioritized product backlog with different views

Both teams share a common product backlog, but have a different view on the product backlog. They work on it based on the priority. It is imperative to note that few items are viewed by both team which are items recognized as dependency items that both teams are responsible of or the items that either of the team can work on [15]. Notable results of such a prioritized product backlog are following.

─ Conceptual integration of different components in a single integrated product.

─ Dependency identification, earlier in the development phase.

─ Efficient inter-team sprint planning[6] and release planning of the product.

Strategy 4: Dependency Management: Proactively Manage Dependency¶

Scrum promotes self-organization in a proactive manner [6]. Hence, at the end of the day, resource utilization can reach to the maximum level in this framework in the GSD context [8]. But, in the multi-site LFDS, inter-team dependency management requires careful consideration in the sprint planning. Typically there are few strategies that Scrum teams can accommodate in their process.

Strategy 5: Communication that Connects¶

Communication is one of the key impediments of LFDS model as stated in earlier. In order to compensate communication richness and coordinate effective communication framework, LFDS promotes all kind of formal and informal means of communication that works. Though in the Scrum framework, there are specific communication protocols in place (e.g. Sprint Planning, Retrospective, Daily Stand-ups, Scrum-of-scrums[6]) for intra- and inter-team communication, in order to do it effectively in GSD, several best practices should be adapted, such as – preference of phone communication, video conferencing over email and instant messaging. Furthermore, “Seeing is believing”; hence, as mentioned in [8-10], in order to alleviate the distance, team rooms with constant video feed from all the sites involved in one feature team can be established using cheap, simple , ubiquitous technologies (e.g. Skype webcam and so on). As there is no hard-and-fast rule, the main idea is to promote communication that connects.

Last but not the least, infrastructure is another key inevitable issue in GSD context; hence, it is not addressed as a separate strategy. However, it is noteworthy to mention that, success of  LFDS depends, to a large extent, on the efficient infrastructure setup facilitating shared code access, continuous integration and efficient communication and tracking tools.

In the next post , we discuss more on  the coordination strategies that are beyond the scope of traditional Scrum process and are borrowed from other sources. One thing is common in them that they fits very well in LFDS + GSD context to reduce noise and alleviate efficiency of this process model. Thanks for you visiting the blog.

References

[1] http://en.wikipedia.org/wiki/Code_refactoring

[2] http://martinfowler.com/articles/continuousIntegration.html

[3] http://en.wikipedia.org/wiki/Code_coverage

[4] E. Carmel, Global software teams: collaborating across borders and time zones: Prentice Hall PTR, 1999.

[5] E. Carmel and R. Agarwal, “Tactical approaches for alleviating distance in global software development,” IEEE Software, vol. 1(2), pp. 22-29, 2001.

[6] K. Schwaber, Agile Project Management With Scrum: Microsoft Press, 2004.

[7] C. Larman and B. Vodde, Scaling Lean \& Agile Development: Thinking and Organizational Tools for Large-Scale Scrum: Addison-Wesley Professional, 2008.

[8] J. Sutherland, et al., “Fully Distributed Scrum: Linear Scalability of Production between San Francisco and India,” presented at the Proceedings of the 2009 Agile Conference, 2009.

[9] J. Sutherland, et al., “Fully Distributed Scrum: The Secret Sauce for Hyperproductive Offshored Development Teams,” presented at the Proceedings of the Agile 2008, 2008.

[10] J. Sutherland, et al., “Distributed Scrum: Agile Project Management with Outsourced Development Teams,” presented at the Proceedings of the 40th Annual Hawaii International Conference on System Sciences, 2007.

[11] P. A. Beavers, “Managing a Large “Agile” Software Engineering Organization,” presented at the Proceedings of the AGILE 2007, 2007.

[12] M. Marchesi, et al., “Distributed Scrum in Research Project Management,” Agile Processes in Software Engineering and Extreme Programming, vol. 4536, pp. 240-244, 2007.

[13] J. McCarthy, Dynamics of Software Development: Pearson Education, 2002.

[14] M. Conway, “How do committees invent.,” Datamation, vol. 14(4), pp. 28-31, 1968.

[15] M. Cohn, Succeeding with Agile: Software Development Using Scrum: Addison-Wesley Professional, 2009.