0

We are an IT company and our team works for one type of products in the company. My manager currently has 9 people onsite and around 15-20 people working offshore under him. He has too many issues to handle and so he split his team into 4 sub teams. I am a Software Engineer I and we have SE II and SE III in the team as well. We started working on a new product last October and have small scrum team of 8 members (4 offshore and 4 onsite). I am a Developer onsite. Since I actively worked on the initial stages of the product and have more knowledge on latest technologies than other senior members in the team, over the time, it just happened that I am running the scrum and doing story assignments etc. From last couple of months my manager sidelined himself on other issues and put less concentration on this team and I am managing the scrum team in terms of work. I stopped writing code since a month since I am getting overwhelemd, but working on blocker issues, handling inter-team dependent issues etc. I do write code for such issues.

So far we have all the team doing both coding and testing for their own stories. We found we are running at the end of sprint and folks are not spending as much time required and planned for testing. Everyone agrees to that. I called for a meeting 10 days ago and asked for everyones opinions. There were a range of ideas on why quality is hindered - Not spending enough time on planning. Requirements are not clear at the start of sprint. So scope changes during sprint are not allowing enough time to test. Suggestions to overcome them where 50% working on Testing and 50% on Coding in rotation for every sprint (was originally my Manager's plan and I read it out in the meeting. He was not in the meeting). Some suggested folks to do both testing and coding but test for others' stories. Some have concerns that will not work since as long as person is coding, he won't have time for testing at the end irrespective of it is his story or other's story. There were other ideas as well, but we had this discussion.

We finished a sprint yesterday and planning for the next one today. Had a discussion with onsite members yesterday and everyone was okay with trying 50% testing and coding. We together decided on that idea onsite and put that idea in sprint planning meeting where offshore folks are also present. My manager knew we were going to do this. I acknowledge here that If I am going to write code, I would hate testing the entire sprint. But it was manager's idea and I was okay to try it.

During planning, one of the team members doesn't like the idea (may be because he is going to be in QA this sprint) and argued a little in the meeting. He said all the offshore discussing on it before planning and thought it would be good if everyone does both coding and testing because productivity will be less, some have to just wait for the code to be delivered (But, they have tasks to fix a few bugs and create tests cases during that time). My manager was aware that productivity will be less. I also spoke about it in the meeting (but did not say it was Manager's). To get it going, I concluded saying I hear all of them but I want to try this for a sprint and see how it goes and we can try other ideas for next sprint.

I guess this team member is mad at me now. I just felt like that, there were no explicit signs, but based on the way he spoke. How to handle such situations ? I don't have any personal grudge or hard feelings and want to be nice to everyone. I am developer and was working along side them until now. I understand we can run a team successfully when everyone is happy and is in agreement. This person is offshore and we don't interact face to face. They work in another country in different timezone.

smci
  • 2,122
  • 1
  • 15
  • 24
TechCrunch
  • 189
  • 7
  • What indication do you have that the team member is angry with you? Have you gotten management buy in on using the new method for the next sprint? – JasonJ Jun 08 '16 at 15:50
  • 3
    Some things you say about your Scrum team strike me as red flags. You say you manage them. You do assignments of work. You decided that something is done without the support of your team. Are you sure you are doing Scrum? Because nothing of this should happen in Scrum. – nvoigt Jun 08 '16 at 15:51
  • 1
    You don't hold a management role/title in the organization, yet you're directing half the developers to do zero development work and instead forcing them to do QA work? I think I'd be upset too. – alroc Jun 08 '16 at 15:54
  • I wrote the entire situation elaborated if anything changes from your opinions. – TechCrunch Jun 08 '16 at 16:32
  • @JoeStrazzere for this project we do not have separate Quality Assurance. However, other products have explicit QA teams. Developers write integration and end to end test cases in this project. During planning, developers estimate for testing. But they spending so much time on coding that testing gets small eye at the end.. – TechCrunch Jun 08 '16 at 18:43
  • "How to handle a dis-agreeing team member?" might be the most off-topic title I've seen. I'm fighting back the urge to retitle this "Team is a disorganized mess vaguely resembling Scrum, manager is AWOL, team disagreements about how to implement testing, what should I do?" – smci Feb 15 '18 at 15:02
  • 2
    The obvious thing seems to be if you're happy to continue being de-facto manager or scrum master (either, but not both!), have the boss promote(?) you officially, and insist they get you (and the team) some training and fix your methodology, and appoint/hire the other scrum master/manager position alongside you. Find them some affordable training recommendations. If you're not happy being it, step down to developer and have the boss appoint/hire someone else. So, which way do you want to go? – smci Feb 15 '18 at 15:05

4 Answers4

8

However, I concluded saying I hear all of them but I want to try this for a sprint and see how it goes.

So basically, despite their objections, you ordered them around. I'm not sure what you think you are doing or what you think your role there is (you never told us) but this is not an agile or Scrum team. There is no "manager" of a Scrum team telling them what to do. It's called "Inspect and adapt", not "My manager inspected and told me to adapt and now I have to do how he says".

You have two options:

  • You can either get a buy-in from your team, which means at least the majority should be on your side on this issue. And not by not complaining, but by actively voicing their support for this change. Then the team changed how the team is going to organize and nobody can be mad at you. You did not have anything to do with it.

  • You could also make clear what you expect from your team. Maybe less bugs or another quantifiable quality measurement? Voice your expectations and let them come to conclusions how to get there.

