3

Follow up question from here:

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

One of my developers is having trouble estimating his work. For the past few weeks he has committed to work, and once stuck in is not able to complete it. Burn down charts then goes out of whack.

My other developer in the team is also concerned that he is not performing.

Approaches I have taken so far:

  • Using daily stand ups to deal with the impediment. I have been giving the slow developer tips; get the easy tasks out of the way then do the hard ones.

I have even explicitly asked him on 2 -3 occasions if he will complete the task in time. His attitude has been 'yeah I will do', but then on the day tell me he can't complete it.

  • I have asked the developer if he needs the other resource to step in and help him. He would always say no.

I am now starting to run out of ideas on how to deal with the slow developer. I am starting to think that he does not care about respecting the burn down charts, and is carrying the attitude that it will be done, when it is done.

EDIT:

I am encouraging the team to become more cross functional. In this instance that would not have helped anyway, because the task in question has to be completed by the person who started it. Otherwise we will have too many cooks spoiling the broth.

I have also educated the developer about the business objectives, and the team velocity is what is being tracked etc Developers agree that this is the right way to deliver work, fast developer is thriving, slow one isn't.

  • 5
    -1 You've been told about how velocity, commitments and shared responsibilities works before. What wasn't clear about the last answers? – Nathan Cooper Mar 9 '17 at 21:06
  • 2
    get the easy tasks out of the way then do the hard ones. Do you really think that is a good idea? Personally, I start the hard tasks early and use the easy tasks to "take a break" when I start getting stuck and am waiting on others to help. At least some of your tips are probably causing more harm than good for the team. – Thomas Owens Mar 10 '17 at 15:09
  • 1
    Is it a matter of getting stuck on a problem and spending too much time on it instead of getting help? – JeffO Mar 14 '17 at 21:08
  • 1
    the task in question has to be completed by the person who started it. Why? On the contrary, swarming on a problem is totally fine, and in this instance, getting two team members to colab together can a) highlight reasons why your guy isn't up to speed, b) allows him to learn and c) improves overall quality in most cases. In this instance that would not have helped anyway: did you try? Or are you able to see into the future? Otherwise we will have too many cooks spoiling the broth. Devs peer program for a reason. You seem to be 100% convinced on quite a few things that you have incorrect – dKen Mar 18 '17 at 6:00
  • 1
    @bobo2000 I was just thinking you talk like you've got all angles of Agile and PM 100% covered, and then I realised you haven't used a question mark (see: haven't asked anyone a direct question). You seem just to talk directly to people, instead of asking for solutions, or even listening. Everything is an argument to support what you think you know. Everything has an excuse, everything is everyone else's fault. The more I hear you talk and argue with those trying to help here, the more I think the problem lies closer to home and that's where you should look to start solving these problems. – dKen Mar 21 '17 at 6:13
9

TLDR: Implement shared ownership of work.

One of my developers is having trouble estimating his work.

In Scrum, there is no such thing as a single developer's work at the time of estimation. Ideally, such a concept shouldn't exist ever, with proper use of the concepts of shared ownership, pair programming, etc.

The Team owns work, and the Team estimates work. Together.

So your problem is not helping a developer estimate better. Your problem is helping the Team estimate better.

The first step towards that goal should probably be to make sure the Team is actually estimating together, as a group.

I have even explicitly asked him on 2 -3 occasions if he will complete the task in time. His attitude has been 'yeah I will do', but then on the day tell me he can't complete it.

I've come across this phenomenon a few times, and a few different things can cause it.

  • The developer is afraid of being punished for not completing things on time, so they try to hide the fact that they're behind, instead just hoping they'll figure something out and the problem will go away.
    • Proposed Solution: Make sure everyone understands that the Team succeeds or fails as a whole, and that no one person will be held accountable for any specific instance of failure.
  • The developer only cares about solving the problem right now, they don't care about schedules or conflicts or critical paths or any other of some such 'nonsense'. So they say whatever they can to make the PM go away so they can get back to 'real work'.
    • Proposed Solution: Educate the developer as to the business costs resulting from incorrect or insufficient estimation or information.
  • The developer just simply dislikes/is bad at estimation, and so tries to avoid it as much as possible.
    • Proposed Solution: Estimating as a team should help via social influences. Combine with training or picking up of systems designed to make estimation easier, such as estimating in story points (relative work) instead of days.

You'll need to talk to the developer to determine precisely why he is avoiding proper estimation, and react accordingly. People always have their reasons for what they do. Often they're good ones.

I have asked the developer if he needs the other resource to step in and help him.

The wording you are using here seems kind of condescending to me. "Hey, I notice you're having trouble completing your work. Do you want Mr. Senior to come in and save you?" It wouldn't surprise me if he refuses, either out of annoyance or fear that he will look incompetent for accepting help on work that 'belongs to him.' Again, the solution would be to remove single-person-ownership of work. Then, the Senior isn't 'helping' with 'his work'. The Senior is just 'doing work normally.' There wouldn't even be a need to ask.

  • I am encouraging the team to become more cross functional. In this instance that would not have helped anyway, because the task in question has to be completed by the person who started it. Otherwise we will have too many cooks spoiling the broth. I have also educated the developer about the business objectives, team velocity etc he nods his head, but then in practice is slow. – bobo2000 Mar 10 '17 at 10:13
  • 2
    If you ask a fish to climb a tree you will also find it slow. – Venture2099 Mar 10 '17 at 12:52
  • 1
    Sounds like a perfect case for pair programming – SpoonerNZ Mar 28 '17 at 11:48
3

Do team estimations and swarm userstories:

The idea is that you get all the developers to work (swarm) on a single story, instead of having each developer working on a separate story. The goal is to get more stories fully completed. It's better to have 80% of the features 100% done, instead of having 100% of the features 80% done.

https://www.infoq.com/news/2013/02/swarming-agile-teams-deliver

Let the Team find solutions to the problem during the retrospective. Instead of you finding solutions to what you think are problems.

Ownership:

Otherwise we will have too many cooks spoiling the broth.

To many cooks? It's a team, they are the cooks. Teach the team something about collective code ownership as an Agile principle.

Collective Ownership encourages everyone to contribute new ideas to all segments of the project.

http://www.extremeprogramming.org/rules/collective.html

Other read about code ownership is this: https://martinfowler.com/bliki/CodeOwnership.html

Process:

he does not care about respecting the burn down charts

As a Scrum Master I do not care about the burn down, it is just a signal that we are behind. A trigger to discuss how we can resolve it, not to push the developers todo more. That will only result into sloppy and buggy work.

You describe as if the developer should go faster, because of the burn down. This will lead to death marches and against the sustainable peace Agile promotes.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

If you start pushing, this developer will not make the constant pace. Development goes as fast as it goes. It is done when it's done. Some are faster than others accept it. Unless the developer is deliberately slowing down and slacking what do you expect to do about it? Demotivate him even more by publicly pointing it out at the Daily Scrum?

Easy last:

get the easy tasks out of the way then do the hard ones

This also seems counter intuitive. The hard tasks have the highest uncertainty and thus risks. You should focus on those first. The earlier you know possible problems or slowdowns the better.

The easy tasks are easy, so you can postpone them to last without to much risks.

  • Unless that single story has a lot of individual components, it does not work well and leads to confusion about who has done what and how they've coded it to begin with. It also means that other stories are not completed because the resources are blocked with the one story. My developers have been complaining about this. – bobo2000 Mar 10 '17 at 13:46
  • Really? They should do better architecture and design discussions/workshop before each story. (less.works/less/technical-excellence/architecture-design.html) Practises splitting up stories more so they can work in parallel. – Niels van Reijmersdal Mar 10 '17 at 14:44
  • My current team on average splits up a even a one day user story into 8-10 separate technical tasks. They visualize who has started and what is done on the physical Scrumboard with Name-letters and checkmarks (for coding-done, reviewed, unit-tested and refactored). Instead of giving up I would get the team to find solutions to why it is not working, how can they remove confusion while keeping in sync continuously. – Niels van Reijmersdal Mar 10 '17 at 14:44
  • Not all stories can be split up further then they already have. If I had a story which was ' As a user, I want my button to change colour when I hover over it, so that it changes colour' I can't split that up any further then it is. But it is still a single task in itself. – bobo2000 Mar 10 '17 at 15:54
  • 1
    I would expect 1% of the tasks be like that, unless someone is micro managing requirements. Still this is atleast two separate tasks, you could write the automated test in parallel. – Niels van Reijmersdal Mar 10 '17 at 16:09
1

I am starting to think that he does not care about respecting the burn down charts

No-one respects burn down charts. it is just an indication of whether you are going to hit your deadline.

Estimates in scrum are supposed to be self correcting. If you underestimate on sprint 1 by 20%, increase your estimates by 20% for sprint 2.

It sounds like this developer is under pressure to put in low estimates. Perhaps they are just a bit slower than the others, but their effort still burns down the total. Take the focus off giving low estimates and aim for consistent estimates

  • During the daily stand up today, I told my developer exactly that, that if it will take longer than expected he should not give a low estimate. See how this pans out in the next few weeks. – bobo2000 Mar 10 '17 at 11:38
  • hmmm. do you not let the team estimate in the planning session? I know they are important, but deadlines and estimates shouldn't really come up in the daily stand up. – Ewan Mar 10 '17 at 11:43
  • Yes, the team are estimating during the planning session, and the sprint is organise so that the 'Must Haves' are prioritised. This week the team even started the sprint agreeing that the slow developer should do less tasks and we are still behind. I get what you are saying, but at some point work needs to be delivered in a timely manner. – bobo2000 Mar 10 '17 at 11:50
  • 1
    I don't think you do. lets say your estimates are 100% accurate. the work doesn't get done any faster. you just know when to expect its completion. Also, it sounds like you are assigning tasks to developers? you should let the developers pick up the top task as they finish the one they are working on. That way the faster workers automatically do more tasks – Ewan Mar 10 '17 at 11:55
  • 1
    if you have consistently low estimates you are actually in a very good place. because you KNOW that the estimate is low, so you can increase it before telling the customer – Ewan Mar 10 '17 at 11:56
1

Stop relying on Expert Estimation and start relying on Forecasting. Expert estimation, whether done in hours or story points, should be your last resort and only used when you have no historic data to base your estimates on. At least, according to Steve McConnel, author of Software Estimation: Desmystifying the Black Art, and I tend to agree with him.

People are notoriously bad at estimating. The average estimate is 2x too small. In order to get 90% confidence you need to quadruple the estimate. Todd Little - Agility, Uncertainty, and Software Project Estimation. I've reproduced those numbers with actual data from a real team I worked on. Let me repeat, in order to get 90% confidence in an estimate, you have to quadrupple a developer's estimate (mine included).

Thankfully, there are good ways to project historic performance into the future. Personally, I prefer to average Cycle Time and extrapolate from there. I've found it gives accurate, but not precise, results.

Cycle Time is the amount of time from the time work is began until the work is finished. I measure this in increments no smaller than whole days. Find the average cycle time for this developer's work. Once you have this, you can reasonably estimate how much work they can actually do in an iteration. Let's say this dev averages 1 card every 4 days and you have a 2 week (10 day) sprint. That means that the dev will, on average, complete 2.5 cards every sprint. The actual will likely be 2 or 3, but will be much more accurate than your current estimates, which are obviously off enough to cause both of you some serious distress.

Now, keep this average in mind during planning. Don't expect the dev to complete any more than their average. Stop planning for more work than your dev can accomplish. If the developer says he can do more than his average, gently remind him of what the numbers say and that you'd rather him be successful and finish early than commit to getting more done than the team can actually accomplish.

Remember, if you plan for more work than your dev team can do, that's your fault. You're the project manager, not them. Also keep in mind that these are averages. He won't complete exactly 2.5 cards every sprint. Sometimes more will get done, sometimes less, but on average 2.5 cards will get done. It needs to be safe to fail. These are estimates, not commitments or deadlines. No amount of planning or estimation will be perfect. All estimates are wrong, some are useful. What matters is that working software is delivered on a frequent basis.

0

I have even explicitly asked him on 2 -3 occasions if he will complete the task in time. His attitude has been 'yeah I will do', but then on the day tell me he can't complete it.

This doesn't sound like an estimation problem to me, in the development sense of "poor at figuring out the complexity of and effort required for a task". This sounds like it could be a very generic, "poor at turning work in on time" problem.

Have you asked him, on the day, why he wasn't able to complete it? What does he say?

Have you asked him why he routinely is unable to complete the work he has committed to? What does he say?

Try asking daily for a confidence level whether he will be done on time. Ask him to give reasons for it, and emphasize that the goal is to know early that there might be a problem. Explain up front that if he is giving you 95% confidence level up until the day he doesn't turn it in on time, he'd better be able to point to an avalanche that happened since yesterday.

0

Sounds like a team problem (or maybe a scrum master's problem), not an individual developer's problem.

In any developer's team there are differences between the team members. Some people get work done very fast, others take a bit more time. The overall team velocity should guide the estimates, not the individual developer's time.

A few countermeasures:

  • Value diversity. Make sure that everyone knows their own and their teammates strengths and weaknesses (both personality-wise and with regards to skills and knowledge). Sometimes for example the fastest developer tends to be a bit sloppy when not working on challenging problems; while the slower developer does not mind doing boring tedious tasks.

  • Work on better estimates from the team as a whole, by using relative estimates instead of time estimates. (Story A was 5 story points - is story B smaller or larger?). This really increases accuracy.

  • More teamwork, more swarming, more pair programming, more collaboration.

  • It turned out he was slow because he was having trouble estimating his stories. With that said, I do think this whole concept of accepting people are of different velocities and doing nothing to change it will breed complacency and a less efficient team in the long run. – bobo2000 Mar 28 '17 at 9:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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