Agile Roles: Development Team

(This is a script for a video that will be produced soon.)

The Development Team are the hands-on professionals who work together daily to deliver a potentially shippable product at the end of each sprint. When you add a Product Owner and Scrum Master, you have a Scrum Team.

A development team does their best work when they are structured and empowered by the organization to manage and complete their own work. For instance, a single collocated team with the full complement of necessary skills to develop valuable products without relying on other teams will—in general—realize dramatically greater performance.

Modern communications technology has made developing software with distributed teams far more effective than it once was and there are many successful companies who rely heavily on a distributed workforce. Meeting in person regularly—at least once a quarter—can significantly improve the performance of distributed teams. However, it is our experience that collocated teams with significant control over their work environment (e.g., furniture choices, layout, decorations, information radiators, etc), generally communicate less formally and more effectively. They therefore enjoy reduced conflict and greater understanding of one another and the mission.

Scrum does not officially recognize unique titles for individual members of the Development Team such as front-end engineer vs QA engineer. The reason for this is that Scrum encourages Development Team members to continually develop a wider array of skills through pair programming and continuing education and maintaining formal titles only serves to force team members into a more narrow role. There is no reason why a user experience designer, visual designer, or even representative from the marketing team should not consider themselves members of the development team as their inputs are essential for the successful release of working software.

The whole team is accountable for all of the work getting done. Think of this as behaving as one team. For instance, some teams rigidly separate products or functions—such as development and QA—within the team. Having a development team split themselves into sub-teams has several unpleasant consequences. First, events are boring because much of what is discussed won’t be relevant to everyone. Second, you’ll have less redundant understanding of your products and technology, which increases risk. Third, you’ll have less flexibility if the blend of work is different than expected.

Each team members should be fully allocated to the team, splitting people across teams significantly impacts their productivity. Solid research shows that individuals and teams lose about 20% of their productivity for each additional team or project they are working beyond the first. So instead of getting half and half if someone is on two teams, you get 40% and 40%. You don’t get a third/third/third from someone on three teams, you get a fifth and a fifth and a fifth, losing almost half of their time to context switching waste.

The best team size is 3-9 developers plus SM and PO. Fewer than three doesn’t feel much like a team and can cause skill gaps and a sense of isolation. More slows the team down with communication overhead: Metcalfe’s Law states that there are n times n minus 1 divided by 2 connections between n team members, so a 10-person team has to deal with nearly twice as many lines of communication as an 8-person team.