Matter of fact you have a third option: stop pretending it's Scrum and return to command and control. Because that seems to be your current behavior. Sure it's sugar coated and you listen to them, but if you don't value their opinion, you might as well stop pretending.

nvoigt
  • 138,739
  • 73
  • 318
  • 416
  • I wrote the entire situation elaborated if anything changes from your opinions. – TechCrunch Jun 08 '16 at 16:31
  • 2
    Your team should consist of equal members. You don't seem to be anyone's equal and discussing things with 4 people first would not feel very equal to me as an offshore member either. I will stick with my answer and say either you do a better job doing Scrum, or you ditch it. But telling people they are on a Scrum team and then not handling them like a part of the team is bound to fail. You are seeing signs of it already. – nvoigt Jun 08 '16 at 16:44
  • 1
    But let me say this: yes you have problems with quality and I can see from your reasoning that you need a solution. Maybe yours would even work. But Scrum is build on the fact that the PO says what is to be done and the team figures out how it can be done. So if you want to be the PO in the absence of the PO, tell them what you want (less bugs?) and let them decide how they want to do it. – nvoigt Jun 08 '16 at 16:46
7

We have small scrum team of 8 members. I'm currently managing the scrum team w.r.t work and assignments though I'm not technically not the manager of the team.

These two sentences don't align. If you are doing scrum, then there shouldn't be any assignment of work. Team members should be picking up stories as they go. Ideally they should be capable of handling any story and try to work on a variety of stories to maintain as broad a skill-set as needed.

If there is a need for more/better QA, you should discuss this with the product owner and the scrum team to decide how the group wants to solve the problem. If you are in some sort of technical leadership role (which it sounds like), then it is fine for you to bring this need to team, but the team needs to decide how to handle it.

With respect to the current unhappiness, this is something that should be handled in the retrospective discussion so that the team can decide how to proceed in future sprints.

Update post question edit:

Discussing with half of the scrum team (the onsite half) is not how this should work and you have likely alienated the off-shore half. In the scrum model, all non-PO team members should be equals in discussing how the team should operate. You have just told the 4 offsite workers that they are not equal.

cdkMoose
  • 17,840
  • 5
  • 49
  • 73
  • 1
    I understand all the members should be included in discussions. But the only reason is because of the lack of overlapping work hours to conduct such meetings. – TechCrunch Jun 08 '16 at 18:52
  • 2
    That is one of the hard parts of doing a distributed scrum team, but at the end of the day, this type of change needs to be the will of the team if you are going to be true to the scrum. It's not really scrum if you can't find regular times for the entire team to meet. – cdkMoose Jun 08 '16 at 19:03
4

There are details which you're either leaving out or glossing over which will deeply impact how the situation should be approached.

I'll discuss each point and some questions that come to mind:

  1. You tell us that you're not the manager, yet are enforcing changes.

Are these changes being implemented with the support and consent of the team, or based on your say-so / authority?

If you, while not officially being their boss, suddenly want to impose major changes it's only natural that some people will react poorly to your display of authority.

In other words depending on your position within the team and how you went about announcing these changes might be what caused the friction.

  1. You are taking steps to impose fairly fundamental changes. This right away raises two important questions. Are they necessary, and does the team understand/agree that they are necessary?

If sub-par code is being delivered by some of the team members and this is your solution then this person might feel like he's paying for someone else's mistake.

Did you communicate your reasoning and motivations for wanting to adopt these changes? Did your fellow team mates get a chance to give you some input, or speak their minds? Was there any sort of debate about the situation?

You don't mention how you handled all of the above, so it's very difficult to ascertain what the team might actually be feeling right now. However, I suggest that you take this person's reticence as a sign that others may have misgivings as well.

Make a team-wide statement explaining your reasoning (if you haven't already) and address their concerns.

  1. Is this guy generally a trouble maker, or is his dissent coming as a complete surprise?

If this person is generally a poor team mate then you shouldn't worry too much about his attitude - some people are never going to be happy no matter what you do. You may wish to speak to him and simply set him straight.

However, if he generally goes along with the team decisions and is only now expressing concerns then most likely something about your approach set him off. This is more delicate situation. You should approach him, get some feedback, and address his concerns.

AndreiROM
  • 49,631
  • 26
  • 124
  • 186
  • I wrote the entire situation elaborated if anything changes from your opinions. – TechCrunch Jun 08 '16 at 16:32
  • For 3, he generally expresses his voice loud on issues and we do have arguments about design issues etc but we eventually come into an agreement. But he is not a trouble maker. He is good at what he does. I am feeling bad he will never speak up again or give ideas for what I did today ? – TechCrunch Jun 08 '16 at 16:39
3

I guess this team member is mad at me now. I just felt like that, there were no explicit signs, but based on the way he spoke. How to handle such situations ?

You handle it by letting him be mad, but still hold him accountable for his deliverables.

You aren't their boss. You aren't their babysitter. You aren't their HR rep. You aren't their career counselor.

Instead you are the Scrum Master (or are otherwise managing this scrum team).

You do your job of running the team, and require that he do his job.

Joe Strazzere
  • 382,456
  • 185
  • 1,077
  • 1,492