1

As a Scrum Master my team is already on the big side:

  • Product Manager
  • Associate Product Manager
  • Business Analyst
  • User Researcher
  • Interaction Designer
  • Content Designer
  • Developer
  • Developer
  • Developer
  • Developer
  • Architect

The team used to have a tester but she left the team for a while but now she apparently wants to rejoin the team.

The team seem to be handling testing fine without her and this is the direction of the org ie for each team to collectively own testing. Which is my preference.

My question is should I take this to the team for them to decide if they want a tester or should I leave the team as is?

I am sure the team will say yes to having a tester, but this goes against building cross-functionalists.

4
  • 2
    Your scrum team has 12 people and only 4 are probably cross functional. Who is actually on the development team? Just the four? And would you consider the tester to be in the development team?
    – nvoigt
    Mar 7, 2020 at 9:34
  • The developers are the only ones doing development. The others assist with current tickets or are helping groom the next sprints tickets. Tester would be part of development. Anything you suggest would be helpful even if you suggest splitting out the functional or design people. I should maybe do another question for this.
    – user32613
    Mar 7, 2020 at 9:38
  • 2
    More than half the roles you named are explicitly not Scrum roles. If you’re not doing real Scrum, then why not just build the team you need or want?
    – Todd A. Jacobs
    Mar 7, 2020 at 15:13
  • True. That’s what I was also thinking. The structure of the team is already so far outside of what scrum recommends what’s the harm in just taking it to the team. It’s a tough one. I want to guide them but at the same time they already so far away in terms of structure from what scrum recommends.
    – user32613
    Mar 7, 2020 at 15:20

6 Answers 6

3

A lot of comments are made about the size of the team and the roles within it, so I'll skip that.

My advice (with most questions, issues or whatever): Take it to the team

The team is doing the actual work and they can tell what they think they need or should do or whatever. Then you can have a discussion about the situation and come to a solution with the team.

Do not talk about the team and their needs, talk with the team

2

As a Scrum Master should I decide or the team decide whether they need a tester?

This is how traditional project managers talk, not scrum masters.

If your team members consider a tester would help and they want a tester, then they should have a tester. The team decides.

This directly answers your title question. I'll now say a few things about what you mention in the rest of your post.

You have a Product Manager, an Associate Product Manager, a Business Analyst, a User Researcher, an Interaction Designer and a Content Designer in (what you consider to be) your team, but somehow you think a tester would be too much? Will a tester help the team provide more or better value? Then get a tester. If not, not.

The team seem to be handling testing fine without her and this is the direction of the org ie for each team to collectively own testing. Which is my preference.

The direction of the organization? The organization decides if developers need testers or not? Scrum teams need to be self organizing. They decide if they need testers or not to do their job properly.

I am sure the team will say yes to having a tester, but this goes against building cross-functionalists.

Cross functionality doesn't mean that everyone does everything. Cross functionality in Scrum means that the team has all the skills necessary to build the product. The team as a whole. It doesn't mean that developers need to do a tester's job also. They can, but it shouldn't be mandatory. Think about it, a User Researcher that does no programming and no testing goes against building cross-functionalists also. What are you going to to about it now to build cross-functionalists?

As a personal story, I've often found myself in the position of being a one man show and although I could handle lots of things on my own, from a lot of different areas (be a cross-functionalist, if you like), everything would have been more efficient and turn out better if someone with more specialized skills would have handled some of the things I did. So if your team needs a tester, let them have a tester. That way testing can be handled in a more focused and efficient manner than others constantly switching from one role to the other.

3
  • This is one of the most patronizing answers I have ever encountered. You either are sitting at the top of your organisation or you have no experience on the ground. The reality is that yes teams have constraints and yes organisations are hierarchical and yes developers who aren’t experienced with Agile need some direction and education. If you think you can tell a whole organisation to self-organise with absolutely no constraints you’re living in fairy land. So unhelpful and also dangerous for inexperienced agilists. Keep beating me with your Agile bible.
    – user32613
    Mar 7, 2020 at 10:23
  • 2
    I'm giving you an answer that I think you need to hear, not an answer that you would like to hear. I'm sorry if you find it patronizing. Note that the scrum master also needs to serve the organization, and scrum itself tends to bring attention to the bad things that happen in the organizations. Then the question becomes what do you do when you find problems? Do you have the courage to bring forth a change for the better or do you just bend things around because there are constraints, and hierarchies, etc?
    – Bogdan
    Mar 7, 2020 at 10:37
  • 2
    As for your Agile bible comment, remember that Agile/Scrum is a tool, not a religion. And tools are most effective when used properly.
    – Bogdan
    Mar 7, 2020 at 10:41
