This should be a surprisingly easy problem to solve.

Have a second meeting with him. Tell him that you accept that it’s probably your perception of reality that is at fault. Then qualify that with “however, if that is the case then we need to work together to improve my perception.” Finally challenge him to solve that problem, so he doesn’t feel micro-managed.

This exact thing happened to me a long time ago. For me, the issue was that I dislike the possibility that anyone might think I’m seeking extra credit for simply doing my job. And that was fair enough, but there has to be a regular feedback loop between any member of staff and their line-manager.

If there isn’t then you get these problems.

Regular, planned, 1:1s are a great idea. And, as people have pointed out, standups do not need to be orthogonal to working from home. But they must involve the three questions: What did you do yesterday? What are you planning to do today? And the one most people forget … What (if anything) is holding you up?

That said, you should try to discourage situations where team members never work together. I’ve worked in that situation before and it seeded distrust within the team and outside it. Have a regular day that you all come into the office. Have a regular meeting where people can voice some ideas on improving processes or whatever.

Don’t make it a line-reporting event. Make it an opportunity to just talk. You’ll be surprised what you learn. If possible, turn that into a social event, go for a couple of drinks on work time as a bonding exercise.

There’s lots of great advice here, and I don’t want to take away from any of it, so I’m posting this as a separate answer.

First, it is evident to me (and apparently others) that you have not discovered the root of the problem. You’re staring at a symptom and trying to cure that. You need to find out what is causing so much friction between yourself and this developer. Perhaps you’re being too authoritative (my Product Owner recently described herself as having “Infinite Power” over a project and that was offensive to me, even though she laughed when she said it). Perhaps he is having severe family problems (would explain all the time out of work). There is a root problem here, and until you find it, this will not be fixed.

Good Catch!

If his performance could be better, that’s great that you’ve determined that. Remember though, that if his bad performance is still good performance by comparison, then you need to tread carefully to avoid losing a good developer. Good developers are hard to come by, and good developers require a very specific set of things. Perhaps take a look at the Joel Test to see if his needs are being met.

Find the Source of the Problem

If he is unhappy with something related to the job he’s doing, then you can only fix it by determining the source of the problem. Let me be clear, you said your programmer wrote good code. That means that he loves programming. It is more than evident that he is frustrated at work (from your description of the meeting), and you’re probably right that his performance is below where it should be, but don’t assume. Remember that many programmers just don’t have social skills.

You’re Not Perfect Either

Remember that sometimes you’re going to have personality conflicts, especially with introverts. If this turns out to be a personality conflict, consider how far you’re willing to go to gain an increase in performance (see 1)

All of That Said

I wrote a blog post about Managing Programmers. I think you should read it.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

I cannot emphasize enough the last part of that post.

If your developers are any good at all, they want to code.

Your programmer, even if he is slacking off, does not want to be slacking off. You have to find the root of this problem, and it may turn out to be something that simply cannot be fixed and he has to be let go, but whatever it is, you cannot make an informed decision without determining it.

When it feels someone is “somewhat difficult to manage” like you describe, to better understand how does one perform and whether there are issues (objective or subjective) impacting productivity of dev team members, consider establishing a practice of regular 1:1’s with your team members, as presented in an excellent article The Update, The Vent, and The Disaster:

…I’m not suggesting that every 1:1 is a tortuous affair to discover deeply hidden emergent disasters, but you do want to create a weekly place where dissatisfaction might quietly appear. A 1:1 is your chance to perform weekly preventive maintenance while also understanding the health of your team.

…The sound that surrounds successful regimen of 1:1s is silence. All of the listening, questioning, and discussion that happens during a 1:1 is managerial preventative maintenance. You’ll see when interest in a project begins to wane and take action before it becomes job dissatisfaction. You’ll hear about tension between two employees and moderate a discussion before it becomes a yelling match in a meeting. Your reward for a culture of healthy 1:1s is a distinct lack of drama.

_{A very strong point of mentioned article is that it is self-contained, in the sense that besides explaining benefits, it also provides a set of practical recommendations basically allowing one to start practicing regular 1:1’s without digging into other sources (although looking for additional information won’t hurt, you know).}

