How to efficiently manage a Scrum team when one member is much less productive?

Question

Currently we have a team of 2 developers in a Scrum team, one is quick, the other is slow.

When the slow developer falls behind in his sprint, the quick developer does some of the remaining work. The quick developer does not mind doing the work, but has made remarks such as 'the other developer should do this it was originally delegated to him'.

I am concerned that my slow developer might be coasting it, from knowing that the quick developer will pick up some of the slack for us to meet the sprint goal. I have mentioned to the slow developer that we needs to work on increasing his velocity during the sprint. He has said 'ok', but then goes 'oh I didn't realise that the work was so complex'. So it is hard to know what exactly is going on. The quick developer has told me that the slow developer sometimes is idle, and works in spurts.

I currently track the progress of the sprint using a burndown chart which is doing a good job at it.

How can I improve the productivity of the slower developer?

EDIT:

I am managing the teams's velocity, but it is becoming apparent from daily stand-ups and the fact that I am sitting next to the two developers that one is much quicker than the other. I feel that it is unfair for the quick one if he keeps on being handed the slack since he ends up doing more work.

Answer 1

First, stop measuring individual velocity. Velocity should be measured on a team level for a Sprint, and not for individuals. Your team delivers a potentially shippable software product after even Sprint, not individuals. Since Scrum is built around self-organizing, cross-functional teams, your velocity should include everything involved in creating the delivery, from grooming the requirements through test and verification.

The next problem is a personnel management question. If you are using Scrum, the process is built on a cross-functional team. If the development team needs additional training to be sufficiently cross-functional, they should have the necessary education and training. This could be pair programming, cross-team training sessions, lunch-and-learns, external training courses, bringing in instructors. The burden is on individuals to understand what skills they need to develop and work with management to develop those skills. Management should also be doing the same - identifying gaps in skills, providing the necessary resource to close those gaps, and encouraging staff to do so.

If you have an employee who isn't performing to the needs of the business, that's a human resources management issue. It's not addressed in the Scrum framework.

Answer 2

So it is hard to know what exactly is going on. [...]

How can I improve the productivity of the slower developer?

First, check your expectations. Are they supposed to do the same work? Do they have the same title, do they get paid the same? Is one really slow on an absolute scale, or is the other one just really good?

If you had just two of the slow kind, would you still keep them? If not, what would you do instead and why don't you do it now with just one?

With that questions answered for yourself, there is little you can do from the outside. Ask your developer what problems he has. Ask him if he needs anything. Help, training, better tools, maybe another working schedule. Work with him so he gets better. If he doesn't, you need to follow up with actions according to the answers you came up with before.

All of this is not a Scrum process. It's normal management. Scrum only works with teams and your team is having problems. It consist of too few members, it measures things that should not be measured (individual velocity does not exist) and it seems 50% of your team is unhappy with the work of the other 50%. If you want to keep this "agile", you should include the questions about how to help your slower developer work more effectively in your retrospective meeting.

Answer 3

'the other developer should do this it was originally delegated to him'

Scrum works best as a pull-model, not a push-model. No work should be delegated to anyone, ever. The Team pulls work into the Sprint. The Team Members pull work from the Sprint onto their laps. Following that model, your senior dev won't be complaining that 'I shouldn't have to do this' because work is not owned until it is actually started.

At which point the only problem becomes individual velocity, which is a concern that should be handled within the Team itself.

The quick developer has told me that the slow developer sometimes is idle, and works in spurts.

Nothing wrong with this. In fact, it would be incredibly concerning if a developer were not sometimes idle. If you're always going at full-tilt nonstop, you are going to burn out badly. Likewise, working in spurts is a personal preference; there is nothing inherently wrong with it.

He has said 'ok', but then goes 'oh I didn't realise that the work was so complex'.

Assuming the developer is speaking seriously and not just trying to deflect blame (which would bring up entirely new issues such as why people are more concerned with blame than with fixing problems in the first place), then this is an issue which can and should be addressed. Potentially in a Retrospective. If tasks are being underestimated due to their unseen complexity, then a possible solution is to spend more time analyzing tasks during the Planning (or Pre-Planning, if your organization has one) meeting.

How can I improve the productivity of the slower developer?

Have you tried asking this to him? Or even better, to the Team at large? "Can any of you think of ways with which we can improve your productivity?" If you don't get anything, prompt with examples. "Pair programming? Training? New tools? Caffeine?"

Answer 4

It is commonly accepted that there is a massive variation in productivity between very good developers and average ones. Read Michael Lopp Managing Humans for a good explanation.

There are two issues:

Firstly is the slower of the two worth the money the company is paying them. If so then keep them going. Do what you can to train them and encourage their development to get better. Otherwise you need to deal with the fact that they cannot competently and productively do the job they have been employed to do.

Secondly and more importantly Ensure that your more productive developer is recognised and rewarded for his or her additional capability. If they feel resentful that their teammate is earning the same and not as productive nor working as hard then you run the risk of them feeling resentful and losing a good developer (to another employer like me who will look after them :).

All of the top developers are used to working with others who don't work as effectively as they do. It's not an issue so long as it is recognised and rewarded.

Answer 5

Quick vs slow developers, hard question. Quick doesn't mean good, quickAndDirtyTM solutions will always bite you in the back later. Slower solutions can be worth much more if they are very readable and maintainable. Slacking to think might also not be so bad, most developers only code 10% of their time. The rest they are reading and thinking.

Measuring individual developer productivity is hard, but be careful of the net negative producing programmers.

"There are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one."

