Iyfjky

Question

I am currently running a team that includes a developer. He is quite talented but the problem that he has is that when he gets stuck on a problem for a long period of time he simply loses interest when solving it and wants to move onto other tasks.

Often telling me that 'Oh it can't be solved' followed by 'I don't know how long it will take to be solved'.

It is only after getting the product owner involved he then does the work, but the fact that I need to get product owner involved is making me insecure.

What can I do to encourage one of my team to work through difficult tasks with out having to resort to "taddling" to management?

@JoeStrazzere yes I have told him that he needs to stop giving up easily, but he gets annoyed and then does the work. He ends up completing the work eventually, but I have to hear a bunch of complaints before he does it. — Aug 11 '16 at 10:55
Note that it's not the Scrum Master's job to ensure that the team are completing work in a timely manner. It's the team's own job to do that. Some formal scrum training sounds like a good idea. — Aug 11 '16 at 11:43
I'm voting to close this question as off-topic because it's is either an elementary "how do I manage someone?" question or something specific to SCRUM in which case it belongs on Project Management (possible candidate for migration) — Aug 11 '16 at 12:12
@Lilienthal - I do not have a problem that is this is an "Elementrary" management question. Not everyone has management skills. This has a narrow enough focus that we should be able to address this. As someone that is a team leader and has been for a while I would still be interested in seeing the solutions our experts provide. — Aug 11 '16 at 15:23

Loofer 408512 · Answer 1 · 2016-08-11 14:40:00Z

As a Scrum master, it's not your job to manage the developer. It's not your job to get the product owner (PO) involved either. It's your PO's job to keep an eye on what his team is doing and it's your job to make sure they are keeping to the process of Scrum.

Your developer is completely right to not discuss the details of working on the ticket with you. You are not the person that assigns him work or judges if or how well the work is done. The Scrum master is not the assistant-PO.

However, if your developer just does another story, he has to communicate that to the team. It's the team's job to see who does what and it's the team's job to make sure all stories get done.

The team might decide that this story is larger than expected and consult the PO. The team may decide that there is an external impediment (no test environment for example) and delegate that to the Scrum master to solve. The team may decide that somebody else from the team will help the developer because some things are hard to see with a single pair of eyes. Maybe they will not finish their sprint goal. It's then time to discuss this in the retrospective.

Again: In Scrum it's neither the Scrum masters nor the POs job to tell a team member to do a certain story or how to do a certain story. Self-organizing team means the team organizes how stories are done. If that does not work, leave it to the team to come up with a solution.

A general part: don't think Scrum is all touchy-feely-warm-fluffy stuff just because there's no project manager of old. Don't underestimate peer pressure. If he doesn't fix the bug, the team will need to do the task. And they won't be happy about it either. But you need to actually do Scrum. As always it seems you have given it all a Scrum paint job, having SM and PO and Team, but you are not acting like it. You are still "his boss" and "managing him". That's not Scrum and it will not work this way. Scrum only works if you actually do Scrum. Giving out titles and doing it old-school is not going to work.

That is all great, but people need to be accountable for their work and product high quality of work, if he didn't listen to us and just did greenfield development tech debt would have potentially ended up increasing. It has turned out since doing the work we have told him to look into, it has opened a can of worms where there are many business critical bugs that need to be resolved. FYI I don't strictly manage the dev, at best I guide him and we tend to discuss this over with the whole team before he commits. — Aug 11 '16 at 11:40
So what happens with the bug when he does not fix it? Does somebody else pick up his work or does the team miss their sprint goal? — Aug 11 '16 at 11:41
We are doing kanban right now, he finished and met his sprint goal yesterday. We have a system in place where we have sprints for only high priority work (to ensure that they are done). The sprint is typically 4 days, and then switch to kanban for the rest of the week. We have found that this works really well since we are then able to adapt to situations like this quickly rather then waiting till the following the week and adding it into the sprint backlog. If during the sprint an emergency situation happens, then the sprint backlog needs to be changed after talking to the development team. — Aug 11 '16 at 11:44
What exactly did you mean by his sprint goal? Don't you get commitments for the whole team? — Aug 11 '16 at 11:52
@bobo2000 - 'people need to be accountable for their work and product high quality of work' - yes that's what the team is for, the TEAM are self managing and have collective ownership, so they should be pushing for the bug to be done and the code to be of required quality, not the Scrum Master (especially as Kanban doesn't have a SM role anyway) — Aug 11 '16 at 13:43

