Scrum for Beginners 3-5-3 Part 1: Developer Role and 3 Pro-Patterns

Hello! This is Part 1 of a series on scrum using the 3-5-3 framework (3 roles, 5 events, and 3 outputs) where we use the Scrum Guide as a base for our learning.

In this article we will cover:

• What is the developer role in scrum?
• What does a developer do in scrum? What do they not do? 🌸
• 3 pro-patterns for developers in a scrum team 🌸

Click the emoji to jump to each section in the article.

What is the developer role in scrum?

The developer role within scrum is not so different from developers or engineers in other frameworks or fields of work.

As a tip, if you want to know basic information about scrum, the Scrum Guide is a fantastic resource.

The Scrum Guide says:

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Let's re-confirm what an increment is: a piece of working software that is potentially shippable and meets the team's agreed upon criteria for completeness.

Seems easy enough. The developers are the makers. We don't have a product or working increment to show if we don't have developers.

What does a developer do? What do they not do?

The Scrum Guide talks about the accountabilities of each role. This is what it says for developers:

 The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:
 Creating a plan for the Sprint, the Sprint Backlog;
 Instilling quality by adhering to a Definition of Done;
 Adapting their plan each day toward the Sprint Goal; and,
 Holding each other accountable as professionals.

Let's break this down a little bit farther.

Creating a plan for the Sprint, the Sprint Backlog:
 The developers attend sprint planning to make a plan for implementation for desired features or components. They receive valuable context from the Product Owner about business requirements and user needs. Once all parties agree on priorities for the sprint, the development team assigns themselves tasks from the sprint backlog and discusses implementation solutions

Instilling quality by adhering to a Definition of Done:
 Each scrum team has a Definition of Done that they use to hold themselves accountable for quality. This may come from other scrum teams in the organization or it may be something the team adapts to their unique situation. No completed task can be considered done until and unless it meets this Definition of Done, which may include business requirements and refactoring along with QA testing. The Definition of Done grows as the team matures

Adapting their plan each day toward the Sprint Goal:
 As new information becomes available, the developers are responsible for necessary changes in their plan. The biggest purpose of the Daily Scrum meeting is to share what new information will affect the current implementation plan so the developers can act responsibly and quickly to change

Holding each other accountable as professionals:
 This means being supportive of one another and having difficult conversations around working together. It is the job of the developers (with the help of the scrum master) to be transparent when in harmony and in conflict with each other

Now that we understand what the developer does let's look at a few things the developer does not do.

The developer does not:

• Say yes to whoever asks them to make/do something
  they are accountable for being able to say no to the Product Owner, scrum master, and even stakeholders when necessary
• Operate as a 1-person team
  they are accountable for finding ways to work together
• Work solely to complete tasks
  they are accountable for building an increment that is valuable and good quality

3 pro-patterns for developers in a scrum team

Here are 3 quick pro-patterns or good practices for developers in a scrum team:

1. Communicate technical tradeoffs to non-technical roles
The developer role requires a lot of communicating with non-technical roles. The other roles need to understand when a solution is going to cost time, money, and other resources. Good communication on these technical details help with prioritization of features and components

2. Advocate for learning
Just as a product owner needs to improve their understanding of users or the scrum master needs to understand the team's goals and impediments, developers need to keep their coding and implementation skills sharp. Working with others in the team and organization to share resources and advocate for learning time is a benefit to both the individual and the organization

3. Reduce subjectivity in code review
In many situations, code reviews differ from developer to developer. The working habits, pet peeves, and perspectives can be very different person to person. Developers who can address these situations early and set best practices for their team will spend less time in code review. This has the added benefit of avoiding reducing code quality down to the opinion of one person in the team

I hope this helps clear up some basic information about the developer role and gives you some inspiration for how you and your team can be more effective together.