There are laws and politics and other shenanigans going on at the mid-management level. Kind of makes you want to stay away from management positions. Check out what one cranky system administer turned manager has to say about the subject.
I am surprised that the estimates are actually pretty reasonable and reliable. After all, the guys who do the work create the estimates. I think there is a problem on how the estimates are being used. If an estimate for a change comes out to 80 hours, you cannot schedule the thing to be done in two calendar weeks.
Nobody works eight hours a day on a change. There are interruptions and other activities going on. I would hope that management 101 dictates that you use some percentage of your resources' time to estimate progress toward using up the hours from an estimate. Ha. Maybe nobody else heard of this novel idea.
Currently we are adding the tracking of actual hours worked. We track how many hours we spend each day on which tasks. That will give us a clear realistic picture of how many hours of the workday are spent on the changes we produce. You would think that with this information, plus accurate estimates, one could reliably predict our project schedule.
Then again, I may be expecting too much.
So I visually mapped out my pieces of the system on a white board. Then I graphically showed what I thought I needed to complete. There was still a long way to go. I showed the project manager. He said we would somehow make up the slips. LOLWUT? I did not care too much because I was having fun writing all this new code.
Eventually you need to pay the piper. When the date for delivery came and passed, we were still nowhere near a state to ship. We got the order to halt that project not too long after that. They brought in outside teams to assess the situation. They switched out to some outside teams to do more management. I jumped ship shortly after that.
The only real thing that caught me off guard was out project manager acting surprised when we missed the delivery. There was no way we could deliver given our rate of progress. This was evident to me. And I was a noob. Perhaps this was all part of some elaborate show. All I know is when I see management tendencies like this, I know utter failure is near at hand.
Next you should offer a bonus to those who finish their tasks ahead of time. There should be some incentive to stay on task when you are physically away.
I hear that you should also have a short talk on a daily basis. This is like the daily team standup meeting. Personally I hate these. They seem like a waste of time. I find that they usually are never short.
Require your developers to have a predictable work schedule. Even if they are at home in their pajamas, they should still be working regular hours. Finally put some short milestones in the schedule. This also applies to local workers. It allows you to detect problems as early as possible.
We were looking to hire some developers about a year ago. We went through a lot of candidates. It was important to get the right fit. There is so much domain knowledge to pick up on the job. Therefore we don’t have time for people to pick up the tech knowledge as well. You got to know our technologies already.
During our interviewing process, a manager from another group approached our big boss. He had a dev that was working for the company but did not have a project. From one big boss to another, there was a request to put this guy on our project. I was asked whether the guy could make any contributions.
This guy’s resume was not a good fit. However I determined we could have him do some work. One would think some work it better than nothing. Big mistake. It turns out the guy was not happy with the transfer. He did not like our project. He wanted to improve his career by learning hot skills. Our project is filled with legacy technologies.
Fast forward one year. This new guy we acquired on our team is just not working out. He can’t or won’t complete any of his tasks. We are constantly reassigning his work to other developers because it needs to get done. Last week was the final straw. We were late on a delivery because his part was not done. So we split his remaining work. After everyone else finished up, the guy could not even complete his lessened workload.
I told my manager that we need to deal with this situation now. It was affecting morale. I myself was tired of doing my own hectic job as well as doing some of the lackey’s work. Plus I was getting extra tasks to plan how we could deal with his inadequacies. All of this could have been prevented by sticking to our guns and demanding we have a good fit before we hire anybody new on the team.
Here is some more guidance that we do not practice on our system. You should put the documentation right into the code. I am not sure if that is the same as saying your source code is the documentation, or whether you should add a lot of comments.
Do you want high developer productivity? Then focus on quality. In fact, quality is the single biggest factor which determines whether the team shall succeed.
P.S. Do nightly builds. It will increase your quality.
Here is a crime. Managers often think their best staff members are too valuable to simply write code. That's nonsense. Yeah you might have a guy that does a lot of design. But they will get stale if they do not have hands on practice.
Beware when developers fix bugs under duress. The result will be more new bugs. To prevent problems in the first place, you should do a test on your specification.
When you are marching towards a deadline, you will almost never be able to make up day by day slippage. So how can you keep on track? You need developers with hustle. That means they just don't try hard. They try harder than needed. I want people like that on my own team.