Being a Scrum Player

Teams approach the Scrum with the eyes looking at the benefits of SCRUM without paying enough attention to what it costs to get them. We will get all those benefits if we have the right people. And that each member knows what to do in a SCRUM team. Unfortunately, that is the key part. If we have a team knowing what to do, any method will work. The reality is that a very few people know what they have to do. Human being is different. In a team, everyone has different abilities and skills.

The SCRUM guides encourages the team effort. It does not say anything about how the development team should be organized and run. That is the implementation detail part and very dependent to organizations, cultures.

The work is delivered by the Scrum Team. And a unit of work is done by a person. The actual work is carried by a person. So eventually, it comes to how to build a strong team and get the work done. At this level, it is not bounded to SCRUM anymore. It is a universal thing—team. And it is not something new. It started long time ago when human started hunting for food.

Context matters (since we are not teaming up for hunting anymore). We need to build a team that plays well in Scrum.

Welcome to Scrum Player. What does it take to play well in a Scrum team?

The below applies for a Software Development team.

Communication

Communication skill is vital for every job. Communicate well, you will get what you want. The opposite will confuse you and the others. How can it help if no one understands what you are trying to say.

Who do you communicate with?

  1. Teammates: happen daily via chatting, discussions, meetings, arguments, …
  2. Clients: Anyone outside the development team—PO, SM, employees in the same company when you ask for help

How?
If there is a formula, then no one will surfer from the misunderstanding, miscommunication. I have not found that formula yet. However, there are some guidelines from others, from book.

Read this for a complete guidelines from Basecamp. I pick here and there and make up a list

  1. Write a complete dialog before pressing the Send button. Do not force other to read 3 or 4 messages to understand what you are trying to say. Look at the rules 3,4, and 6
  2. Do you homework first before asking for help. When raising a problem, make sure to include your analysis and proposed solutions (if there is). It is not good that you raise a problem without spending time and effort on investigating first
  3. When a problem is raised, if you are looking into it, let others know
  4. It is ok to say "I do not know", "I am busy atm so I cannot help"
  5. Do not expect responses immediately. And do not let others wait too long. In daily work, 30 minutes is a good period to wait. So if you ask a questions, it is fine that there is no response within 30 minutes. And if someone mentioned your name, it was not ok if you have not responded within 30 minutes
  6. For urgent issues, do not use chat. Find other channels: Direct talk, SMS, phone call, … whatever it works

Be accountable

Every member should care for the outcome of the team. But that does not mean that all members should care all issues in the team. Everyone is encouraged to join solving problems. But there will be only one person in charge of the problem.

What does it mean by in charge?

  • Means be able to answer the question: What is the status?
  • Means find a way to solve the problem either by him/herself or by asking others internal or external. He/she can ask for the team effort if that is the way to solve it
  • Means report the final status and say thanks to the team effort

Why is it important?

  • It shows that each member cares about the team outcome; that they raise their hands to solve problems so other can focus on other tasks. That is the teamwork in action
  • Well-organized, well-managed. We know what problems we are dealing with and that they are in good hands
  • Personal growth. It is a chance to improve problem solving skill.

Specialized

Let’s face this: Everyone has different ability and skill so the price. No matter what kind of team you are in, a level 10 developer cannot just do the work that can be done by level 5. And a level 5 developer is not supposed to do the work that requires level 10. It is just delusion. It will not work.

For a software development team to work, these roles are required

  1. Architect: Without architect, the software is just a piece of code added over the time. And soon enough, it will fall apart. It will be hard, even impossible, to add features. This role is hard to find
  2. Abstract thinker: I want to use the term designer but afraid that it will confuse with the existing designer role. This role has the ability to think of component, of design pattern, of trade off between choices
  3. Specialized implementer: Good at low level implementation. He/she has specialized skill in certain languages, framework. For example, a FE developer that specializes in Angular
  4. Labor: Developers with limited experience. For every project, there are easy, repetitive but time-consuming tasks.

Do you think that it is good idea to assign an architect a labor task? No, of course not.

A developer can play many roles at the same time. It is a matter of knowing the strengths and weaknesses and assign the right tasks to the right person.

I like this saying from a wise man

Don’t send your ducks to an eagle school.

It won’t work!

 

So let put it to work. Let’s play well – Scrum Player.