The reaction to the first option was: “How will I have the time to attend various meetings and keep track of the activities of all of my people if they are scattered across multiple teams?” The reaction to the second option was: “If managers no longer own components, they will leave because that is what motivates and defines them.” 

If you’re paying attention at this point, you can see that this element of the Agile transformation of the company was still the highest hurdle to jump. Engineering teams may have embraced many of the agile concepts, but the role of the people manager in the organization had not taken hold, and this is what we ran up against in proposing what was considered such a radical idea. 

Managers stuck in this component ownership mindset often say that separate component teams were more efficient because the team had expertise in their own component and can build shared to support ALL dependent teams. This argument aligns with a service-oriented architecture model. While there are merits to this concept, when we dug a little deeper, we often found more deeply rooted issues. Always at the root of these arguments was the manager’s fear of losing their relevance and their positions. 

It was clear that such a significant change could only come with executive buy-in and with a new path for engineering managers coupled with a robust plan for change management. Three years into our agile journey, the time might be right for such this shift in mindset and in practice. The question for us was how to convince leaders of this as well! Company leadership, and especially data-driven engineering leadership, is influenced by real internal data. It is sometimes the only thing that is an effective counter to the argument that “we are different/industry research is academic/ this just doesn’t apply to us.”

As those managing large-scale, complex projects for the organization, we were well aware of critical initiatives that seemed to take forever to get off the ground, much less muscle their way to completion. We also intuitively knew why – Multiple handoffs and coordination between the multiple, highly-impacted teams. For any given initiative, the priority of a couple stories for one component relative to the rest of their backlog might be very different from the priority of a couple stories for another component relative to their backlog. This might be because of a lack of alignment amongst the myriad product managers involved, or more often than not, multiple high-priority initiatives jockeying for attention in the ever-shifting landscape of customer growth and retention. Yet even when the business and PMs were aligned with priorities, there was still the effect of passing partial work around with queueing delays in between real integration activities, not to mention varying release cadences for these component teams which tended to add days to weeks in between handoffs.

In order for this to work, we needed proof that our intuition was accurate, and we needed executive approval to try some experimentation with our feature team idea. As Agile coach for the organization, Jim led the way in making that case for engineering leaders at their multi-day offsite meetings. 

To put together our case, we decided to select 2 high-profile projects and do detailed value stream maps on each. In one case, we focused on the requirements elaboration process. In the other, the focus was on the development process. That second case is what we will cover in this report. 

The figure below is a graphical depiction of the value stream of that development process.

The 12 swimlanes indicate the activities of the 12 teams involved. Pink boxes are largely spikes and information flow and yellow indicates actual development stories. Digging into every Jira ticket, we analyzed the effort expended for each activity. The result was shocking! For a project that took 6 sprints to deliver, the aggregate effort expended was equivalent to what a single team could do in a single sprint. We calculated the flow efficiency of our current process (using this initiative as an example) to be 16%. It should be emphasized that this was by no means an outlier in terms of flow efficiency. Back of the napkin estimates of other similar cross-domain initiatives were also in the 15-25% range.

This became the catalyst for change. When presented with the facts of what was going on in the trenches, senior leaders were quick to recognize that while feature teams might sacrifice some near-term efficiency, they would ultimately allow us to get features and initiatives out the door much faster. In addition, there were possible long-term benefits such as improved morale resulting from new challenges and ways of thinking; a distribution of expertise and opportunities for cross-training; and the promise of a stronger more resilient organization due to the implementation of these cross-functional teams.

A decision was made to identify a set of vertical stack teams – six in all. This was a start and represented less than 10% of our total number of Scrum teams. But we knew we had to prove the concept for it to gain acceptance. Six teams would have to do! 

Individuals were selected to be on the teams based on specific criteria (cross-domain knowledge was a plus, but just as critical was a highly collaborative mindset openness to try new things – fail fast and recover quickly). Initiatives (defined as high-profile, complex, cross-component work in our company) were selected for teams based on similar criteria (involve multiple component work, but also have a bit of slack in terms of schedule expectations to allow for knowledge transfer and ramp up time). We recognized that self-selection, both in terms of team design as well as project selection, would be a more ideal mechanism for creating teams and selecting work. Recognizing, though, the appetite for too much change, we made the conscious decision to postpone that until later when the concepts we were introducing were more accepted. There were plenty of other challenges we needed to tackle! 