http://c2.com/cgi/wikix?NetNegativeProducingProgrammer

It might be harsh, but I have seen that removing the slow programmer can speed up the team significantly.

Still I would try to see if the team can pull up their members to the same level

• Pair programming to increase codebase and programming technique knowledge
• Retrospectives specific on finding out issues that are holding some developers back. Let them try to come up with solutions.

Answer 6

When the slow developer falls behind in his sprint, the quick developer does some of the remaining work.

This is how Scrum team is supposed to work. You don't work on your stuff, your only goal is to produce potentially shippable increment of software at the end of Sprint.

The quick developer does not mind doing the work, but has made remarks such as 'the other developer should do this it was originally delegated to him'.

This statement contradicts itself, he doesn't mind yet he complains.

I am concerned that my slow developer might be coasting it, from knowing that the quick developer will pick up some of the slack for us to meet the sprint goal. I have mentioned to the slow developer that we needs to work on increasing his velocity during the sprint. He has said 'ok', but then goes 'oh I didn't realise that the work was so complex'. So it is hard to know what exactly is going on. The quick developer has told me that the slow developer sometimes is idle, and works in spurts.

This shows fundamental lack of trust between you and both team members. I don't want to defend slow guy, but that's the way it is in software: estimates are usually not met and it's just too complex to predict accurately.

Having said that... you might be in situation where you actually have slacker/under-performer on the team and Scrum and iterations don't have anything to do with it.

Let's improve developer's productivity

How can I improve the productivity of the slower developer?

You don't know why he is "slower". The question you're asking can be compared to "how can I cure sneezing?" without asking what caused it.

Your "slow" developer might be: - demotivated at his role/project/team

• lacking skillset of specific technologies

• having some personal issues (sickness/problems at home/etc)

• not be right fit for being developer (yes, it happens)

Top of my head I can think of couple more possible reasons.

Solution to your immediate performance problem

Try to approach it from two avenues. First and foremost talk with him and openly ask if he's ok as you noticed that he seems to be falling behind with the work and you don't want to guess what the reason is.

Second, if you're his manager it would be good to know what is his history in the company. How he was hired, how he ended up with his team, what is his professional experience. There are companies that are very inconsistent in hiring practices and they just hire people not qualified to be programmers, who are managed by people who have no qualifications to be managers. When you'll know more (or give us more details for that matter), you can start thinking about improving someone's performance.

You need to learn a lot

Looking at your post it seems you're beginner manager with very basic understanding of Scrum and missing all core values behind it (e.g. "I am managing the teams's velocity"). I don't mean it to be insult, but rather as knowledge assessment and opportunity to learn. If you're willing to learn - sky is the limit.

I would recommend reading Peopleware to understand what it means to be manager of software team. Then follow it by couple articles by Joel Spolsky (start with TOP10 at the bottom) and then you can follow it by book with real life applications of Scrum explained like: Agile Project Management with Scrum. After that look at Management 3.0 and get grasp of modern management.

Answer 7

You should accept that the slower developer may never reach the pace of the faster one.

You don't specify the developer's background in the post, and I can only assume that the faster one is more experienced, and/or has been longer in the project. In both cases, the "faster" guy will probably always be faster.

I still recognize this issue, and I think that you should proceed with the following recipes:

1) From your post, I got the feeling that tasks are assigned to the developers at the beginning of the sprint. In most cases this is bad practice - try to have an list of tasks to be done as a team in the sprint, not individual lists.

2) When you stop assigning tasks at the beginning of the sprint, it will become much more natural for the developers to start implementing tasks together (aka. pair programming).

Pair programming may sound scary for you; after all, you've hired two devs to be able to produce twice the value, and they suddenly start working on one task at a time. However, working together at one task at a time will really improve your velocity:

• the communication done in pair programming can make it faster
• it enforces better focus
• It is a great opportunity for the slower developer to learn, making him faster when implementing some of the tasks alone.

3) Have retrospectives after each sprint, if you aleady don't do that. "I thought it would be easier", "I didn't realize it was so complex" -reactions can be spoken out in retros, and the reason can be spoken out - and situation can be improved.

Heck, this situation may even be a result of your faster developer writing such a hard-to-read/bad code, that it is hard to work on for other developers. This kind of situation is very hard to recognize from the outside, as the slower developer may not feel comfortable to bring up the issue. Retros & more effective communication is the way to figure out these things.

Answer 8

You tagged this with #scrum and #agility, so I'll direct answers towards those two things.

This is not a process or tooling problem, it's an individuals and interactions problem. Look to what works to motivate individuals. I'd suggest reading "Drive" as a primer summary of basic motivational science over the past, half century. Here's a quick summary:

Drive by Dan Pink

As a manager, focus on any environmental impediments, incentives, cultural norms, etc that are de-motivating. I've found this model helpful when exploring impediments to motivation, effectiveness in Scrum teams, etc

Agility teaches us that individuals and their interactions are typically more valuable than processes and tools. A corollary is that a problem with an individual or their interactions will not be effectively solved with processes or tools...only mitigated.

Last, work to create a system where this individual can self-select him/herself off the team or out of the company if things are really that bad. Alternatively, you could build a system that encourages and enables high performance culture and results from the Scrum team and give that team a recourse for it's own membership. Grow trust by treating these members with respect and require responsible behavior. Dedicate yourself to practicing Scrum or some other means of establishing transparency, inspection and adaptation as a normative practice. Transparency will expose problems, inspection will determine root causes, and adaptation will produce positive change. This may of course involve the personal improvement of this individual or his/her exodus from the team or organization.