FDD: Feature Teams

Agile development teams use highly iterative approaches to the designing, implementation and testing of the software they are creating. The software is constructed bit by bit, in small client-valued pieces.

For example, in eXtreme Programming a small number of user stories are designed, implemented and tested in each iteration, where an iteration is typically two weeks. In Scrum, a small set of items from the product backlog are selected and completed in each sprint. A sprint is typically a calendar month.

In Feature-Driven Development(FDD) the required software is designed and built, feature by feature where a feature is defined as a small piece of client-valued function. A Chief Programmer picks the small set of features out of his list of assigned features, that make the most sense to work on next.

Being client-valued pieces of functionality, user stories and features often require changes to several classes or components to fully implement them. For example, to implement a feature that places a new web-based order for a product is likely to require enhancements to the order processing classes or component, and the product inventory classes or components.

Traditionally, each developer is given the responsibility for particular sections of the software. This might be a set of classes in an object-oriented programming environment, or a particular component in a component-based or service-oriented environment.

However, problems occur when a feature requires changes to classes or components belonging to more than one developer. In these cases, it is quite possible for one developer to be prevented from completing a feature because they need modifications to be made to code owned by another developer. For example, if developer A needs to implement a new operation in his class X but to do so requires developer B to add a new operation to his class Y, then developer A is blocked until developer B completes that task. If developer B is busy implementing some other feature then they may not be able to implement the new operation in class Y for some time.

Even in very small teams these delays can add up. In larger teams where the developers are split into separate sub-teams, the delays caused can caused in this way can be exasperating.

A second problem arises if a developer leaves the project for some reason. Frequently, the project manager finds that no-one else is familiar with that developer's code. If the departure is sudden (baby arriving a month early, an sudden illness or injury, etc) the time taken to for another member of the team to understand that developer's code can be significant. Even if the departure is planned and some sort of hand over of the code to another member of the team takes place, but this can also takes time.

In eXtremeProgramming these problems are addressed by doing away with individual developers owning different parts of the code. Instead collective ownership is used. Here everyone owns all the code. In other words everyone is responsible for the quality of all the code and anyone can update any part of the code. For example, if developer A needs to update class X and class Y to implement a feature then they simply do so. If developer B needs to update class Y and class Z to implement some other feature then they do so. If developer A and developer B both find they have updated class Y at more or less the same time, they have to work to merge the two sets of changes. In a small team such collisions are usually rare enough, and the changes quite often mutually exclusive,so that merging is not too much of a problem.

Collective ownership also addresses the second problem of losing knowledge about a set of classes when a developer leaves because if everyone can update any classes the chances are that more than one developer has worked on each of the significant classes in the software. Again this is much more likely to be true in a smaller team.

Although it sounds like a recipe for disaster, proponents of collective ownership point out that all coding in eXtreme Programming is done in pairs and this helps prevent poor design choices being made when choosing the classes or components to update.

Collective ownership is not without its own potential problems however.

• As the size of the project increases it rapidly becomes impossible for each team member to retain detailed knowledge of all of the code. This leads to de facto individual ownership appearing as pairs of developers start to pick tasks that impact code they have recently worked on in favour of tasks that impact code that they are unfamiliar with. I have seen this happening over time in a team of only five or six developers.
• Having several different developers access the same classes and components over time can lead to a loss of conceptual integrity for a class or component.
• Developers often derive satisfaction and quite rightly take pride in a well designed class or component. This can be lost in a collective ownership environment.
• Where a specialist skill is needed for part of the software, it is very difficult for collective ownership to function efficiently. For example, it is much harder for someone not familiar with the user interface libraries of the programming language to write user interface code than for someone who is.

Feature-Driven Development uses a different approach to eXtreme Programming.

it calls feature teams. Sections of code, usually classes in object-oriented programming, all have a specified developer as their owner. When it is time for a feature to be developed, the Chief Programmer forms a new feature team comprising all the developers whose classes used to implement the feature.

Feature teams are inspired by Harlan Mill's surgical teams as descried in The Mythical Man-Month . The proposal here is that a chief programmer is aided by a number of other programmers and team members with other skills to complete chunks of the software, in the same way a surgeon is helped by other doctors and skilled personnel (nurses, anaesthetist, etc) to successfully complete an operation. The team functions as a unit with the Chief Programmer being the main communication point (interface) with other teams. Each of the different roles involved, tech. author, tester, class/component owner, domain expert, are expected to be familiar with the standards and
conventions required to do their job and to coordinate as necessary with others playing the same role in other teams to ensure thins are done consistently.

Scrum project teams, eXtreme Programming project teams and FDD feature teams are expected to be largely self-sufficient. They are supposed to include all the skills and experience required to complete the set of work they have committed to deliver in the next iteration. This necessitates that the teams be cross-functional or multi-disciplined.

Cross-functional, self-sufficient teams are the natural way to scale to truly large development efforts. We have learnt that encapsulation and information hiding are crucial in building software on a large scale. The same is true of teams. Loosely coupled, highly cohesive teams communicating through well defined interfaces are just as likely to scale better as loosely coupled, highly cohesive software components with well defined interfaces.

In fact, this principle is fundamental to scaling up structures in nature and in my experience in growing sustainable companies. Trying to grow companies using centralised functional departments leads to breakdown in communications and 'teamwork' locally, adds cost through bureaucratic infrastructures needed, etc.