The largest challenge we faced with implementing this solution was managing the change alongside leadership expectations of the change. Although at the most senior level, there was support for the feature team idea, agreement and alignment was mixed at the Director level and fear often took over at the Manager level. So, there was by no means a full willing leadership supporting the change. 

Coupled with keeping leadership focused was the challenge of giving these newly formed teams the space and time they needed to learn new components and organize themselves as a function set of scrum teams. 

Add to that mixture the need for collaboration with the teams that natively support these existing components. These components didn’t go away just because we took team members away to work with other team members collaboratively. We had to also be mindful of the incremental load knowledge transfer and mentorship would be on these component team members, especially in light of other high-priority projects that depended on them.

Once we started forming the teams, defining roles and responsibilities within a feature team it became a great point of discussion. Having a single team be responsible for an end-to-end solution should have eliminated the need for release train engineers or traditional program managers, but still necessary was that single voice to communicate expectations and changes to stakeholders. Could Product Owners or ScrumMasters fill that void? This model also put a greater reliance on full-stack solution architects, rather than the traditional component architects we normally worked with. Did we have any of those? 

As we peeled back the onion, we discovered many challenges that were more practical. Could teams create an environment that allowed development, integration and testing across all of the components and foster this collaborative mindset? Would there be difficulties in sharing code bases that were previously accessed only by a small, siloed team? Who would help teams write stories in holistic vertical slices rather than the component-specific methods they were used to that they were used to? Our Product Management organization was also siloed to manage parts of the puzzle rather than look at the whole. 

Most importantly, how would we know we were successful in our experiment? Did we need to develop new metrics for success?

Tackling the leadership change management challenge head on, we established a support structure consisting of senior engineering leaders from all development domains. That team met weekly, and their objective was to address any overall roadblocks that came up related to the newly formed feature teams. We tracked issues and resolutions on a fully transparent Confluence page; assigned owners at the meetings; and discussed solutions to each issue. These meetings also allowed us to keep up with the tolerance level for the change and provide feedback on where teams may need additional time or how configuring the teams differently might ease some of the roadblocks. 

All engineering leaders were required to provide subject matter experts to assist the feature teams new to the model and learning new skillsets. Teams were encouraged to reach out to their designated SMEs for support and to be collaborative when it came to finding the right timing for these discussions. We knew the SMEs would see a higher workload as a result of this change, and the goal was not to frustrate existing teams delivering against other company goals. 

To address new roles and responsibilities, the ScrumMaster and Program Manager roles were combined into a single role which we referred to as “Team Captain.” Although this had the sound of a directive role, it was a conscious decision to balance traditional Agile best practices with the fears that without a traditional Program Manager the team may lose focus. This Team Captain had their feet in both roles – they worked with the team on best practices, organization, and guidance and managed up to leadership by clearly communicating the achievements, issues, and risks to the team and the overall initiative delivery. 

No managerial changes were made in terms of reporting structure; hence, we followed the model of each team member reporting to their previous (domain) manager. The domain managers were not engaged in the feature team, but provided more employee mentoring and development to the feature team member. In addition, rules for engagement were worked out for all members of the team including architects and SMEs. Suggestions for success were worked out and presented to team members, team captains, product owners, component managers, people managers, architects, and SMEs with the goal of creating an environment of transparency and collaboration. 

As mentioned before, other parts of the organization - specifically Product Management – were also hired and trained with this very siloed component mindset. We had to reach across to that organization to provide someone who could lead these new feature teams and write those vertical requirements along with the team. Or, in cases where we couldn’t take a single person away from their role to provide epics for the team, we had to train the PMs to write in a way that was different from their usual models. 