2

It is the responsibility of the Scrum Master to make sure the team is following Scrum, but adding a tester to the team does not conflict with the Scrum Guide.

However, the Scrum Guide does recommend keeping the team size to 9 or fewer, so it would be worth discussing that with the team. A good approach would be to keep an eye out for issues related to team size, such as communication break-downs.

I am sure the team will say yes to having a tester, but this goes against building cross-functionalists.

There is no reason why you can't have a tester in a team of cross-functional people. Testers may well get involved with analysis and some may do coding or configuration tasks as well. They can have just as much of a t-shaped skill profile as a developer can.

What a good tester can bring to a team is a quality mindset. They may look at the product's functionality in unusual ways, spotting potential problems that may not be spotted by others.

2
  • Interesting perspective. I would have said that the Scrum Master deciding to add a tester would conflict with the fact that only the team gets to decide how to do the work, since it seems to strongly imply that they need a certain person to test.
    – Daniel
    Mar 8, 2020 at 1:18
  • I certainly didn't mean to suggest that the Scrum Master makes the decision on adding a new team member. I was referring to the question of whether they have the right to veto the decision of the team. Mar 8, 2020 at 8:38
2

Perhaps it will be helpful to reframe the question. We can ask instead, "Does my team have the skills around quality necessary to deliver the product increment?" You may think you know the answer to this question - you may even be right. However, this is a question for the team.

The Scrum Guide has this to say about the development team:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

This does not give permission to the team to create increments that are not potentially releasable due to quality problems. So while we could say that it isn't your role as SM to tell them that they do or do not possess the necessary skills to produce a quality increment, you absolutely should share what you see that may indicate that they are not meeting that standard. For example, if you see a high number of returned defects, or increments being declared not shippable because of missed testing.

Now the question for the team is how to meet this standard. Perhaps it is a process issue - that they have the skills but need to apply them. Perhaps they don't have the skills, but learn them from someone on another team. Perhaps they decide that adding another person would be the best way to acquire that skill. Really, this is the same thought process for every skill the team may need.

The red flag I have about needing another person is two-fold:

  1. We shouldn't conflate people with skills. What the team needs is the skill. Simply adding people for each skill can get expensive and can reinforce bottlenecks.

  2. For most teams, this simply isn't something that is in their control. There is an approval process for budget, a hiring period, a training period (where the whole team will slow down to train the new person). How will the team produce anything in that time period? Are those months just a wash?

Theory vs Practice

Okay, all that was very much background theory and thinking. So what's the practical answer? If I was in your shoes, I would take these steps:

  1. Determine if there is a quality problem. Share your observations with the team. Help them verify the expected level of quality with the PO and the organization (and the customer if possible).

  2. If the answer is "Yes, there is a quality problem", determine what skills and behaviors are needed to resolve it. Again, this is an exercise we facilitate with the team.

  3. Determine how we can meet the standard this sprint. I would start here because through the conversation we will learn what is possible now, what might be possible with another person, and if we are just stuck without another person with deeper knowledge.

  4. Clear space for it to happen. Here is where your job gets hard. Unless #3 uncovers something convenient, your team may need help from other teams, other parts of the organization, or a variety of other things, even if you don't need another person (and if you do, there's a process to start for that too).

    The team should not be working to look busy - they should be building product. If they don't have what they need, they can't make the product increment and they shouldn't be just working on nothing releasable. Of course, in the real world, a lot of people won't like that answer. Here is where coaching others in your organization is very important for them to understand the stakes and what the team needs without just sounding like a zealot.

    I hope this isn't too blunt, but making that happen is why the team has a Scrum Master. It's a big part of what makes Scrum work. And how to do it is pretty much impossible to put in a Stack Exchange answer (sorry).

  5. Make amazing products! Celebrate a job well done.

