Traditional software development approaches define various job types, such as architect, programmer, tester, database administrator, UI designer, and so on. Scrum defines the accountability of Developers, which is simply a cross-functional collection of these types of people. In particular, Developers are one of the three accountability on every Scrum team. Developers have the skills required to deliver the business value requested by the product owner. 

In Scrum, Developers must do all of the work to produce one or more vertical slices of working product functionality each sprint, including the design, development, integration, and testing of that functionality. Thus, we need a team that is skilled at all of those tasks.

Perform Sprint: Execution during sprint execution, Developers perform the hands-on, creative work of designing, building, integrating, and testing product backlog items into increments of potentially shippable functionality. To do this, they self-manage and collectively decide how to plan, manage, carry out, and communicate work. Developers spend a majority of its time performing sprint execution.

Inspect and Adapt: Each day Developers are expected to participate in each daily scrum, during which Developers collectively inspect progress toward the sprint goal and adapt the plan for the current day’s work. If some team members do not participate, Developers can miss pieces of the big picture and may fail to achieve its sprint goal.

Refine the Product Backlog: Part of each sprint must be spent preparing for the next. A large part of that work focuses on product backlog refinement, which includes creating and refining, estimating, and prioritizing product backlog items. Developers should allocate up to 10% of its available capacity every sprint to assist the product owner with these activities.

Plan the Sprint: At the beginning of each sprint, Developers participate in sprint planning. In collaboration with the product owner and with facilitation from the Scrum Master, Developers help to establish the goal for the next sprint. Developers then determine which high-priority subset of product backlog items to build to achieve that goal. For a two-week sprint, sprint planning typically takes about half a day. A four-week sprint might need up to a full day for sprint planning. Notice that planning happens iteratively. Rather than focusing on a very large, uncertain, and overly detailed plan at the start of a development effort, Developers make a series of smaller, more certain, and more detailed plans just in time at the beginning of each sprint.

Inspect and Adapt the Product and Process: At the end of each sprint, Developers participate in the two inspect-and-adapt activities: sprint review and sprint retrospective. The sprint review is where Developers, the Product Owner, the Scrum Master, stakeholders, sponsors, customers, and interested members of other teams review the just-completed features of the current sprint and discuss how to best move forward (see Chapter 21). The sprint retrospective is where the Scrum team inspects and adapts its Scrum process and technical practices to improve how it uses Scrum to deliver business value.

Characteristics: 

•  Developers are SELF-ORGANIZED and SELF_MANAGED. Developers are empowered in self-organization in such a way that no one, including the Product Owner, Scrum Master, or any other manager external to Developers directs or commands them about how to perform their work. Developers self-manages by getting focused on the goal and nudged by time-boxing.

• Developers are CROSS-FUNCTIONAL.  Developers are unified in such a way that there are no specialist roles or sub-teams. The individual developer may have specialized skills and areas of focus, but accountability belongs to Developers as a whole. The Sprint Goal binds Developers together.

Developers may contain various specialists needed to achieve the Sprint Goal. For example, there could be Programmers, Testers, UI modelers, Architects, Technical documenters, etc. But there is NO special name for any of them. Irrespective of their field of specializations, every one of them is called a Developer. While the specialist should identify themselves as part of team and learn additional skills to collectively deliver the Sprint Goal, there is no barrier to personally enhancing their vertical competencies and continue to specialize. For example, a team member with architecting skills may be added if the work requires that skill. Though this team member will contribute to the architectural aspects of the effort, he or she along with the entire team is responsible for the progress of the collective Sprint Goal and is expected to help Developers to reach that goal. In the process, this team member may enhance skills other than architecting to become cross-functional too.

A cross-functionally diverse team has members from different backgrounds. Each team member brings a set of cognitive tools for problem solving; these tools can involve different interpretations (of the same data), different strategies (or heuristics) for solving problems, different mental models of how things work, and different preferences for both approaches and solutions. This kind of diversity typically leads to better outcomes in terms of faster solutions, higher-quality deliverables, and greater innovation, all of which translate into greater economic value.

• Developers usually have 3 – 9 members working full-time within a Scrum Team. Developers are structured in such a way that they are small enough to reduce communication complexities and big enough to include the required skills to perform a complete work.

The optimal size of Developers in the Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Developer members decrease interaction and result in smaller productivity gains. Smaller number of  Developers may encounter skill constraints during the Sprint causing the Developers to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. A large number of Developers generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