Obviously, there is a major communication issue here. He may well be doing fantastic work but if you’ve got the feeling that you don’t know what he’s up to then that by itself is an issue. And if you don’t know what he’s doing, then his coworkers probably don’t either. This can cause issues when he does check his two week old code in. Especially if there was anyone working in a similar area.

You can always suggest that he checks in/provides updates more regularly to minimise these kinds of conflicts. This could allow you to couch your request in terms of helping the team rather than “I don’t know what you’re doing”.

I know standups get a lot of hate but it doesn’t actually have to be held in the same room. A quick call or a group Skype update once a day is very quick and keeps everyone on the same page.

I’m currently working from India with a team in Ireland and I can’t imagine not being in communication with each of them on a daily basis and I either know roughly what each of they are at or I can find out very quickly.

Pointless

Daily status updates are pointless. Having people report ‘today I am 2.5% complete’, ‘today I am 3.74% complete’ is ridiculous.

It provides no value to the stakeholders, and annoys the people doing the work.

Leave them to their work, undisturbed.

Baseless

On what grounds do you suppose that developer A is ‘underperforming’? If his/her work is being done on time, that should be good enough.

You say you hate micromanaging, yet what you have described is exactly that.

Our company requires the developers to indicate the work progress in
the bug tracker we use, not so much as to monitor the programmers but
to keep the stakeholders apprised of the progress.
… Developers would require to update the tasks as they go along
everyday.

This is pointless (see above) nonsense. Your team is not flipping burgers, they are crafting technical solutions. Progress is not linear, nor is it easily measured or even estimated. Even if it was, such daily measurements or estimates have no value.

Dangerous

Reexamine the basis for your ‘feeling’ that developer A is ‘underperforming’. You think he/she could do better, but on the basis of what evidence?

Unhappy != underperforming

Continue as described, and at some point, developer A will likely decide that he/she is under-appreciated, has given enough to the company, and will find another company. Squeezing the last 0.01% of effort from employees is far less important than retaining them for the long term.

Developers might hate the effort of documenting what they do and updating statuses – but that’s part of being a professional developer. I would suggest that you could try to point out to him that his late updates of your issues log is causing an unnecessary negative perception of his work. If he doesn’t see that his failure to communicate is a performance problem – well, you’re his team leader; tell him that it is.

Regarding estimation – that’s a classic problem. I recommend reading “Software Estimation – Demystifying the black art” by Steve McConnell. In this instance, you give the impression that most of your developers under-estimate. This is, curiously, normal, and rarely addressed. I would suggest that you’ve got a problem with the estimation process itself, rather than this one individual.

Try to ‘close the loop’ of estimate-measure-review and improve. Then, if your developers are coming in on time more regularly and this one individual isn’t, you can consider what to do about him.

Finally, have the stand up meeting. Even if it’s by Instant Message. All you want is everyone to know “what I did, what I’m doing today, any issues”. And if there are issues, take them offline for discussion later. That’s what I’ve done before, and it was successful for that team.

First thing, why are your sprints that long? Sprints should never exceed two weeks. I think the majority of your problem lies there. I would recommend you to shorten the sprint time on a trial basis and then analyze your question again.

What about the code check in’s? Does he checks in his code all the time?
I personally think that programmers are not really management guys and the more you try to manage, the more they will get frustrated. In fact, I hate to do those update tasks and probably that’s why PM’s and Leads are there for. But at the same time, I do provide a status during scrum meetings or whenever we meet. Now when you do assign a task, do they commit to a timeline or is it you who assigns them the timeline?

Therefore, the only way I could tell if someone is under performing is to map the committed timeline to % of work done. Now of course, if someone says that it will take him two days to write a method that adds up two numbers, you know there is a problem so the timeline should be something realistic and agreed by both the parties.

Take it this way- If you can write a piece of code in an hour, give him an hour + some buffer. If he is delivering that to you in that amount of time, I think then you guys are just doing fine. If he is not then question him and later its up to you to decide whether he is furnishing a reasonable explanation or not.

One thing that you can do is to integrate something like XPlanner with versioning tool.

