Csdrhrt

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.

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

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.

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.

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.

You don_t have a programmer - you have someone incompetent for the job, to start with. Replace programming with cooking and then ask whether a cook - one working in that profession - would have problems with complex stuff like making pasta. SQL functions ARE basic. Not saying most programmers re not competent, particularly if they work for a manager with limited skillset - they may even get into senior positions then.

Second, you have a really not too good development cycle. Wednesday release is not bad, but there should be cut offs, different test environments etc. - and what does not make it, goes into the next release.

Third, you miss a fundamental of SCRUM - people have to be consistent with their estimates, NOT RIGHT. You THEN adjust speed based on how good or bad the estimates are. I.e. maybe they get only 10 hours done per week - but that is it. You do NOT change estimates because PEOPLE ARE BAD AT ESTIMATING. If we have learned anything about IT projects in the last 80 years or so - you can not properly estimate them, estimates always shoot low.

That said, the fact that you DO use a waterfall process is a VERY strong indication you have NOT learned anything about IT projects in the last 80 years. They generally do NOT work - unless you have

• very specific requirements


• very specific deadlines



• spend a lot on planning




• have very strong legal requirements that are ok with wasting a ton of money on overheads (which i.e. governments love)

None of that is normally true in business, and the whole idea of modern software development is NOT to do waterfall.

And again, from what you say, she is not a programmer. She is - a beginner lacking the fundamental basics. Deal with it, or replace her with someone competent. Given she is the only programmer, there is no one to mentor her. Not good.