Dedicated Scrum Development Teams and Cross‐Functionality

By Mark C. Layton

Development team members are solely dedicated to one project at a time. No thrashing your development team. You want them to be focused each day on the current sprint’s goal. Whether functional management chooses the team members or someone else does, a diversity of skills is sought after to be self‐encapsulated. Which leads to the next point — cross‐functionality.

People don’t necessarily start out being cross-functional; they grow into this state. Start with a team of diverse talents and then organically build that team toward being individually cross-functional. Ideally you want every developer to be able to do everything. This is not always possible, but you at least want every developer to be able to do more than one thing. Becoming c cross-functional is a process.

Whatever your business or organization, the facts remain: People go on vacation, they get sick, they take on new roles and jobs. One day they’re there next to you, and the next, they might be somewhere else. In traditional projects, when a key development team member goes on vacation, the project goes on vacation. You’re forced into delays either from waiting for that person to return, or in the case of attrition, recruiting and mobilizing another.

In scrum, you strive for cross-functional in your development team. In this way, you eliminate that single point of failure. If one development team member comes down with the flu, someone else can take his place and get the job done. Some additional benefits of cross-functional are

  • Allows for diverse input on development for optimal solutions.

  • Enables the ability to do pair development to ensure higher quality.

  • One of the best ways to increase your primary skill is to learn an associative skill, because this process exposes you to other ways of thinking about your primary skill.

  • Allows people to work on various things and keeps the work interesting.

Several ways exist to create cross-functional individuals from cross-functional teams:

  • Don’t use titles. Encourage an equal playing field. This stimulates junior developers to get up to speed faster, and senior‐level skills increase because senior people don’t want to be outdone by young, hungry talent. A lack of titles also emphasizes skills over fixed hierarchy, thereby encouraging skill development. Informal status still exists, but now it’s based on skills.

  • Do use pair programming. Commonly used in software development practices such as eXtreme Programming, pair programming can be used by a development team to develop any type of product. Two developers work on the same piece of functionality together. Developer A is tactically developing (cutting code, for example), while Developer B is free to think strategically about the functionality (scalability, extensibility, risks, and so on). They switch these roles throughout the day. Because these developers are working so tightly together, they can quickly catch errors.

  • Do use shadowing. Again, two developers are working together, but in this case, only one does the work while the other watches and learns.

    Shadowing also increases product quality. Remember, visibility and performance are correlated — increase visibility and you will generally increase performance. The working developer doesn’t want to take a lazy shortcut in front of the learning one, and the learning one will ask those smart “dumb questions.” Explaining something improves your own knowledge of it, and vocalizing something uses a different part of your brain and improves functioning. Finally, ownership is reinforced if you’re teaching and explaining.

The Hawthorne effect (or Observer effect) is based on studies showing that a worker’s productivity increases when someone is watching them. It’s named after Hawthorne Works, an electrical company outside of Chicago where the first experiments took place.

Rubber duck problem solving, rubber ducking, or the rubber duckie test are all terms used to describe an interesting phenomenon often used in software engineering. Programmers are told to explain their coding problem out loud and in detail to a rubber duck. Most of the time, before the programmer has even finished explaining it, the answer comes to them.

The same phenomenon can be seen when a friend comes to you with a problem. Just the process of vocalizing the issue stimulates a different part of the brain so that answers can dislodge themselves and flow downstream.

The organizational structure of scrum development teams helps prevent bottlenecks in your work flow. Through cross-functionality, pair programming, colocation, and direct access between the requirement maker and the developer, communication lines are cleared and diversity in skills is expanded. This all leads to fewer plugs in the flow.