jimm101 11.6k72753 · Answer 2 · 2016-08-11 11:30:33Z

Not everyone adheres to the same principles with scrum, particularly in small shops where people wear multiple hats. So it's not entirely unusual to manage this situation yourself.

Piling more features on bugs will drive your technical debt through the roof. The bugs won't get easier to find or fix by adding more features.

If these bugs are caught early in the development cycle, don't categorize them as bugs, but reject the items that he's completed as incomplete.

It's likely you need to increase your tests, and certainly your test coverage. An investment of a sprint or two toward unit and system tests will increase code quality. You'll also give yourself easier ways to replicate the issues, and more confidence in code areas that could potentially be causing the bug, but aren't. This will all conspire to narrow the the scope and time required to fix bugs. You can also add code review if you haven't already.

It's also possible upper management is giving a different message. Features sell products and upgrades; bugs are enragers--statistically csustomers don't say they value bug-free code in surveys, and usually don't deeply evaluate code quality prior to buying. If so, that's the main enabler. If not, a single, unambiguous edict from above will help. Asking upper management to basically demand that all bugs are fixed before new features are added will take you off the bad-guy-I-can-ignore list. Asking upper management for that would reframe the issue for him.

He doesn't like eating vegetables. He needs to eat his vegetables. :-)

score 1 · Answer 3 · 2016-08-11 14:07:19Z

"Short answer?" Delicately!

Although you are not this person's manager, in an HR sense of the word, you are the leader of your particular team. (Whether or not terminology such as "scrum" is used. No matter what, if any, "management philosophy" is used ...) You act with delegated authority.

Therefore, after privately discussing your strategy with the manager and listening carefully to his/her instructions or suggestions, speak privately (but, directly) with the developer. Remind him or her that your expectation is that s/he will stick to a task until it is completed, but also that s/he is expected to ask for help, assistance, and guidance. That such requests should be directed to you, and that you will accept them. That you consider part of your job to be to remove any impediment that is standing in his/her way.

Without being threatening in any way, try to help this person understand that "the team needs the team," and that his/her appropriate participation in these matters is, indeed, required. As team leader, and within the scope of the team that you are leading, you do have the prerogative and the (delegated) responsibility to say such things.

Having first taken the time to discuss your plan with the manager, you will now have the support of that manager. "Yes, Jim or Jane, I am aware that bobo2000 was going to tell you this, because he first discussed it with me. He was and is effectively 'speaking for me,' and I am your manager."

Also: Â be ready "at the drop of a hat" to stop and listen to this person. Why might this person be shying away from difficult tasks? The comment that "it's not fun" (or, what have you) might be a smoke-screen. Can you draw-out this person's candid view on the situation? Programmers sometimes conceal their perceived weaknesses, and they might well perceive weakness where and when you don't. Try very hard to make this a private(!), and two-way, conversation.

Practice your very-best tact, diplomacy, powers of persuasion, and ... decisiveness. Yes, you have authority. Yes, you do. But what you really want to achieve is: (a) to better understand the true situation from this person's point-of-view, and (b) to persuade this person to want to change for the better.

One fellow once put it this way: "Offer him butter and honey on a slice of bread. When he accepts, take out your sword and use it to butter the bread. He will take and appreciate the honey, and he will not fail also to notice that you bear a sword."

At the end of the meeting, and after letting the person have the last word, shake hands, walk out of that private room, and leave everything that was said inside that room, "inside that room."