0

This Mike Cohn article largely answers my question:

https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly

“Management Exerts Subtle Control over Self Organization

In the original paper describing Scrum, Takeuchi and Nonaka identified “subtle control” as one of its six principles. They list staffing decisions as a key management responsibility.

Selecting the right people for the project team while monitoring shifts in group dynamics and adding or dropping members when necessary [is a key management responsibility]. “We would add an older and more conservative member to the team should the balance shift too much toward radicalism,” said a Honda executive. “We carefully pick the project members after long deliberation. We analyze the different personalities to see if they would get along.

Getting the Right People on the Agile Team

If you are a personnel manager or otherwise influence team composition in your organization, here are some of the factors to consider.

Include all Needed Disciplines on Agile Teams

As a cross-functional team, it is important that all skills necessary to go from idea to implemented feature be represented on the team. Initially this may mean that team size is slightly larger than desired. But, over time, individuals on a Scrum team will learn some of the skills possessed by their coworkers. This is a natural result of being on a Scrum team. As some team members develop broader skills, other individuals can be moved onto other teams.

Mix of Technical Skill Levels on Agile Teams

Subject to considerations of team size, you should strive to balance skill levels on the team. If a team has three senior programmers and no less-experienced programmers, the senior programmers will need to code some low-criticality features that they could find boring. Not only might a junior programmer have found such features enjoyable to work on, that programmer would also benefit from learning through association with the senior programmers.

Balance Domain Knowledge on Agile Teams

Just as we strive to balance technical skills, we should strive for a balance between those with deep knowledge of the domain in which we are working or the problem we are attempting to solve. This is not to say that if we have the opportunity to assemble a team entirely of domain experts we shouldn’t take it. Rather, we should consider the long-term goals of our organization. One of those goals is likely the build up of domain knowledge throughout the organization. You’ll have a hard time achieving that if you put all of the domain experts on one team.

Seek Diversity on Agile Teams

Diversity can mean many different things—gender, race, and culture being just three among them. Perhaps equally important can be how individuals think about problems, how they make decisions, how much information they need before making a decision, and so on. Research shows that homogeneous teams reach consensus more quickly than do heterogeneous teams, but they do so by failing to consider all options.

Consider Persistence When Forming Agile Teams

It takes time for agile team members to learn to work well together. Strive, therefore, to keep team members together who have worked well together in the past. When forming a new team, consider how long members will be able to work together before some or all are dispersed to other commitments.”

-1

I strongly agree that "teams are not put together randomly." Whether or not your team as composed strictly follows the organizational principles spelled out in "some book," and whether or not you call yourself by a title contained in "some book," the bottom line is that your job is to ensure that the team produces quality software, steadily and consistently.

Therefore: do you perceive that there is a quality problem? Do the developers think that they would benefit from having a dedicated individual whose job is to do nothing but testing? Do you?

When the team completes and signs-off on a milestone, does the work subsequently remain stable?

Whether or not you have a separate person who is testing what others have done, testing always needs to be embedded into the software development process. It isn't enough to write a block of source-code: you have to prove that it works. And, you have to be able to continuously test to make sure that what used to be working didn't subsequently break. The developers must have first and primary responsibility for this: "you write the code, and you write the tests." Meanwhile, in a large team such as yours, I do like to have someone else whose full-time job is to take that bigger view, to look for regressions, to push every button and click every field, while the developers have moved on.

I don't really believe that development teams are, should be, or really can be "self-directing." They need guidance and that means you.

1
  • I'm sorry but this isn't good advice. The purpose of a Scrum Master isn't directly "to ensure that the team produces quality software, steadily and consistently", that's the job of the dev team itself. The Scrum Master helps the team become better at this through coaching on self-organising/self-directing and Scrum processes etc. It's unfortunate you don't believe it is possible for dev teams to be self-directing but there are plenty of real world examples to the contrary. Mar 10, 2020 at 18:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.