Having been in this industry for more than 25 years, I believe feature teams will be a key tool and one of the best solutions possible. Software products can be developed in different stages and using this approach ensures positive results when partnering with companies like Making Sense.
There are a number of methods that app development teams utilize to govern projects and split the workload. Some call for the team to work as a streamlined unit, while others require more independent work. Whatever the case, a team leader must decide on a strategy that is not only beneficial for the project at hand, but one that will best suit the working styles of team members as well.
The use of feature teams in development is by no means a new approach: This style has been used for decades by leaders in the software development community, and was made popular by Microsoft in the 1980s. Feature teams have sustained their popularity throughout the years for good reason – this approach to development can offer a number of advantages to product creation.
Let’s take a look at feature teams, with particular emphasis on how it stands apart from other development strategies and considering the advantages that this approach offers to the development of software products.
Defining a feature team
One of the first questions to address is what constitutes a feature team, and what makes it different from other styles of development. According to FeatureTeams.org, a feature team is defined as “a long-lived, cross-functional, cross-component team that completes many end-to-end customer features – one by one.” In this way, the team works together to create a singular function of a product, and once that feature is completed, the team moves on to the next capability.
Feature teams come as an alternative to a component team style, where teams are based on code ownership and work in singular units each in charge of different aspects of the product. For example, one component team may be in charge of testing, another may be responsible for overall analysis, and so forth. On the other hand, can serve to introduce change and better address obstacles that emerge during the development process.
Jim McCarthy, former development lead of Visual C++, noted that feature teams revolve around five main characteristics:
- Empowerment: Feature teams include a mix of developers, each with their own unique strengths and skills. With this multi-disciplinary team of individuals, those with the greatest skill set in a certain area can lead the team, and help others build their knowledge as they work on a particular feature.
- Accountability: The feature team as a whole. iIs mutually responsible for every aspect of the creation, development, testing and launch. This helps create ownership of the product and ensures that the team works together to reach a shared goal.
- Identity: As opposed to other development approaches, feature teams help each individual identify with the product as a whole, as opposed to identifying with a specific feature or skill.
- Consensus: Having a consensus in place is a main goal of feature teams. McCarthy writes, “Since the point of identification is the feature rather than the function, and since the accountability for the feature is mutual, a certain degree of openness is safe, even necessary. I have observed teams reorganize themselves, create visions, reallocating resources, changing schedules, all without sticky conflict.
- Balance: With feature teams, balance is the name of the game. Having a multi-disciplinary group work together to complete tasks helps create this balance, and ensures that a range of assignments can be accomplished with a diverse set of points of view helping to govern each step of the project.
How are feature teams beneficial?
Conway’s Law provides motivation for the utilization of feature teams.
Conway’s Law states that, “there is a very close relationship between the structure of a system and the structure of the organization which designed it. Any organization that designs a system … will inevitably produce a design whose structure is a copy of the organization’s communication structure.” In this way, if the team designing the product is a unified, streamlined group, they will produce a product that is similar to their structure. A team that is siloed and slow to develop features will create sectionalized and slow software.
But Conway’s Law isn’t the only advantage to leveraging the feature team approach. Larman and Vodde also noted that feature teams lend themselves to faster cycle times, simplified planning and improved code creation and quality. In addition, feature teams enable members to increase their knowledge by working with others with expertise in specific areas. In addition, this style provides better motivation for the team as a whole, helping to ensure that the product is not only developed more quickly, but is of a higher quality upon completion.