score 1 · Answer 4 · 2016-08-14 08:17:39Z

There are sometimes bugs that are very hard to find for one specific person. I've seen bugs that only crept up if your hard drive had a certain name. Or only in the evening. Or only on one day of the year. That happens.

It seems you have bugs that are hard to find and fix, but not impossible. He gives up, your boss tells him off, then he continues work and does it (if I understand you right). The bit where your boss has to get involved to make him continue to work on the problem is frankly unacceptable. You involving the boss is also something that your boss is unlikely to be happy with.

You can make a managerial decision that a bug doesn't get fixed, if there are more important bugs that are easier to fix. But if that bug needs fixing, it either is given to someone else (and if that person fixes it, it's a huge black mark against the first person unless there are some unusual circumstances), or you tell him to continue, and he continues. If he doesn't, that's not your bosses problem, but a HR problem.

Just to clarify: If the developer says "it can't be fixed", and the manager thinks it is important to fix and hands it to someone else who fixes it, that would likely be remembered (written down) and brought up at the next performance review. If the developer says "it can't be fixed" and gives you a reason why, and the next developer that you ask says "it can't be fixed" with the same reasons, that's an altogether different situation.

PS. I noticed you edited the title to "as a scrum master". Being a scrum master is one role that you play. It's about organizing scrums, making sure that tasks are well spec'd and go into a sprint, keeping track of progress etc. The quality of the developers is not the task of the scrum master. Purely from the view of the scrum master, if he doesn't finish a task, then it is unfinished unless someone else picks it up.

However, there are two different roles in a company that would be responsible: One would be a mentor or senior developer tasked to help others to do their job properly, and one would a the developer's manager who will see how much or little that person contributes to the company. You might be in one of these roles as well.

Meh, I personally doubt that this has anything to do with the difficulty in bug-fixing and everything to do with the fact that new features are more "exciting" to work on than tracking down bugs. Bug fixing can be a source of enjoyment for many devs, but I have all too often run across the type of dev who would much rather be green fielding their work than bug hunting, which in itself is fine, its when they then try every excuse in the book to get out of bug fixing that it becomes an issue. — Aug 11 '16 at 10:56
Thanks of this, when the 'developer' says 'it can't be solved', how do you respond? And Moo, you are spot on. — Aug 11 '16 at 10:58
@bobo2000 you respond : 99% of the time the problem is between the chair and the keyboard.. Every developers knows that one, but they might need someone to remember it sometime :) — Aug 11 '16 at 13:14
I would also point out that expertise differs between different members of a team, something can be extremely tough for one person to find and easy for another, for instance because he's seen it before. He should be taught that when he says "it can't be fixed" he should really say "I have spent time on this and I haven't been able to fix this yet -- I need to involve another team member". — Aug 11 '16 at 14:00
When I worked in a Scrum situation, the sprint was always about how many new features could be added, not about how many bugs could be fixed. If the developer is being held accountable for only new features, could that cause him to try to meet the sprint goals and ignore things outside the sprint goals? — Aug 11 '16 at 15:11

rickjr82 112 · Answer 5 · 2016-10-28 16:48:41Z

I would want any of my developers to feel accountable for quality.

Does this developer have any contact with users of the product?
- It might help him to start seeing your users as people and not just some other group hassling him. I would want people to see a quality product and to be happy with it.

Does the team have internal accountability?
- Can you assign multiple developers to work together to address difficult problems? It's usually harder to ignore a peer than ignore a work ticket

Loofer 408512 · Answer 6 · 2016-08-11 14:40:00Z

As a Scrum master, it's not your job to manage the developer. It's not your job to get the product owner (PO) involved either. It's your PO's job to keep an eye on what his team is doing and it's your job to make sure they are keeping to the process of Scrum.

Your developer is completely right to not discuss the details of working on the ticket with you. You are not the person that assigns him work or judges if or how well the work is done. The Scrum master is not the assistant-PO.