I don’t think the programming profession is inherently different from other professions when it comes to identifying someone who is slacking off. You may have to go with your gut.

I personally think it’s strange that A refuses to provide updates for weeks at a time. I am a programmer working from home, and there’s an implicit contract between me and my employer that I need to provide daily updates on my progress. These are not “official” updates, it’s just a short email or IM letting him know what’s going on with the software I’m being paid to create. The update takes less than a minute or two to write, and offers closure to both of us. For bug fixes I mark the ticket as resolved in our bug tracker by the end of the day. These are not difficult procedures for me, though I enjoy a relaxed work environment with very little paperwork.

Even casual updates would be appreciated coming from him, I’m sure. You sound very, very lenient in your post. If you’ve been suspecting that he’s slacking for an extended period of time, you don’t need another excuse to address it with him.

Daily standups even if over Skype or in a chat room are the way around this but not if you treat it as an update for the stakeholders. When once a day the whole team just checks in to say what they’ve been working on, what challenges they’re running into and what they plan on doing next, you get several wins:

• Whether you’re wasting time for good or bad reasons, that something is taking too long is going to be more transparent, encouraging your devs to ask for help when they need it and not go overboard on research that probably didn’t need to happen or solving a problem for the challenge of it when input from the rest of the team would help them knock it out a lot faster.

• You, as a manager can see where people are encountering roadblocks most frequently, which helps you estimate better and possibly resolve fundamental issues that are wasting time/money.

• IMO, it really helps the team learn to underpromise on estimates better when they can see how long it typically takes for everybody to get even relatively straightforward things done sometimes.

• You’ll often be reminded of things that need to be communicated in terms of re-prioritizing when your team members tell you what they plan on doing next.

So forget ‘% of complete.’ Just make the process about getting everybody honest with themselves as much as with everybody else, making better/more-reliable estimates as they gain more experience at it, and giving people a little more motivation to have progress to report without it turning into a mind-numbing exercise of putting a number on something that you really can’t.

It sounds like upper management understands that deadlines don’t always get hit. Doing daily standups will give you more ammo on that front because you’ll have much more specific ideas about why they aren’t getting hit.

And don’t do them first thing. Always a mistake IMO. People need time to sink their teeth back into the problem before they can more reliably report on what all the issues are, IMO.

Quick standups that are more about communication than accountability, and simply setting goals, more than anything are what make agile work in my opinion. The rest I could take or leave, especially Scrum, which I’ve come to view as executive/stakeholder snake oil.

Underperforming?

Intensity ebbs and flows during a person’s career. If he’s worth more than he costs, then talk to him and try to make his job easier. Or else start looking for a replacement.

Communication

Don’t rely on weekly meetings. Most people aren’t going to do a complete braindump. Schedule more 1:1s. Ask them how things are going, what you can do better, and what you feel they can do better. Sometimes, there will be nothing to talk about, but that’s ok. By having more 1:1’s, you increase the likelihood that they’ll remember to mention something.

Have a more persistent means of communication

You can get more information out of people if you don’t make it feel like an extra chore. If they’re all remote, have them use a chat program with logging capabilities like Hipchat or IRC. Having a more persistent means of communication encourages people to talk more. Lead by example and talk often, to encourage others to do the same. At least once a day, have people say where they’re at with their projects. Sometimes, just by looking at chat, you can get a feel for how things are progressing.

Source control

Have everyone check in their code daily. If you’re using git, have them push to their own branch on the company repo. By looking at the commits, you can tell how they’re doing.

Separate the means from the ends

The stakeholders want to be updated? Deal with the stakeholders yourself. Part of your job as manager is to be the shit umbrella, so your coders can focus on their work. Look through the chat logs and commits, then write a summary about how things are going.

These are my suggestions:

1. Innovation: Imagination and creativity used to lower costs and improve the current situation.

2. Corporation: Willingness to help others accomplish their objectives

3. Initiative: Attempting non-routine jobs and tasks.

4. Attendance: Absences or lateness, Below standards.

5. Alertness: Ability to quickly understand new information and situations

6. Accuracy and Quality: Code reviews, delivering on time, issue rate).