• T-shaped skills mean that a team member (say, Sue) has deep skills in her preferred functional area, discipline, or specialty. It’s unrealistic to believe that every person on a team could work on every task. That’s a lofty goal to have.

Managers should focus on forming teams that have the best set of T-shaped skills that are possible with available personnel. However, it might not be possible to get exactly the desired team skill set from the get-go, so the desired skill set could evolve over time as the needs of the product development effort evolve. Therefore, it is critical to have an environment where people are constantly learning and adding to their skill sets, whether those include domain knowledge, technical knowledge, thinking skills, or other capabilities. Management needs to support team members with time to learn and experiment.

• All for one and one for all - In a well-functioning Scrum team, I would never expect anyone to say, “I got my part done. You didn’t get your part done. Therefore we failed.” This attitude misses the point that team members are all in the same boat together.

Team members must appreciate that they must work together to meet their commitments, because if they fail, it’s going to be everybody’s problem in the end. Having team members with a Musketeer attitude is critical to achieving shared success.

Having team members with T-shaped skills encourages this attitude and makes it practical because people are capable of working on more than one type of task. On these teams I don’t expect to hear a person who is capable of doing the work say, “That’s not my job.”

However, because it is not always possible for a person to do every job, I might hear someone say, “I’m not capable of doing that job.” In this case, Developers might choose to have the person without the skills apprentice with a person who has the skills so that in the future Developers will have greater aggregate capabilities.

Even if skills limitations prevent people from working cross-functionally, team members can still organize their work to ensure a good flow through the sprint so that no one team member is overburdened. For example, holding all of the testing work until the end of the sprint so that the “tester” can do the work is most certainly a prescription for failure. See Chapter 20 for a deeper discussion of how Developers should manage flow during sprint execution.

• High-Bandwidth Communications:  Developers need to communicate with one another, as well as with the product owner and the Scrum Master, in a high-bandwidth manner, where valuable information is exchanged quickly and efficiently with minimal overhead. High-bandwidth communications increase both the frequency and quality of information sharing. As a result, the Scrum team has more frequent opportunities to inspect and adapt, leading to better and faster decision making. Because the economic value of information is time-sensitive, accelerating the rate of information sharing allows Developers to maximize its value. By quickly exploiting emergent opportunities and recognizing wasteful situations, Developers can avoid expending more resources by going down the wrong path.

• Transparent Communication: In addition to being high bandwidth (fast and efficient with minimal overhead), communication within Developers should be transparent. Transparent communication provides a clear understanding of what is actually happening to avoid surprises and help build trust among Developers. I have always felt that teams should communicate in a way that aligns with the spirit of the principle of least astonishment. Simply put, people should communicate in a way that is least likely to surprise one another.

• Focused and Committed: Team members need to be focused and committed to the Developers' goal. Focused means that each team member is engaged, concentrating on and devoting her attention to the Developers' goal. Committed means that during both good times and bad, each team member is dedicated to meeting the Developers' collective goal.

If a person is working on only one product, it is far easier for that person to be focused and committed. When asked to work on multiple concurrent product development efforts, a person must split her time across those products, reducing her focus and commitment on all products.

Ask any person who works on multiple products about her focus and commitment and you will likely be told something like “I have so much to do that I just try to do the best job that I can on each product and then hop to the next product. I don’t ever feel like I have time to focus on any one product and do it well. If there is an emergency situation on several products, I simply won’t be able to help out on all of them.”

It is harder for a team member to do a good-quality job when she is hopping from product to product. It’s even harder to be truly committed to multiple products simultaneously. Instead of being in one boat with her team members, the multitasking team member is moving from boat to boat. If many of the boats spring a leak at the same time, how does this person choose which boat’s crew to help? If a person isn’t there to bail water, that team member is not committed to that team. At best she is involved with that team. To be fair to the other team members the involved team member should make it perfectly clear that she is only involved and therefore might not be available at critical times.

Short Summary:

• Developers do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

• Developers s are structured and empowered by the organization to organize and manage their own work.

• Optimal number of Developers in the Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint.

• Fewer than three Developers decrease interaction, increases skill constraints, and results in smaller productivity gains.

• Usually more than nine Developers increase complexity and require too much coordination.

• They are self-managing and cross-functional.

• Developers are called Developers, regardless of the special work individuals may perform like testing, business analysis, etc.

• Each Developer may have a distinct work focus, but accountability belongs to the Scrum team as a whole.

• There are no sub-teams between Developers.

Do you have any questions? Ask us

 

You May Like