Who is the Scrum Development Team?

Scrum defines three roles within the Scrum Team: Product Owner, Scrum Master, and Development Team. Literature abounds when it comes to the former two, while the latter rarely gets mentioned.

What is the Development Team?

According to the Scrum Guide, this team encompasses all the people needed to make a product backlog item become an increment to the potentially deliverable product. In a rather powerful way, these people are the ones who make things happen. If there is no decent Development Team to build the product, having great Product Owners or Scrum Masters really won’t matter.

The features of a Development Team

It should be

• multidisciplinary
• self-organized
• self-managed
• autonomous;
• committed
• focused
• tireless in the quest to improve on its ways of working and results

Those features are easy to list but hard to accomplish. Let’s discuss them individually.

Multidisciplinary

The Development Team has all the skills needed to cover the workflow end to end: from hypotheses formulation to business problem-solving until delivering the product to the final client, including data collection on results — the Team has to cover it all.

If you work in a small or mid-sized company, creating a multidisciplinary team is relatively easier. For big companies, finding scenarios with rather vertical silos of specialization is quite commonplace.

Specialization requires managing experts. Additionally, there are costs associated with operationalization and “resource” coordination (and please check out Rodrigo Toledo’s post on how we are Humans, not Resources!). All this makes it quite tricky for a multidisciplinary team to exist, as politics gets in the way.

When the team is not multidisciplinary, it starts having handoffs (passing the baton) to external people. This behavior decreases efficiency and creates a spirit of “us vs. them” as in “We’ve made our move. Your turn”.

Let us be transparent about the losses that we experience due to external handoffs. First, handoffs should be presented on the task board.

Besides, using metrics is vital to increase transparency. The most interesting metric would be Customer Lead Time: the time elapsed between the moment in which the Development Team commits to a backlog item until its delivery to the final customer. Also, Local Lead Time (or Cycle Time) would be of interest since it means the time elapsed between any of the flow steps.

That said, the team will know when the value item will be under its responsibility and for how long the item will lie with external teams. Are you curious (or plain out confused) about metrics? Check out our training on Agile metrics.

Another important metric that doesn’t usually come up when discussing Agility is team cost. Knowing this figure matters for us to justify bringing over a new member, for example, or investing in having someone from the team acquiring a skill that the team needs but doesn’t have just yet.

Those were three efficiency metrics. Measuring the efficacy of the team is vital. Otherwise, it will just be taken into account as a cost, and companies just love cutting costs, don’t they?

The next question would be, how much is this team worth? How much does the company make with the deliveries that it performs? One could use many efficacy metrics to measure: revenue, churn, customer satisfaction, retention rates, client acquisition, Return over Investment, etc. (Check out our post on Metrics: how to measure your team’s agility).

There is a metric that I absolutely adore and still want to cover in this blog, which is called Cost of Delay. For now, you’ll have to do some research by yourself, but it will be worth it. Putting it shortly, it is about how much money I refrain from making due to delaying the delivery of a product or product increment. This metric takes into account possible new competitors entering the market and seasonal events.

With such information in hand, the team can consider more investments. Do not sit and discuss matters with managers or directors without data and hard facts!

Self-organized

The Scrum Guide states that NO ONE outside the Development Team must tell it how to conduct development. Neither a Scrum Master nor even a manager. The Product Owner establishes what will be done. The “how” depends on the Development Team.

However, it is common for us to see teams asking people in leadership roles how to go about development, which tasks to execute, or who should perform them.

The origin of this problem may be in how formal schooling and general education is handled. Ever since we are children, we have someone who sets the tracks for our personal journeys. The relationship between teacher and students stems from Fordism (watch Sugata Mitra‘s video on this matter). From then on, we learn that there is a superior person who is the “most intelligent in the room” (teachers, parents, managers, and leaders), and that we must follow them.

Self-organization breaks this paradigm. From now on, the Team is the most intelligent person in the room. This act of breaking free depends heavily on the maturity of both the leaders and those under their leadership.

If you are a leader, whenever someone asks you to make a decision or answer a question that your team can handle by itself, an alarm should sound in your mind. Before undertaking any actions, ask yourself right off the bat, “What am I doing wrong since the team still needs me to make such a decision?” Then, move on to action-generating questions, “How can I make my team not depend on me for this?”, “How do I stop being Cc’d in every e-mail (which reveals insecurity)?”, “How do I stop taking part in meetings that do not depend on me?”

If you belong to the Development Team, ask yourselves the opposite questions, “Do we really need the most expensive people in the company to make this decision or answer every question?”, “Is it worth it cluttering the e-mail inbox of my leader with this type of matter?”

