The idea of a feature team that incrementally delivers vertical slices of application functionality is central to many “agile” software development organizations. A feature team possesses all the skills and resources necessary to deliver a customer-centric software feature end to end. How feasible is this model in a large corporate IT environment?
Conventional wisdom in the “agile” community holds that it is practical to organize feature teams for any software development environment, including the most complicated and large-scale ones. The idea is described well in the book, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, by Craig Larman and Bas Vodde.
It isn’t necessary for each individual team member to understand all the technologies and all the disciplines involved in building and delivering a useful software product, provided the team as a whole has that knowledge.
Generalists and full-stack developers
Another popular concept is the idea of the generalizing specialist, or T-shaped professional. In the context of software work, this means an individual expands his/her skills into multiple delivery disciplines, such as programming, testing, analysis, and management.
A closely-related concept is the full-stack developer. It concerns the expansion of technical skills specifically, to cover all the technologies necessary to deliver a solution on a given technology “stack.”
Challenges with the generalizing specialist idea
The idea that a developer can perform all the basic functions of software delivery is compelling. Recall the canonical Rational Unified Process (RUP) diagram, shown here: http://www.agilemodeling.com/essays/agileModelingRUP.htm. Notice how the workload shifts among various disciplines as the work progresses. With a team of specialists, some people are overloaded while others are idle at any given time. While some tasks may require narrow and deep skills in a particular area, a generalizing specialist or T-shaped professional can contribute to several of these disciplines well enough to keep the work moving along smoothly. The problem, however, is that very few individuals want to spend their time working in any discipline other than the one or two that interest them.
A second challenge, and one that is increasing, is that the range of disciplines necessary to deliver a software solution is growing. Disciplines such as user experience design and data analytics, among others, are becoming necessary for many types of solutions. It’s a good thing to try and become a T-shaped professional, but there may be a practical limit to the width of the T. As we broaden our skill set, we risk losing depth in any single discipline.
Challenges with the full-stack developer idea
In reading the article about full-stack developers linked in the previous section, you may notice that the range of technologies included in the author’s “full stack” is pretty limited. It’s certainly feasible to develop technical skills in all those areas. Within a given domain, it may be true that the range of necessary technical skills is small enough to enable individuals to master them all. Yet, even within relatively limited domains the range of technologies and skills is growing rapidly, as noted by Peter Yared, Andy Shora, and many others.
The range of technologies involved in a large corporate IT environment presents a considerably greater learning challenge. The “full stack” can include iOS, Android, JavaScript, Java, .NET, Ruby, Python, Unix, Linux, Windows, various scripting languages, zOS, Rexx, COBOL, PL/I, S390 Assembly language, JCL, VSAM, DB2, CICS, COTS packages of various kinds, numerous different frameworks, data analysis tools, data transformation tools, multiple communication protocols, and more. Technical disciplines involved in software delivery can include DevOps, security, network engineering, technical infrastructure and architecture, and others. Is it reasonable to expect any individual to develop strong technical skills in all those areas? Is it realistic to expect any individual even to be interested in all those areas?
Things fall apart (apologies to Chinua Achebe)
In principle, there’s nothing wrong with the idea of a feature team. In principle, there’s nothing wrong with the idea of a T-shaped professional. When things get highly complicated, there are challenges in putting these ideas into practice.
As the range of disciplines and technologies grows, the list of skills a feature team requires also grows. As it is impractical for individual team members to pick up 20, 30, or more discrete technical skills with any degree of proficiency, the only way to increase the capabilities of the team is to add new members.
Once a team reaches a size of about 12 people, it becomes very difficult to maintain a collaborative working style (in my experience). Around the size of 15 people, the team will self-divide into sub-teams, even if that is not the intention. Typically, the sub-teams form around common interests. Effectively, the result is a group of component teams, regardless of whether management officially considers them a single “team.”
The unofficial component teams have dependencies on one another. This introduces the same logistical overhead in software delivery as we had before the era of feature teams and collaborative work. The situation may be worse than in the Old Days, if management is unaware the component teams exist because they have officially created a “feature team.” In that case, the organization will not have resources and processes in place to handle the cross-team dependencies.
Legacy environments
Considering the advantages of having feature teams deliver vertical slices of functionality, we certainly don’t want to discard the idea entirely. How can we retain as much of the value of this model as is practical, while dealing with the realities of heterogeneous, complicated, large-scale technical environments?
Some large companies don’t have a legacy technical environment that dates back to the mid-20th century. They are in a relatively good position with regard to this problem. However, many larger companies have been in business for several decades and have used computing resources all that time. Through the years they have added new technologies to the mix. For the most part, they have not retired the older technologies. Instead, they have added on.
Separating the top and bottom of a vertical slice
Although service-oriented architecture (SOA) has never caught on formally to the extent proponents might have wished, in reality most large organizations have been attempting to isolate components of their technical infrastructure for quite a long time. Some home-grown solutions date back as far as the 1970s. In the late 1980s and through the 1990s, a predecessor of SOA was widely applied – enterprise application integration (EAI). Other types of solutions were developed, as well, such as Perot Systems’ LiquiFi architecture, based on middleware messaging. All these were attempts to tie things together while keeping them logically separated.
Thus, in most large legacy organizations there is at least a starting point for creating a layer of separation; in many cases there is much more than a starting point. By making this layer explicit and bringing a degree of standardization to it, we can create a more-or-less “clean” separation between two broad technology stacks.
On the one hand, there are the front-end and middleware components, often including support for mobile devices and web browsers and comprising tactical business applications that may use lightweight databases. On the other hand, there are the back-end components, typically involving a combination of mainframe systems and third-party packages that support strategic IT assets and long-lived, enterprise-wide data stores and algorithms. A single vertical slice of functionality cuts through all those layers.
Within the scope of either of these two broad “stacks” the concepts of feature teams, T-shaped professionals, and vertical slices of functionality may be practical. The compromise is that any given team would be able to deliver half of a vertical slice of functionality. That is not as desirable as a single team that can deliver a complete vertical slice, but it is better than a group of component teams bouncing work requests off of one another.
Another advantage of dividing the feature teams into two is that the line of demarcation corresponds to a cultural divide in large IT organizations. People who work on tactical business applications using leading-edge technologies and lightweight delivery methods tend to be motivated by different attractors than people who work on stable, long-term, strategic technical infrastructure and legacy applications. Each of the two feature teams involved in delivering a vertical slice of functionality can be organized and managed in ways that are suited to their inherent preferences. I allude to this cultural difference in another blog post: https://davenicolette.wordpress.com/2014/09/23/a-modest-proposal-for-restructuring-enterprise-it/.