We’ve had a lot of great discussion here recently on the very important topic of iterative development and I suspect we are far from exhausting the topic, but let’s shift gears for a moment.
One of the topics I mentioned in my article on Development Effectiveness was that of cross-functional teams (CFTs), also called “project teams.”
Definition: A CFT is a group of people who work together from start to finish to produce a piece of software, and whose make-up consists of one or more people from each of the key disciplines required in the development process. A typical CFT consists of:
- a business analyst (or equivalent title)
- one or more engineers
- one or more QA people
- a systems analyst (for organizations that have that role)
It could also include full or part-time participation from a variety of other disciplines such as UI design, database design, tech writing, and others.
I think that CFTs are a natural and essential part of doing iterative development. Why? Iterative development requires short cycles, so you can’t afford to have work done sequentially where each functional group throws things over the wall to the next functional group in line. Because a CFT is a cohesive group that takes a piece of development work from start to finish, it is ideal for doing work quickly with good intra-group communication – just what is needed to make iterative development work.
Further CFT characteristics:
- Each CFT has a leader. This could be anyone on the team who has good leadership abilities. In my experience, is it usually the business analyst but sometimes one of the engineers. This person is essentially the project manager for the work being done by the CFT, and takes overall direction from the project manager of the whole project.
- The CFT should be the right size – not too small or too big. If you look at my earlier post on What Makes a Great Team I argued that 5 people was the best team size. A team twice that size starts to lose cohesion and might be better separated into sub-teams. Thus a large project likely has multiple CFTs.
- The entire group works together from start to finish. The QA people don’t join late and have to catch up, and others don’t go on to start new work leaving QA to clean up a mess.
- The team works closely together. Everyone on the team needs to understand the requirements, the solution, and how the solution will be verified and validated.
- The CFT is semi-durable. A good CFT needs a lifetime long enough that the team can form some cohesion. I think a good CFT will last for at least the duration of one release cycle, and possibly longer. If it lasts longer, it would be good to allow some members to move to other teams and some new people join, while preserving a core.
- CFTs are flexible. A CFT might be created for the express purpose of building a large feature, and/or it might be given a set of features to work on over a series of iterations. When it is no longer needed, it can be dissolved and the resources reassigned to other CFTs.
I’ll make one other assertion, perhaps controversial: When you are on a CFT, it is the group to which you owe your highest loyalty. You are no longer part of the engineering team, or the QA team, or the BA team. You are a member of a team of people whose goal is to produce some specific software, and any other mission or instructions are secondary.
I don’t know to what extent CFTs are used in other places, but I’ve used them before at other companies with great results. Within the my development organization we have been using CFTs to some extent already, and are adopting them more completely on some new projects. We’re off to a good start so far.
