In this series of blog posts I will be exploring what I feel are some of the important aspects of software development management, particularly in relation to web application development.

A cross-functional team is generally defined as a group of people with different expertise working towards a single goal or objective. Within software development, this means a team of people who will collectively hold all the skills required to develop, build, and deliver the product. For example, when developing a web application, you would want the development team to have expertise not just in coding in the programming language of choice, but also in databases, systems, usability, UI/UX/front-end design, front-end development, testing, technical writing, and so forth.

The common single goal and nature of cross-functional teams make the greatest advantages to the approach seem fairly self-explanatory, but difficult to describe. Perhaps Mary and Tom Poppendieck summarised it best in their book Lean Software Development. They described seven types of waste in software development, and cross-functional teams can help in all of them:

• Partially done work, or work which has not yet been delivered. For example, work which is yet to be tested. Cross-functional teams minimise the effect of this by ensuring no external dependency – continuous testing can take place, and in an Agile environment delivery is made at the end of each iteration ensuring partial work is not left waiting.
• Extra features, or providing more features than have been requested. This is particularly pertinent when comparing Waterfall and Agile methodologies – in Waterfall this will not be apparent until delivery, whereas with Agile methodologies there will be more opportunity to act. A cross-functional team can help by providing domain experts who can assess when to stop working on a feature.
• Relearning, or reinventing the wheel. A cross-functional team can share knowledge and prevent the team from working on a problem which has already been solved.
• Hand-offs. Handing off work to a third party will suffer from two problems: the inevitable documentation, and a potential degradation of knowledge. Within a cross-functional team, less documentation will be required as there will already be prior shared knowledge, and there will similarly be less room for misunderstanding. All this will lead to fewer delays.
• Delays. As alluded to above, cross-functional teams will reduce delays in communication and external parties, but also those due to, for example, differing priorities.
• Task switching. Interruptions can be minimised when work can be coordinated within a single team, without external dependencies.
• Defects. Not just bugs, but misunderstanding the functionality and delivering the wrong thing. A cross-functional team is better suited to defining the functionality, and involvement from all team members means better test coverage.

There is a certain amount of disagreement on whether Scrum should include specialists in defining a cross-functional team, or whether cross-functionality should be achieved by having team members work in areas outside their area of expertise. In practical terms, I’ve found it to be a little bit of both, but either way I think it’s clear that cross-functional teams are important.

Photo by Simon Liu via flickr.