Overall, the feature team experiment was a strong success. The metrics collected verified the key results we were seeking. The main objective of course was to improve flow efficiency of cross-domain initiatives – i.e. get stuff out the door faster. Figure 1 below shows the results for the 6 initiatives that were delivered by feature teams. The average flow efficiency was 80% which compares extremely favorably against the average of 15%-25% that we saw from component-team-based initiatives.

Since we asked each team to estimate their flow efficiency every sprint, we were able to see how it changed over time. At the beginning of each initiative, it tended to be lower than at the end, due mainly to the need for knowledge transfer and time to learn new components, code bases, and domains. The steady state level averaged to 89% (measured toward the end of each initiative) and the average time that it took to ramp to that level was 1.33 sprints, or about 2-3 weeks. We expected that both the ramp up time and the initial flow efficiency for new initiatives would increase as teams took on new work, assuming, of course, that there would be less learning needs as teams broadened their subject-matter expertise. 

Below demonstrates the metrics that we collected regarding team satisfaction and subject matter expertise. 

As a comparison against how team members felt when they were on component-based teams, average team satisfaction increased by 30% over a period of 6 months. Note that there were a couple outliers, and it was valuable to identify the reason that they gave for those cases. Our goal ultimately was to improve the concept and any information was good information, even if it didn’t fit with the model we wanted to see. 

In one notable case, the team’s satisfaction level dropped 50%. The reason that they gave was that they essentially felt that they were “constantly learning new things and not given time to apply what they learned.” This particular team had been taken off of their core domain and given to a completely different product area a few months before the feature team experiment began. Then, as a feature team, they were given yet a third unrelated product area to work on rather than one of the two that they were already familiar with. We believed that over time, this effect would have subsided, but ultimately, the management team decided to pull them back to their original product area, so there is no way to tell. 

The other team metric that we measured was “increase in component Subject Matter Expertise.” Since teams filled this out at various times during the projects, we normalized it by annualizing the metric. On the average, teams felt that they increased their knowledge of and ability to understand the code base of previously unfamiliar components by 38% annualized. Interestingly, the team that registered the greatest increase in subject matter expertise was the one that had the lower satisfaction rate while the teams that had the highest satisfaction rates registered the lowest increase in subject matter expertise. The other three data points, however, are not correlated to that trend and with only six data points, we would caution too much of a conclusion from this observation. For us, it opened up more interest in exploring and iterating on this idea.

With any aspirational vision comes the realities of the environment you are working with. As alluded to above, a major change in leadership occurred about 6 months after the creation of the feature teams. Senior management who had been supportive of the feature team’s work left the company amid major layoffs and restructuring. New leadership did not embrace the concepts of Agile and did not particularly understand the benefits and values that the feature teams were bringing. Their focus was on the majority of the engineering teams who were still clunkily “delivering something” and employee satisfaction wasn’t their primary focus. Our greatest learning from this was the original ingredient needed for this recipe to work – leadership support for feature teams and the mindset shift needed there. As a result, executive support was lost, and some of the teams were disbanded and pulled back into their original component-based ways of working. There was extreme disappointment (as well as resulting attrition) among many of the members of these teams as they had tasted a way of working that involved greater autonomy and a large solution-level vision.

In the end, we came way with key learnings and guidance which we feel would help any organization thinking of this sort of team structure:

One of the key intangible successes we both got from this experiment was to see feature teams work in good and in not so good times. We were able to discuss and measure individual and team successes with this model. Members of those teams that experienced the transition (including us) have moved on to other companies as well. Our hope is that the spark we set in this one controlled area may find its way to burn brightly in other organizations.

This paper would not have been possible without the actual teams whose stories we are telling. They are the heroes who went through the triumphs and pains to make this grand experiment a success. They had fun and inspiring names like Lighthouse and Polygots, and Honeycomb. But for us, they will always be inspiring friends who taught us that “going together” is best. So, thank you to the teams who went along with this crazy idea. Also, our success would not have been possible without two key champions – the Senior Director of the PMO and the VP of Engineering at the company we worked for. They gave us the “aircover” to try, fail, iterate, and succeed. Lastly, many thanks to Niels Harre for his evaluation and feedback on this paper and to XP for allowing us to tell our story!