My programmer underestimates deadlines or is just lazy

Question

Since august, I have had a software programmer in my charge and I became the project leader of my area.

She went well with learning things about our area, configuring some tasks, but ever since I started to ask her more complex things (to be specific, complex in the sense, understand sql functions and how the back end of a application works) is when my problems got started

First of all, I think she underestimates the complexity of the tasks, then I believe she became secure and stretches her schedule doing the bare minimum until I ask her how she goes; for example she does not implement her changes in the development environment, she just goes "I'm just testing things here in my sql session" like some query's on the fly without testing the project as a whole (I assured her that she can do and test whatever she wants in development environment)

Wednesdays are the days that new releases are made, so I told her days ago to check with time her development with the entire project, not just use the Monday and Tuesday to adjust things. Today. Friday she implemented her changes and of course, in the development environment everything crashed

This is not the first time she has done this. My specific question is, with that personality should I implement a sort of specific scrum for her? We use waterfall because our projects are small; I'm thinking about sitting with her 15 minutes a day to ask her about her progress.

This is not what we're used to doing, we normally just set deadlines and set a Gantt diagram, I'm not saying every other developer is perfect but her case is very isolated. She only had that task and previously I was assured that she understood how the project works and I tried to respond to her questions as clearly as possible.

Answer 1

You might have been describing a young me. Estimating the time required for a task is a skill that takes some time to learn. When asked for an estimate, she probably thinks of how long it will take in a perfect world with no distractions and where nothing goes wrong, and maybe adds a tiny buffer to it. She then feels that she should be able to complete the task in that amount of time, and is embarassed to offer a more realistic time frame because it might make her appear incompetent or lazy. Having given her estimate, she now believes it, and thinks she has time to spare.

Next time an estimate is required from her, I would sit down with her and analyse the estimate, breaking it down into several smaller sub-tasks. For example, if she says she can add this feature by a certain date, ask her how long it will take to analyse the requirements, how long to write the tests, how long to write the code, how long to run the tests and fix any bugs. At several points, ask her if she wants to revise her estimate. Remind her that things seldom go perfectly smoothly, and that you're looking for a realistic estimate. I'd do this for the next few estimates until she starts to get the hang of things.

This approach will accomplish several things. It will show her a systematic approach to coming up with an estimate. And when one of the smaller subtasks takes longer than expected, it will make her realise that she is in danger of missing the deadline (and give you advance notice). It will help her notice patterns in her estimates.

Answer 2

First up, humans suck at task estimation time. I mean, Really Really Suck.

They did one study where they got participants to estimate how long it'd be before they were 50% sure they'd be done (aka, an average be-done-by time.) A second group was asked to do the same with a 75% certainty. And the third, a 99% certainty (aka, I'm almost positive I'll be done by this time.)

The results? Only 13% of the first group was done in time, not half. And of that 99%-certain group? Only 45% were done. Aka, people were being pessimistic, trying to give a safe conservative answer, and they STILL underestimated.

So they did a follow up, to figure out why we suck at task estimation. One group was asked to guess how long something would take. One group was asked to guess how long it would take best case, if everything went right. And one group was asked how long it would take worst case, if everything went wrong. And they found that the first two groups gave nearly identical times. Basically, people naturally plan as if everything will go perfectly. And it doesn't - it almost never does - and our estimates are bad because of it.

So, right off the bat: people naturally suck at task estimation. I'd highly suggest reading about the Planning Fallacy a bit to get some more (interesting, imho) information on the subject.

So! What can you do about it?

Door #1: Story Points

Well, Agile groups typically don't use 'Time' as an estimate for how long something will take. Why? Because, well, people suck at task estimation. The minute you ask how long something will take, it sweeps them into bad-task-estimation-mindset.

Instead, they use Story Points. Instead of estimating how long something will take, they estimate how complicated something will be. This can often help bypass people's overly-optimistic nature.

Door #2: Time Translation

There are some people that when they say something will take "4 days", you mentally have to translate to "2 weeks." Yeah, the person should hopefully get better with task estimation as things go forward, but you might have to get into the habit of figuring out the relationship between how long they say it'll take, versus how long it actually takes - and then do some mental calculation when their estimates come up.

Now, as for the Possibly-Lazy issue?

You'll have to take special care at figuring out whether it's actually laziness or if they're just not the most familiar at what you're asking them to do. There have been times that I've been in the weeds for a project, with no clear visibility on what I'm doing, what I'm supposed to be doing, and how exactly things are supposed to be done - and it sucks.

If they're in the weeds? You're either going to have to give them some slack to get things figured out, or have someone get more involved in helping them out. Pair programming can actually be a god-send in these types of situations.

And if they're just lazy? You're probably going to have to get more involved - daily task goals, or something with more rapid feedback that don't allow them to slouch for days at a time. (Again, make absolutely sure it's a laziness issue before treating it as such.)

EDIT: A link was requested - but the easiest thing is to google Planning Fallacy or go to the wikipedia page. The article itself is behind a paywall. It's: Buehler, Roger; Dale Griffin; Michael Ross (1995). "It's about time: Optimistic predictions in work and love". European Review of Social Psychology. American Psychological Association

Answer 3

Best practices in software development include some testing methodology. It can follow an official definition such as Test Driven Development or Behavior Driven Development. Or it can some personal method. What matters is an organized approach to writing software where clear, repeatable tests are an integral part in the process.

If you have a developer who doesn’t apply these best practices, he/she is either inexperienced or somehow survived in previous positions despite this issue. In any case, this approach won’t work long term.

Such a developer needs to be taught proper programming practices by a senior dev, which shouldn’t take very long. Furthermore, examine the culture in your company - are best practices encouraged/enforced? Do your devs share knowledge? Do the managers (you) understand these things and nourish a conducive environment?

As for time estimates, you need an organized approach which is beyond the scope of your question. But from the info you gave, it sounds like you are using waterfall, which may not be the best method for software development.

Answer 4

If you think it is appropriate given her experience and place in the team you can have the occasional, separate, short and informal meeting with her.

You need to be careful however not to strain her too much by your attempt to mentor her or figuring out her strengths and weaknesses.

Plus, let your team members know the priorities for their tasks.

Also, pace the complexity of assignments, especially for juniors and
reassure her that using the dev environment is not only allowed but part of the protocol (if that indeed is the case).

As you see, she struggles to manage her tasks, so help her by assigning them priorities and remind her of company procedures regarding local testing and global dev environments.

This is not to say you're at fault but anything you ask of her or mention, even if just in passing, may become a priority to a young or inexperienced (as a worker in general) employee.

They might want to impress you with their capabilities.
It is easy to forget time management, even for senior employees in that mindset.

She ends up trying to please you in all areas you mentioned and won't have a chance to succeed in any properly.

It is commendable that you want to assist in her development, it will benefit your team and her alike.

Don't classify the meetings in any way (especially not in a separate format) or she might feel singled out or pressured to prevent your impending negative impression about her performance.

Answer 5

You need to iron out procedures and expectations, then explain them to everyone.

Most importantly you then monitor and enforce them, using disciplinary action if necessary. Crashing the environment without good reason and ignoring procedures once would be grounds for a warning, more often and you would need to look at disciplining her.

You do not change procedures for a single staff member if they're fine for all the rest without risking morale issues in the team.

Do not single her out at this point though, explain the procedures and expectations to everyone. Make sure they understand it's not a suggestion, there are issues with procedure not being followed and you will be monitoring.