In a conversation with a friend we identified an anti-pattern that can often happen to “feature teams”.
Feature teams are supposed to be cross-functional groups that focus the software development process in valuable-chunks of work, which normally cross the whole system (vertical slices of the system).
There’s a way in which you can meet that definition and still not be a feature team. Here’s the example.
In a certain company, that shall go unnamed, one feature team was developing their features all through the project. At the same time a set of UI designers were developing their version of what would be a new user interface for the product. Come the last Sprint of the project and the UI people gave the complete UI specification to the feature team. Lots of changes were needed.
At that point the feature team was struggling to develop all of the new screens defined by the UI people as well as changing the ones that were already implemented.
On the face of it, the feature team was working like a feature team. It had UI people, architects, testers and engineers that worked together daily to develop and deliver complete features at the end of every sprint. It was the proverbial cross-functional team. However there was a problem. That’s when it hit me the feature team definition has been wrong all along! A feature team is not defined by it’s structure it is defined by it’s output!
This particular team had no way to create a complete output of the product, they were powerless to influence what the UI team would work on and could only wait and cross their fingers that the UI team would not ask them to completely re-implement the product in the last sprint.
Note that the feature team had UI people present in the planning and development of each feature they developed, but there was another UI team working in a different organization that was shielded from the development work.
Also, the feature team could deliver so called features in every sprint, so by the “old” definition they were indeed a feature team; except their were not.
Note that this same problem could happen if, instead of UI team, you talk about Marketing, IT, Sales, Localization, Documentation, Certification testing, etc.
A feature team is not defined by it’s structure (being cross-functional), it’s defined by it’s output! (delivering shippable pieces of the system)
Proposal for a new definition of Feature Team
So here’s a proposal for an improved definition of a feature team:
A feature team is a long-lived group of people that typically involves engineering and non-engineering functions and delivers a complete and potentially shippable feature at the end of every Sprint.
A Feature Team may, as needed, include roles such as: UI designers, UX testers, IT personnel, Marketing, Sales. A feature team will in any case involve all roles that influence the development of a feature to the point of being shippable.
 Scaling Lean and Agile Development, Larman, Vodde: Feature team definition on page 153
4 thoughts on “A feature team needs more than a cross-functional group!”
I see two things here:
1. The team was not actually cross-functional… or at least for me cross-functional does not mean only the developers of all application layers (but in this case even the UI layer has been excluded from cross-functional team.)
2. The team had wrong Definition of Done for stories or for the sprint. Otherwise they would not consider a functionality as “done” without having the UI designed and integrated for each function.
So basically I think there is no need for a new definition, but a need for understanding the original one better.
BTW I’ve been a part of such team once and we did the same mistake of postponing the UI integration until the last sprint… and I remember one thing… NEVER, EVER DO THAT AGAIN! 🙂
@Marcin The team had UI people, just not “the” UI people that were re-designing the UI.
You are right when you say that the team should include all people that contribute to the release (as I say in the post, even Marketing and IT), but a more important point in my post is this: a Feature Team is not defined by it’s structure/composition, but rather by it’s output. Basically being cross-functional is not enough, you need to be able to release something to the market before you can call yourselves a “Feature Team”
It’s a good story. I see your point with the feature team and your definition applies to feature teams too, however I’m with Marcin.
In this case it was the understanding of what is a feature team not really clear.
I have a very similar example, where actually all the participants in the project understood the principles, but the management did not fully supported it, and so broke the “process” with actions like you describe here.
@Tom Can you describe that case? How did management “break” the process? How did the team react to that?
Comments are closed.