We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Anatomy of Agile Enterprise

Janne J. Korhonen

Scaling Agile Beyond the Team

Vote 0 Votes

The agile movement has traditionally focused on agile software development at the team level. Team-based approaches, such as Scrum, focus on delivering day-to-day customer value, but do not, per se, ensure a strategic approach to business agility at the enterprise level. On the other, the notion of business agility dates back to times before agile software development, but its relationship to agile development and underpinnings in terms of IT organization have received relatively scarce attention. Much has recently been discussed about scaling agile beyond the team. In the following, I will sum up my understanding of this discourse and attempt to relate it to the broader enterprise context.

In agile software development, a development team is a self-organizing, cross-functional "whole team" that organizes development tasks in a disciplined, overlapping manner to speed up development and reduce information losses between tasks. The team is typically fairly small. Scrum recommends the team size to be 7 ± 2. The size of any team does not scale effectively beyond about 12-15 people. This is the group size of the so-called "sympathy group", common in situations where very close coordination of behavior is required (Dunbar, 1998). However, it has been argued that hyperproductive teams, needed in Scrum proper, would always split into subgroups of 7 or less people. This comes closer to Dunbar's size of a "clique": the number of people from whom one would seek help in times of severe emotional stress.

According to Conway's Law, any organization that designs a system will inevitably produce a design whose structure reflects the organization's communication structure. The communication structure of an agile team only allows design alternatives pertaining to single systems. A larger development endeavor of a more encompassing solution cannot be effectively pursued in a single team arrangement, but calls for a "team of teams" approach such as "scrum of scrums".

The team of teams approach works with a small cluster of teams working on multiple systems within the same context. The size of this cluster of teams lies in the same order of magnitude as Dunbar's notion of "band", whose size is 30 to 50 people. For instance, each of seven scrum teams of seven would designate a person to attend a scrum of scrums meeting, where any issues, problems or challenges pertaining to coordination between the different scrum teams is addressed.

At the level of team-of-teams response, it is also increasingly important to integrate development with the broader context. In order to link development with operations, for instance, DevOps people with a multidisciplinary skill set in both development and infrastructure are needed to take down the "wall of confusion" that usually blocks effective teamwork between the two camps and thwarts agile efforts from the holistic point of view.

An even larger system may span several contexts. Both the system design and the communication structure must be modular along the context boundaries. The maximum effective size of the respective development community, henceforth the "agile unit", is around 150, which, according to Dunbar, is the mean group size of cohesive communities. Specification and management of interfaces between system modules -- and between context-specific teams (of teams) -- is of special importance and explicit communication across context boundaries is needed. A dedicated integration team should address integration between systems and specify pertinent integration tests.

The three scales of agile development efforts are depicted in Figure 1.


Figure 1. Three scales of agile endeavors.

In addition to system integration, Scott Ambler suggests three other areas that need to be addressed with large agile teams: project/program management activities, technical/architectural issues and requirements/product ownership issues.

At the team of teams scale, technical aspects of project management such as dependency management, contract management, resource tracking, and vendor management may simply be addressed by the team leads in scrum of scrums meetings, but at the scale of the agile unit it is worthwhile to consider establishing a separate project management faculty and integrating the agile process with a pertinent project management framework at the macro level. This also helps liaise the project with the overall project portfolio management at the enterprise level.

Similarly, the architecture team, at its simplest, may be comprised of the architecture owners from the team. Its main role then is to partition the system to requisite subsystems and specify the respective interfaces. In the scope of the agile unit, however, the architecture faculty in the project can be given an exalted status as a body that governs cross-cutting aspects of the solution architecture (e.g. information, security, user experience) and alignment to the overall enterprise architecture.

The product ownership team is responsible for managing the requirements dependencies and coordinating the requirements effort across the teams. Also here, Ambler suggests that the team is comprised of the product owners of each team, but in a more sizeable effort it might be a good idea to extend the team with other relevant stakeholders, including cross-representation from project management and architecture teams.

An exemplary anatomy of a sizeable agile endeavor is depicted in Figure 2.


Figure 2. Agile at scale.

Janne J. Korhonen provides insights into how information technology can be applied strategically to catalyze organizational change and responsiveness. Drawing from both theory and practice, he discusses agile enterprise and its governance.

Janne J. Korhonen

Janne J. Korhonen is an independent business and IT consultant,specializing in enterprise architecture, business process management,service-oriented architecture and pertinent governance models. He has over ten years of experience as an architect and consultant in a variety of extensive and mission-critical IT projects. With strong theoretical underpinnings, his consulting encompasses systemic co-development of business, organization and information technology.

Recently Commented On

Recent Webinars

    Monthly Archives