When you start out an agile transition one of the first things you should consider is the move from component teams based structure into feature teams. I like the following definition:
A feature team is “is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one”, taken from http://www.featureteams.org/
However, feature teams are not the norm. Most companies have created their teams by separating different functions into different groups (Product, Analysis, Programming, testing,…) and then based on size, they split those groups according to an area of expertise, which reflect the product architecture, (Infra, Back End, Front End,…). Changing this structure to one based on feature teams requires some “Motivation” if possible at all.
The Trap of Component Teams
So other than the obvious statement of “you need to move to feature teams if you want to succeed at your agile process”, what else is there to know about feature teams. Why do component teams find it hard to function inside an agile process?
While there are a few reasons for that, I find the main cause is simple:
When you work inside a component team the work you are doing is actually never finished inside the team.
In most cases, a single team member handles only part of the work. When he finishes his part, the work is either passed to another team to continue or integrated with work done on different teams (sometimes by a third team) into the final product. The final product is then tested and approved by the QA (Fourth Team). Technically, this means that as the work progress, the original team member is becoming less and less involved, to the point of him not being involved at all.
Is This Bad?
Of course it is. It lengthens the cycle time.
Naturally, as the programmer gets less involved, he has more time and will take new features to work on. In turn, this makes him even less available to support the ongoing integration of the“older” features. And when his help is needed, he will need to “find” time for it. Usually he will be in the middle of something else and will not drop everything and help (people hate to be interrupted). Therefore time will need to be scheduled for that. Later. And everyone either waits (less likely) or finds something else to work on and before you notice it the need to get everyone together at the same time, will result in Special “integration time” to which everyone agrees to meet together and “integrate” the new work. Did someone say “Integration phase”? And since it is needed from time to time, why not plan it ahead, in fact, let us allocate integration time for all our new features.
Another thing that tends to happen gradually, is caused by the fact that teams are not perfect and not always finish all the work inside an iteration. When that happens, normally, those pesky integrations, tend to be postponed to the next sprint. By then, since we are going to do integration anyway, it looks much more efficient to combine several of them together… and you know where this going to end, right?
Let’s also consider the fact that team members who are less involved in the later stages of development find it harder to see the “big picture”. When you pass your work to another to integrate your ability to see and understand the entire system is smaller. You don’t see the entire system work together that often, you tend to interact with “end users” much less, and understanding the actual business domain also becomes somewhat twisted. That is a very big problem.
And if that’s not enough, when I worked in such a context, I found it very hard to work as a real team. Even though I worked with others in my area of expertise, the fact that I was constantly pulled to help outside the team, interfered with my ability to coordinate work time with my teammates. Since that happened on a regular basis, we all found it much easier to just split our work in a way that minimized our interactions. That way no one had to wait for someone who got pulled away in the middle. Another very big problem.
Moving to feature teams
Working inside a feature team tends to help with those aspects, Since those teams are in charge end-to-end, the majority of integration and testing is done inside the team, and the ability to collaborate and continuously work on a feature from start to end increases. You are less likely to be pulled away and synchronizing everything becomes much easier.
In fact, feature teams are an essential ingredient for scaling up an agile process. (If you only have one team, it’s a feature team by definition). The more teams you have, the more important it is to reduce the number of inter-teams dependencies and that is usually possible only with feature teams.
However, that’s not an easy move, I’ve been involved in too many failed transitions that failed due to the fact that the organization was not willing to make such a move. If you find yourself working in such a context, we would still like to make small incremental changes in that direction (and hopefully will reduce the problem on the way). So here are a few tips:
- Make the goal of gaining more knowledge on the system, product, and domain explicit. One way to do that is to have everyone involved in customer support. Another way, is to make sure each member leads some significant integration preferably not of his own work.
- Encourage team exchange – maybe restructuring the entire company is not possible, moving some people from one team to another is always possible (at least for a limited time). Yes, it might not look very efficient at times. But the knowledge gained and the reduced effort in cross-team synchronization will more than compensate in the medium-long term. If possible, try to move people to other functions, team – not only from back end to the front end team but from QA to a product, from programmers to QA, etc …
- Focus on teamwork – generate real dependencies between people in a team. This can be done in the way of shared design activities, doing peer reviews, or just work together. When people depend on one another, they will have to collaborate and work together. Don’t allow teammates to work as silos in a team.
- Remove Pressure – And last, if we expect people to be involved in later stages, they need to have the time to do that. Intentionally free up the time for this. Don’t be tempted to pile up other work while “they wait” encourage everyone to get actively involved. And again while this may look at times to be inefficient, it tends to be more effective on the whole.
In the long run, people need to see and be involved throughout the life cycle and until their work gets truly done, feature teams are the most convenient and effective way to do that. It does not mean however, that if you cant move to those, there’s nothing you can do.