Working in multidisciplinary teams is common in Agile. In practice this means that the team consists of people with different skills, but work in the same dimension (for instance software). What about cross dimensional teams? In cross dimensions teams not only the skills differ, but also the area of expertise. For instance developing an electronic device includes electronics and software. They work on the same project, but can they act as one team?

Teams
There are all sorts of teams, but the most common in agile and lean are multidisciplinary teams and multidimensional teams. The multidisciplinary teams consist of people that together cover all the skills needed for the product. Whereas the multi-dimensional teams consist of different teams with different skills that work together in sequences (lean).
In a cross dimensional team, the team consist of multiple teams developing one product in parallel. The difficulty with cross dimensional teams is that they have a different heart beat, problems and constraints while working one product. For instance developing an electronic device like a touch MP4 player consist of the electronics for the device and the software that drives the electronics.
Developing in these two dimensions require both doing research and development. They also depend on each other in a way. Without the software the hardware team cannot check whether the touch hardware is working and vice versa. On the other side there are some areas in which they don’t depend on each other, but can influence each other. For instance a hardware component can limit the features in the software and vice versa.
Putting these dimensions in one team with one backlog does not make them more effective. Due the different heartbeat it could mean that they have to wait for each other. However they do have some areas in common. For instance the interface between the hardware and software. This is the contract between the two worlds. The earlier this interface is clear the more freedom the teams have.
The figure below shows the time line of a cross dimensional team working on one product in an agile way. Purple for the development of the electronics (hardware) and red for the development of the software.

The dimensions of the team start at the same time. In this first period it’s important to do the things in common first. Later on in time there is no possibility to change decisions. The reason for this is that electronics production has a lead-time. Once this process is started, there are only some small changes possible due to high costs. Therefore the early stage is important to get things clear.

Dimensional planning
Dimensional planning (story mapping) can help with this. Usually interfaces and prototyping are put in the first slices. The features that can be addressed later on should be in later slices.
Most of the times the different dimensions of the team work from separate backlogs, but are aligned in the dimensional planning. Although they work from a different backlog they can discuss the problems together. Often this leads to better solutions due to the different views on the problem. In some cases this leads to backlog items for the different dimensions.

Freeze
Somewhere in time the electronics development is frozen in order to start the hardware production on time. From this moment on only small changes are possible. For instance to lower the radiation levels or things that need to be done in order to get an CE certification. Meanwhile the other dimension still continues to develop software for the device. Sometimes solving some hardware issues. Depending of the requirements of the CE certification the main software features needs to be frozen too. Fortunately software updates can be applied in a late stadia.

Conclusion
In conclusion a cross dimensional team can work in an agile way. Using dimensional planning brings focus to the cross dimensional teams. Important is to freeze the interfaces between the hardware and software in an early stage. This will reduce the dependencies of the dimensions. Problems that occur during the prototyping can be solved by working closely together in an early stage.

Filed under Agile, Articles | 1 Comment »