As Scrum Master, how do I stop a team member from giving up too easily?

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?

Answer 1

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.

Answer 2

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. :-)

Answer 3

"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."

Answer 4

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.

Answer 5

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

1. 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.
2. 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