However, if your developer just does another story, he has to communicate that to the team. It's the team's job to see who does what and it's the team's job to make sure all stories get done.

The team might decide that this story is larger than expected and consult the PO. The team may decide that there is an external impediment (no test environment for example) and delegate that to the Scrum master to solve. The team may decide that somebody else from the team will help the developer because some things are hard to see with a single pair of eyes. Maybe they will not finish their sprint goal. It's then time to discuss this in the retrospective.

Again: In Scrum it's neither the Scrum masters nor the POs job to tell a team member to do a certain story or how to do a certain story. Self-organizing team means the team organizes how stories are done. If that does not work, leave it to the team to come up with a solution.

A general part: don't think Scrum is all touchy-feely-warm-fluffy stuff just because there's no project manager of old. Don't underestimate peer pressure. If he doesn't fix the bug, the team will need to do the task. And they won't be happy about it either. But you need to actually do Scrum. As always it seems you have given it all a Scrum paint job, having SM and PO and Team, but you are not acting like it. You are still "his boss" and "managing him". That's not Scrum and it will not work this way. Scrum only works if you actually do Scrum. Giving out titles and doing it old-school is not going to work.

That is all great, but people need to be accountable for their work and product high quality of work, if he didn't listen to us and just did greenfield development tech debt would have potentially ended up increasing. It has turned out since doing the work we have told him to look into, it has opened a can of worms where there are many business critical bugs that need to be resolved. FYI I don't strictly manage the dev, at best I guide him and we tend to discuss this over with the whole team before he commits. — Aug 11 '16 at 11:40
So what happens with the bug when he does not fix it? Does somebody else pick up his work or does the team miss their sprint goal? — Aug 11 '16 at 11:41
We are doing kanban right now, he finished and met his sprint goal yesterday. We have a system in place where we have sprints for only high priority work (to ensure that they are done). The sprint is typically 4 days, and then switch to kanban for the rest of the week. We have found that this works really well since we are then able to adapt to situations like this quickly rather then waiting till the following the week and adding it into the sprint backlog. If during the sprint an emergency situation happens, then the sprint backlog needs to be changed after talking to the development team. — Aug 11 '16 at 11:44
What exactly did you mean by his sprint goal? Don't you get commitments for the whole team? — Aug 11 '16 at 11:52
@bobo2000 - 'people need to be accountable for their work and product high quality of work' - yes that's what the team is for, the TEAM are self managing and have collective ownership, so they should be pushing for the bug to be done and the code to be of required quality, not the Scrum Master (especially as Kanban doesn't have a SM role anyway) — Aug 11 '16 at 13:43

jimm101 11.6k72753 · Answer 7 · 2016-08-11 11:30:33Z

Not everyone adheres to the same principles with scrum, particularly in small shops where people wear multiple hats. So it's not entirely unusual to manage this situation yourself.

Piling more features on bugs will drive your technical debt through the roof. The bugs won't get easier to find or fix by adding more features.

If these bugs are caught early in the development cycle, don't categorize them as bugs, but reject the items that he's completed as incomplete.

It's likely you need to increase your tests, and certainly your test coverage. An investment of a sprint or two toward unit and system tests will increase code quality. You'll also give yourself easier ways to replicate the issues, and more confidence in code areas that could potentially be causing the bug, but aren't. This will all conspire to narrow the the scope and time required to fix bugs. You can also add code review if you haven't already.

It's also possible upper management is giving a different message. Features sell products and upgrades; bugs are enragers--statistically csustomers don't say they value bug-free code in surveys, and usually don't deeply evaluate code quality prior to buying. If so, that's the main enabler. If not, a single, unambiguous edict from above will help. Asking upper management to basically demand that all bugs are fixed before new features are added will take you off the bad-guy-I-can-ignore list. Asking upper management for that would reframe the issue for him.

He doesn't like eating vegetables. He needs to eat his vegetables. :-)

score 1 · Answer 8 · 2016-08-11 14:07:19Z