5-Minute DevOps: The Feature Team Fallacy
Recently, I’ve had conversations about team structure, specifically whether development teams should be organized around features or product capabilities. During those conversations, it became clear that Large Scale Scrum (LeSS) agile coaches are adamant that teams should be organized around features. This article from LeSS hits all of their talking points.
Now, I’m no agile coach, and it could be that I’m just not trained enough. Still, I have a few decades of experience working as a developer on product teams and feature teams and on everything from customer-facing applications to developer platforms, so I feel qualified to give feedback to LeSS on their article and explain why they are wrong.
Defining Terms
The article defines a feature team this way:
To me, this sounds like a classic project team, except they don’t disband after the project. I was unsurprised to find a comparison with project teams later in the article. We’ll cover that later.
The article doesn’t clearly define what “component team” means. However, follow-up conversations with LeSS Agile Coaches confirmed that we both define a component team as responsible for a product sub-domain (a component of behavior), not a layer of the tech stack (a DBA team). Platform teams and other service-providing teams are beyond the scope of this discussion. We are only discussing teams building products. I typically use the term “product team” or “product domain team” to describe this structure, but for clarity, in this article, we will stick to “component team.”
LeSS Claims
The article makes several claims without supporting evidence or explanations of why these claims have a causal relationship to team organization. However, I’ve worked in all of the structures described and have spent a fair number of years in the details of delivering software products better and helping others do that, so let's pull back the curtains on these claims.
Component vs. Feature teams
Optimized for lines of code vs. maximum customer value
This has nothing to do with team structure. Every team structure can be incentivized to meet output vs. outcome goals. My experience working on feature teams and observing them in other organizations is that management uses them to maximize utilization by flexing people to meet output demands. This is easier to achieve with feature teams but can still happen on component teams.
With component teams, flexing to meet output demands (there are valid business reasons to do this) requires a defined inner sourcing process. However, if this is required frequently, there is a problem with team/component alignment or product management.
Focus on individual productivity vs. system productivity
Again, this has nothing to do with team structure and everything to do with management incentives. I’ve worked on feature teams with assigned tasks and individual output goals. I’ve worked on feature teams where we helped each other. Every component team I’ve worked on focused on the team’s goals and shared ownership of the code within the team. However, I’ve also seen poorly led component teams where management measured individual output.
Responsible for only part of a customer-centric feature vs. complete customer-centric feature
We finally get to something related to the topic.
It’s true, a team developing a tax calculation service to support point-of-sale and e-commerce systems for a retailer focuses on only some of the customer journey of adding things to a cart, paying for them, and having them shipped. They are focusing on ensuring that every other team that needs taxes calculated correctly has that ability. They are also focusing on keeping the system easy to change so they can quickly adapt to new tax rules, the addition of new markets in other tax zones, etc. Business domain specialization and code ownership mean they can deliver higher quality faster. This assumes they don’t have dysfunctional management. However, as we covered in the previous sections, that’s a vulnerability for any team structure.
A feature team would need to re-orient on the tax system, and every other component they touch to learn what other changes other teams have made since they last looked at them when a feature is added to the checkout process. That doesn’t lend itself to performant delivery. It certainly doesn’t lend itself to supporting the needs of the business.
Traditional way of organizing teams — follows Conway’s law vs. ‘modern’ way of organizing teams — avoids Conway’s law
This one confuses me because I never saw a component team until 2015 when we rearchitected the teams around business sub-domains to enable continuous delivery. Every person I know who is a thought leader in the space around CD will talk about how important it is to have loosely coupled, highly cohesive teams to drive a decoupled architecture and enable faster feedback with CD. It’s SO important that the “Inverse Conway Maneuver” is the description for re-aligning teams to achieve that. This isn’t theoretical. I’ve helped plan and implement that to decouple a 25 million line entangled legacy system with over 400 developers. The results were astoundingly good, with lead times dropping from months to hours until the management team degraded and incentives changed.
You can’t “avoid Conway’s Law.” You have three choices.
- You can ignore it. This will incentivize spaghetti code and harm your ability to react to changes in production.
- You try to work around the spaghetti code problem by creating architectural review boards or, in the case of one feature team advocate I spoke to, also creating component teams. He had feature teams responsible for features and component teams for keeping tech debt low, code reviewing the feature teams, and tier 2 support—the worst of both.
- As I and others have done, you can leverage it to improve delivery and replace process overhead with engineering.
As Martin Fowler says, “Accepting Conway’s Law is superior to ignoring it…”
leads to ‘invented’ work and a forever-growing organization vs. customer focus, visibility, and smaller organizations
OK, so back to “our management sucks.” This has very little to do with team structure. Kingdom-building, not component teams, causes forever-growing organizations.
Any development team needs to be limited in size to be effective. If they grow too large, then collaboration becomes increasingly difficult. A component team should not be assigned so much of a system that it exceeds their cognitive capacity. There is a natural limit to how much a team can absorb.
As to “invented work,” that is a product of poor incentives and poor product management. No matter the team structure, invented work will happen without good product discipline. I will admit that it’s less likely that a feature team will invent a new feature, but only because they lack ownership. Their focus is on completing the tasks assigned by a product manager. They don’t make product decisions. Their job is implementation. Component teams own their capability from birth to death. If they lack product discipline, they may implement a “good idea” that no one needs.
Dependencies between teams leads to additional planning vs. minimizes dependencies between teams to increase flexibility
I must point out that every person I’ve spoken to who argues strongly for feature teams has either no development experience or very limited experience (2–4 years) before they moved to agile coaching over a decade ago. This is a common problem in the agile coaching industry: lack of technical proficiency.
The component team problem can be real. If the underlying architecture is tightly coupled, the teams are tightly coupled. Realigning the teams to decouple the architecture decouples the teams. I’ve helped do this and worked in the resulting teams as a developer. I know it works, and I know why it works. Coordinating through APIs with teams with well-defined product sub-domains results in independently deployable components and more stable systems. It enables daily delivery as well. When things are broken, you want a team that’s expert in fixing the code and can ship independently of anyone else.
Let’s discuss this fantasy that having feature teams “minimizes dependencies.” Everyone who can change a component is effectively on the same team. This means that every member of every feature team that is changing the same product is actually on one large, poorly communicating team.
Our goal should be small, highly cohesive, loosely coupled, cross-functional teams. A feature team may be cross-functional, but it fails at everything else.
- It is loosely cohesive because other developers outside the team's control are also making changes to the code with no communication.
- It is tightly coupled to other teams because their code changes directly impact each other.
You can fight this by creating a change management team responsible for coordinating code merges, but all that will do is create more jobs and add process overhead. It doesn’t fix the underlying problem. I’ve had that job, too. I was given the goal of eliminating the need for that job. I did. I helped move us to component teams.
focus on single specialization vs. focus on multiple specializations
So, a component team is an expert at their sub-domain, and a feature team needs to learn all the sub-domains that their feature touches. I’m struggling to understand why domain expertise is a bad thing. I’ve had a few LeSS Agile Coaches tell me that this optimizes for learning because optimizing for learning is a goal. The article states it clearly.
…when requirements do not map to the skills of the teams, learning is ‘forced,’ breaking the overspecialization constraint.
Feature teams balance specialization and flexibility.
So, I need to re-learn code that another team changed and why they changed it. I need to keep a mental model of every system component my feature touches and learn about new components other teams have built because of “learning?” They misunderstood learning as the goal.
We should learn how the product is or is not helping the users. We should learn what the teams that consume our sub-domains need. We should learn better way to fulfill those needs with less waste and less effort. We should learn how our component behaves or misbehaves to make it more resilient and reliable. We shouldn’t spend cycles learning what other teams have done to “our” code.
This “advantage” that feature teams have harms timelines, cost, and quality. That’s one way to impact the Iron Triangle.
individual/team code ownership vs. shared product code ownership
No individual should “own” any part of the system. Team ownership is very important to quality. A proper component team will be given problems to solve. They will own how the problems are solved and the consequences of their decisions because they are responsible for supporting it when it fails. They can enforce quality standards within the team through code review and focused training.
Feature teams don’t have “shared product ownership.” That’s another fantasy of LeSS Agile Coaches. They don’t have ownership because they cannot enforce code quality working agreements with other feature teams. If they have operational responsibility, they feel the pain of other teams’ bad decisions. However, they are typically only responsible for development and have no outcome ownership. None of that is good for quality or, frankly, morale.
clear individual responsibilities vs. shared team responsibilities
I see. We are back to “making up fake comparisons.” Both of these exist in every development team structure. It’s an outcome of management. Every team should be focused on delivering as a team.
results in ‘waterfall’ development vs. supports iterative development
There’s no causal relationship here. A component team can deliver independently of everyone else. If they are working correctly, they are using continuous delivery. You cannot be more agile than CD.
This does remind me of another argument from these coaches. I’ve had LeSS Agile Coaches DevSplain to me that component teams cause duplication because it’s easier for them to build something they need that someone else should be building than to wait on the team that should be building it.
False. If the teams have proper domain alignment and are loosely coupled, then they don’t wait. They deliver their part of the feature after collaborating with their upstream and downstream teams on API changes. Any duplication is due to poor domain alignment or poor management.
Duplication with feature teams is far more likely. If two features require the same behavior, what is the control mechanism to prevent those teams from both building that behavior? Playing whack-a-mole with that problem is something I’m quite familiar with. I cannot say how much time I’ve spent refactoring code to condense several implementations of the same behavior over the years. But then, I’m just a developer, not a LeSS Agile Coach. I’m probably wrong. However, they might know why this claim is wrong if they had SOME background in modern software engineering.
exploits existing expertise; lower level of learning new skills vs. exploits flexibility; continuous and broad learning
Sorry, but learning how something new works that some other team built before I can start my task is not a value add to me or to the business. Yes, we want people to have a learning mindset. No, we don’t want to do that by causing frustration for them, their management, and the business goals. Again, they need help understanding what we should be learning about. We should be learning how to solve the problems better.
works with sloppy engineering practices — effects are localized vs. requires skilled engineering practices — effects are broadly visible
“Works with sloppy engineering practices?” The author must provide evidence for this extraordinary claim and how aligning teams to features fixes it. Until then, it’s simply bullshit.
On the contrary, we executed a strategy of improving engineering excellence by aligning teams to product domains and helping them solve the problem of “Why can’t we deliver today’s work to the end user today?” It was very effective. Instead of futzing around with an agile scaling framework, just solve that problem.
contrary to belief, often leads to low-quality code in component vs. provides a motivation to make code easy to maintain and test
Oh? How? When my team owns our code, we keep making it better. When we are constantly in the same code, we make that code less complicated and easier to change over time. Our tests are constantly being improved. We look for ways to make it more resilient and performant.
When other teams change things without my team’s permission, we must constantly fight decisions in the code other teams make outside our control. It’s demoralizing and provides zero motivation for improvement. It does create a blame culture, though. That’s why we don’t do that.
seemingly easy to implement vs. seemingly difficult to implement
Really? Then, you have no idea what you’re doing. This was probably added to say, “If it’s hard, it’s worth doing,” and make the reader feel challenged. However, putting a group of people together and assigning them a feature to build is about as easy as it gets. It’s why development has been done that way for so long. Spending the time to design teams and architecture? That takes work. I’ve done it.
Feature Team vs. Project Team
I know this post is too long, but I promised I’d cover this.
This shows the same level of understanding as the previous table.
- The first item is true.
- The rest have no causal relationship and may be true or false in either.
A feature team is a long-lived project team working on projects. Been there. It sucks.
LeSS Effective
I normally criticize SAFe because I’ve experienced it directly. It’s hard to find something worse. LeSS’s information is shockingly bad. Not only because it was biased, misrepresentative, and objectively false but because it offered no reasons behind the claims. LeSS isn’t the only place where you can see this recommendation to use feature teams. I’ve seen other examples from SAFe and some random Scrum training sites. This page offered so many false claims that it needed a response, though.
Advocating for feature teams is a good indication of having no experience delivering at scale. You may get it to work if you can deliver your product with only two or three teams. It falls apart quickly after that. “What do you think of feature teams?” is also a good job interview question. Try it in your next job interview. If you’re the interviewee and they talk about their feature teams, politely leave. You’ll thank me later.