Unfortunately, some managers still believe in the old-fashioned management model and think they will lose “control” if they do not call all the shots on how to do things.

If you happen to be in this situation, I’m very sorry to tell you that, when it comes to knowledge workers, creative working, and complex systems, “control” has already been lost. But this is a long conversation — let’s have it in an upcoming post. Paraphrasing Peter Senge (The Fifth Discipline, 1985): “you hire people based on what they have from their necks up, and not from their necks down.”

Self-managing

Some teams ask for permission before doing something or a blessing from someone from the leadership once they take action. In a mature Development Team, we hope that people know how to self-organize and manage themselves. The Development Team must decide who should be hired or let go, which training each member will take, if the job should be done on-site or remotely, meeting times, participation in events, among other management attributions.

This feature is particularly hard to achieve by certain companies since laws and procedures may impose self-management restrictions. In such cases, the key thing is to find out how far the team can go. For instance, the team may freely decide the Scrum ceremonies times. Still, hiring and firing will remain under HR. What is the autonomy level, anyway?

Autonomy

The Development Team must have the autonomy to make decisions and perform their work. What tools to use, authorizations, administrative activities, knowledge needed, etc.

A very interesting tool to determine a team’s autonomy level and grant transparency is the Delegation board. It is basically a board in which the Scrum Team and managers can define the level of autonomy for each decision. Levels range from 1 (manager decides) to 7 (full delegation). In this board’s most recent version, from 1 to 5.

Committed

Commitment to product increment, solving the client’s problem, the business results, and, above all, with the Scrum Team is vital. If there is no commitment with those aspects, there won’t be a team: all we will have is a group of people who may, out of sheer luck, be able to eventually delivering something.

Besides, there are no sub-teams within a Development Team. Saying “I’ve done my bit” is simply not an option. Success depends on everyone’s work! Failure, on the other hand, is shared among all.

Focused

Focus is always on delivery. If the team is committed, the goal to reach will be crystal clear. The team must also know which efficacy metrics to use to determine if it is on the right track.

Special attention must be given to transparency. No “invisible work” must go on during development. If any of the team members are taking care of other activities that are not related to building and delivering the product, we must grant visibility to such work. It may be on the workboard (or even on a separate board). Make sure to measure the impact caused by this type of work before trying to shoot it down (Malone and the knife brought to the gunfight, remember?)

Continued improvement

Stop improving = stop evolving. The Development Team must be tireless in perfecting its work. Improvement should take place in all dimensions, such as workflow, processes, tools, collaboration, administrative procedures, etc. Within Scrum, there is a specific event for that purpose, namely the retrospective meeting. It is worth highlighting that any moment is a moment of improvement. There is no need to wait until the retrospective takes place.

Holding an experimental culture is fundamental. Do not try and get everything right in the first attempt. Trying to foresee all the possible consequences of an experiment leads to the tragedy of BDUF.

Team size

The Development Team must have at least three people to be multidisciplinary, even if only minimally, and avoid external dependencies that hinder the team from delivering product increment. Also, it shouldn’t have more than nine members, as the cost of coordinating large teams is too high. Brooks’s Law on the interconnections of communication channels explains why.

Brooks’s Law has “I” as the number of connections, and, in the case of Scrum, “n” as the number of people in the Scrum Team and other stakeholders.

If you have 11 people (9 in the Development Team + Product Owner + Scrum Master), you have at least 55 communication channels. If you have more than that, coordination costs and time needed for decision making will skyrocket.

It’s about people

One rather unfortunate idiomatic development is that the management and project management world got used to calling people “resources.” The word “resource” makes us think of objects, things. If an item breaks, you toss it and get a new one. Do you currently belong to a team? Then think about what you would do if your best technicians left the company today. TODAY. Would you just “train someone else”? There you have it.

Chairs, desks, paper, pencils, phones, computers — those are resources. They do not need to learn (nor can they), and things never evolve. In case you want them to be better, you’ll have to get new ones. It’s different when it comes to people. They get better over time. Working at a sustainable pace, enabling a safe environment, and respecting diversity will transform your team into a High Performing Team.

Did you like this article? Take a sneak peek at other posts related to this subject:

• Agile Radar and Its Criteria: a Diagnostic of Your Team’s Agility
• Want to increase your company’s productivity? Give time off!
• Transforming a task team into a product team
• Silos: visualizing and dealing with the team’s dependencies
• Are we actually a team?

Register for one of our training programs:

• Certified Scrum Master® (CSM)
• Certified Scrum Product Owner® (CSPO)