GeeCON Prague 2014*
The moose likes Jobs Discussion and the fly likes Feedback on public charts Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Careers » Jobs Discussion
Bookmark "Feedback on public charts" Watch "Feedback on public charts" New topic
Author

Feedback on public charts

Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
I had an idea for something and want to run it by people.
I am slightly concerned with the amount of effort put in by some developers. I don't think the appreciate the ugency of some products.
Undoubtedly, many of you just thought "typical management thinking." Before you judge me understand that we have a 40 hour work week with 1 hour for lunch each day. Right now we're a week away from the project deadline, it's behind schedule (this is the scaled down product) and the engineers still seem to work at a casual rate, not recognizing the importance of getting this done on time. While I believe people should be able to surf the web and take occasional long lunches, generally trustng them to be accountable for their own time, given the deadline and schedule, I'm concerned.
I believe this is a systemic problem. That is, there never have been schedules and deadlines before. They just did it and kept working on it until it was done. This project, originally estimated for 2 months, is currently 4 months overdue from when they originally planned it.
I provide all that as background to the culture. Now here's what I was thinking of.
I am using Microsoft Project to schedule and track projects. It creates a PERT/GANTT chart. I was thinking of putting this chart of the wall. Here's the part which may be controversial. Typically as tasks are completed, they are marked as such. I was originally just going to highlight them to show them as completed. Now I'm thinking of highlighting tasks in green, yellow, and red, to show tasks completed ahead of schedule, on schedule, and behind schedule.
Obviously this is useful information since it's important to know when you're ahead of and behind schedule. How would you react to the public use of color codes (it's posted where everyone can see it)? Do you think it would embarass people? Do you think it would motivate people? We've talked about the fact that we expect many estimates to be off, since most people are inexperienced, and I work with engineers and help them pad their initial estimates. It's certainly not going to be used to "shame" anyone. How does this idea sound?
--Mark
John Dale
Ranch Hand

Joined: Feb 22, 2001
Posts: 399
Perhaps it would depend whether the timelines came from the programmers, and they have the ability to adjust priorities to get the task done, or it is just another way to be beat over the head with someone else's idea of reality.
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
We sit down and they schedule their tasks in terms of priorities and time. I usually talk them into upping their time, and help them set priorities. That is, they give me a list of tasks and then I start questioning them about as I walk them through it. That usually yields a few more tasks (e.g. they remember that it takes 4 hours to deplay the system before it gets tested). Then I ask them for time estimates on the tasks and usually question those. To date, I have only increased their estimates.
--Mark
Matt Cao
Ranch Hand

Joined: Apr 03, 2003
Posts: 715
Hi,
No, it will not offended anyone. You should make it a wall size and post on the wall in the conference room or any place that your team usually conduct weekly meeting. In my company we go extra step by tying it with the action-minute status report. We go extra mile to let people understand the important of time management because we have to report to clients on weekly basis and the team separate by three continents.
Regards,
MCao
John Dale
Ranch Hand

Joined: Feb 22, 2001
Posts: 399
I've not gotten to do much programming. But when I have, I've liked to have a way to feed what I learn week-by-week back into the process as things go on, and to adjust things to keep the effect of misjudgements or the zillion little things that sneak in under the radar from piling up into the part of the project. As you work a project you usually develop a much better understanding about which features of a project are really important to the end user, which are costly to develop and to use, etc. This, coupled with progress information, could be adjust priorities, assignments, and estimates, if anybody had the time to think about it. It seems to me that schedule feedback when there is time and opportunity to do something with the information could be greatly appreciated, especially if it helps avoid the death march. "Padding" at the beginning (meaning trying to allow for details that are not explicitly in the plan) is helpful, but I suspect that continuous feedback and adjustment to the plan gets people to think a lot harder about what they are doing and how they are doing it.
As for charts with red on them... A lot would just depend on the tone of an organization. I've been very surprised at the degree to which "non-management" reaction to change is "this too shall pass". (I shouldn't be, since, all too often, it is true.) You might want to consider whether your gut reading of the environment is "we are all trying to learn to do this better", or "what we had was just fine, let's not rock the boat". Almost anybody is going to first turn red when they see red on their task. So what matters is whether people get stuck there, or get past the pain and on to how to solve the problem. Pushing past that pain is a learned behavior. [M. Scott Peck, The Road Less Traveled.]
My hunch is that, at best, it will take more than a modest increase in hours work to move from "delivering whenever it is ready" to "delivering on schedule". This leads to the problem that, whatever you try, if people didn't really buy into it, the one thing they will know at the end is that "it didn't work".
Sorry to give you a hard time on this. I know it is a tough problem, and I wish I could be more constructive. I'm glad I'm not a manager.
Kevin Thompson
Ranch Hand

Joined: May 04, 2001
Posts: 237
Mark,
No way!!!. I have a very strong opinion on this.
Assuming you ARE NOT their direct boss ==>
If I was a programmer and somebody who was not my boss put a gant chart for my project on the wall it would piss me off!
Who do they think they are to "movitivate me"?
Why does somebody who is not my boss even think they understand the technical issues and scheduling issues involved in my project?
Assuming that you ARE their boss ==>
I would talk to them individually. Putting something on the wall is an underhanded attempt to motivate people via public humiliation.
Kevin
SJ Adnams
Ranch Hand

Joined: Sep 28, 2001
Posts: 925
http://www.westegg.com/exupery/
If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea.
http://www.dockingbay101.com/ep6.html
Perhaps I can find new ways to motivate them
So is what is you management style Mark? Darth or an Antoine
Terimaki Tojay
Ranch Hand

Joined: Nov 24, 2003
Posts: 165
Just talk to your guys and tell that this has to be done by this date otherwise all of us will be fired. The job will be done before the deadline, if you have smart people.
From my experience, smart people have more than 50% reserve capacity, which they use occasionaly to show that they are smart.
By posting gnatt charts, motivational speach etc. you'll not fool any'smart'body. They consider it all as management BS. So you'll be wasting your time.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16103
    
  21

Oh Boy.
It's been said (probably by Ed Yourdon) that the important thing with programmers isn't in motivating them, it's in not de-motivating them.
Of course everything's behind schedule. The worst job I ever had was in a shop that was schedule-obsessed. It became apparent at time went by that the programmers were actually pretty good at predicting the amount of time it would take to write "x" lines of code, but were routinely off by a factor of 2 on the actual amount of code required. I personally like to tkae what I think it would take and double or triple it, which actually has made me come in pretty close to reality. But it makes managers really unhappy.
Very commonly, the programmer gives an estimate, the manager doesn't like it and leans on the programmer, the programmer downscales the estimate and the project comes in "late".
Or, just to repeat an ancient business adage: "Everything takes longer and costs more".
OK. So much for the usual BS. I've said it before and I'll say it again. Creating software is not like making ground beef. You won't get results faster by applying more pressure or running the grinder for more hours. Quite the contrary. Abuse the staff too much and the code will be hamburger.
However, while brute force will get you nowhere, applied deviousness will.
First off, realize that almost every project is two projects. The obvious project is the one that's contracted for. Allow for the other one as well. That's the one where the programmer is stretching his/her horizons. It may not pay back immediately, but it does pay off in morale, a more competent staff (assuming you're willing to buck the trend and actually retain staff), and sooner or later those little offshoots may find their way into something of major value. This is the carrot. More than money, toys, free pizza or anything else. We got into the business almost one and all because it was fun. People who get into it for the money generally get out pretty quick. So the #1 anti-demotivator is to not stomp on people's pet projects. Programmers hate being bored. When they're bored, they may occupy a chair for 10-12 hours a day, but they won't be productive. If something piques their interest, you'll have to chase them home.
On the other hand, pet projects don't get the product out the door. They're simply something that you should allow for as overhead. Overhead's ALWAYS underrated. Out culture is obsessed with eliminating overhead. We'll spent more time, effort, and money getting rid of overhead than we lose to the overhead. Let it go.
So far this comes in a a bunch of "deal with it"s. But that's not the whole story. You need a realistic timetable. You need self-motivated staff. But you also need milestones and triage. Projects must have well-defined goals. If they don't they'll fuzz off into oblivion and they'll fail. They also need well-defined subgoals. Just like structured code, you need structured time. A project should ideally be divided up into "must-have's", "nice-to-haves" and "optionals". I also like to allocate alternative goals such that IF the prerequisite "must-haves" are coming in on schedule, then the less important things get time allocated, but design in such a way that, should time become tight, I can jettison the options without having to back up and rework the main sequence. Or, alternatively fall back to a more achievable option. That's where a good modular design can be invaluable, as can keeping a few spare frameworks around.
Rather than posting a big colored Gantt Chart, I'd go with a more informal diagram that shows the overall schedule with emphasis on the high points. Just some notes on the local whiteboard are enough. Sometimes it's better when you're slogging down in the valley to be able to take a quick look at the mountaintops and realize where you should be. Save the Gantt charts for the individual workers, pass them out in private and discuss them regularly. People need to be reminded that they're on a schedule, even though I don't believe in tight schedules for quality software myself. Take notes on what milestones have slipped and why. If the same issues keep coming up, take them into account on future plans. And pass out a few attaboys for results above and beyond.
Communication is the key. Turning packs of programmers loose and issuing edicts from the mountaintop won't work. If you're in touch with your staff, you should be able to see the problems coming. And if you see problems coming, it's your job as manager to plan for them.


Customer surveys are for companies who didn't pay proper attention to begin with.
Matt Cao
Ranch Hand

Joined: Apr 03, 2003
Posts: 715
Hi,
There is a thing called weekly meeting. The team get together discuss each member problems and report the progress. Not all team members knowledge level are the same so Mark H needs to step in, sort out differences, and lends support whether asking others contributions or he himself.
By have the chart up on the wall, each will also aware and not make a big fuss about compensation percentage. Mark will save himself a lot of headaches down the line with assumption that Mark also practices democratic performance review.
Mark do not put on the hallway, a small conference room is my best bet. If you put on the hallway, your company president will tell you to remove it.
Regards,
MCao
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
Originally posted by Tim Holloway:
Very commonly, the programmer gives an estimate, the manager doesn't like it and leans on the programmer, the programmer downscales the estimate and the project comes in "late".

I recognise that well.
Or the project manager finds out after he gets his plan approved that marketing has gone ahead and promised delivery early.
Or someone forgot to do a correct translation of required hours into required days, counting 8 hours of coding time per day without taking meetings, sickleave, vacation time, testing, etc. into account.

First off, realize that almost every project is two projects. The obvious project is the one that's contracted for. Allow for the other one as well. That's the one where the programmer is stretching his/her horizons. It may not pay back immediately, but it does pay off in morale, a more competent staff (assuming you're willing to buck the trend and actually retain staff), and sooner or later those little offshoots may find their way into something of major value. This is the carrot. More than money, toys, free pizza or anything else.

though the free pizza will motivate people to do overtime, they're not going to work on an empty stomach

Communication is the key. Turning packs of programmers loose and issuing edicts from the mountaintop won't work. If you're in touch with your staff, you should be able to see the problems coming. And if you see problems coming, it's your job as manager to plan for them.

And even more importantly, to learn from them to avoid them in the future.


42
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
Originally posted by Mark Herschberg:
I am slightly concerned with the amount of effort put in by some developers. I don't think the appreciate the ugency of some products.

Did you explain it to them?
And are you realistic?
I've seen too many managers call every single doohicky mission critical to believe most of them...

Undoubtedly, many of you just thought "typical management thinking." Before you judge me understand that we have a 40 hour work week with 1 hour for lunch each day. Right now we're a week away from the project deadline, it's behind schedule (this is the scaled down product) and the engineers still seem to work at a casual rate, not recognizing the importance of getting this done on time. While I believe people should be able to surf the web and take occasional long lunches, generally trustng them to be accountable for their own time, given the deadline and schedule, I'm concerned.

We started working overtime when the project was feared to go over schedule 3 months before the deadline.
Now it's 1 week before the deadline and we're waiting on the testers. Development is done, testing is still ongoing, something you can't blame on us as we warned about that months ago but management did little!
Yet guess who'd be blamed for problems due to poor testing in most companies. Let me give a hint: neither the testers nor management.

I believe this is a systemic problem. That is, there never have been schedules and deadlines before. They just did it and kept working on it until it was done. This project, originally estimated for 2 months, is currently 4 months overdue from when they originally planned it.

In that case you can't blame the programmers that they're not used to work under a deadline...
You should have educated them earlier, not waited until the last moment and then blame them for your inaction earlier in the process.
Al Newman
Ranch Hand

Joined: Mar 30, 2003
Posts: 716
Originally posted by Jeroen Wenting:

In that case you can't blame the programmers that they're not used to work under a deadline...

Wrong, Jeroen. Along with the adage Tim quoted about things always taking longer and costing more, I'll add another one. The programmer/implementor is always to blame.
Excrement is a liquid and it flows downhill. Guess who is at the bottom of the hill.


SCJP1.4, SCWCD
Mark Fletcher
Ranch Hand

Joined: Dec 08, 2001
Posts: 897
At my current place of employment, we start having daily meetings as we reach the end of the development cycle (just before code freeze, and then onto the end).
These meetings are short, no more than 10 minutes. The agenda for the meeting is basically to establish
a) How far along we are in the process
b) How far we have to go to reach our goal
c) That everyone is clear on their tasks for today.
Once this is out the way, the development manager asks everyone if they are having problems with their current task. This encourages developers to speak out and say "Well Im having a problem with x right now". The developer doesnt have to give a lengthy explanation, just that there is a potential problem.
The development manager then makes clear whether or not that person should be approached, so that they can continue on their work, or asks for volunteers to help the developer work around their problem.
The meeting is then concluded.
I think this type of short meeting is good. It reminds us of our impending deadline, by dicussing what has to be done. As developers it encourages us to work together as a team, knowing that we can get help from other developers if we get stuck in our tasks. Finally, as everyone is in that "team" frame of mind, no-one wants to be the "fifth-wheel" holding everyone back. Being aware of the goal, and being aware of what has to be done and what contribution has to be made to the team, prevents people from bunking off, surfing the web etc.
Does that help?
Mark
[ November 27, 2003: Message edited by: Mark Fletcher ]

Mark Fletcher - http://www.markfletcher.org/blog
I had some Java certs, but they're too old now...
D. Rose
Ranch Hand

Joined: Apr 25, 2003
Posts: 215
Team gets demotivated easily if it thinks management itself is not serious enough. Is management doing enough in terms of resources,environment,tools and training etc?
There has to be building of trust in the team and I think team meetings are good for this. IMHO it is not a problem to discuss schedule ( even red ones etc)issues in a closed door team meeting. Other team members might want to volunteer.
No person should be made to feel inadequate. Instead team should be prepared to give full support.
Also encourage people to revise their estimates based on their experience and they can come up wih good ones.
Al Newman
Ranch Hand

Joined: Mar 30, 2003
Posts: 716
Originally posted by Tim Holloway:

OK. So much for the usual BS. I've said it before and I'll say it again. Creating software is not like making ground beef. You won't get results faster by applying more pressure or running the grinder for more hours. Quite the contrary. Abuse the staff too much and the code will be hamburger.

True. I can do this to myself for a relatively short period and get results but I've never seen a manager who could do it effectively to others. Be careful when you ask for and/or pressure staff members into a corner. It will wring them out and piss them off royally. So save it for when you really need it, because you'll only get it once.
Originally posted by Tim Holloway:

Rather than posting a big colored Gantt Chart, I'd go with a more informal diagram that shows the overall schedule with emphasis on the high points.
Save the Gantt charts for the individual workers, pass them out in private and discuss them regularly.

Yes. I've seen charts backfire in a big way. Once a manager posted weekly charts showing bugfix goals and the individual performance of all the team members. Nobody was doing better than 40% of the goal. A couple of us decided to shove that chart up his ass. We kicked up our performance but also devoted a couple hours a week to looking over the buglist for 'water' (duplicates, already fixed, tester opinion 'bugs', etc). Our game was to make the manager change the scale on his charts.
His goal was 16 fixes a week. Two weeks after he started posting the charts I clocked 32 fixes in a week. 8 'real' fixes, 24 'water'.
The charts disappeared the next week and the second the crisis passed the mofo canned me. No sense of humor at all.....
A chart will be seen as a challenge. If one of your clever boys kicks your ass with it the proper response is to buy him a beer and laugh with him, not to fire him....
Originally posted by Tim Holloway:
And pass out a few attaboys for results above and beyond.

Difficult to get right but extremely important. Make them routine for everyone (including timeservers) and they are rightly seen as bullshit. But if you don't say thanks for 'above and beyond' you may not get it again. You certainly won't deserve it.....
Originally posted by Tim Holloway:
If you're in touch with your staff, you should be able to see the problems coming. And if you see problems coming, it's your job as manager to plan for them.

I've managed a few times, and I think one job of an effective manager is 'problem-solver'. Clear obstacles fromn the paths of your people. Walk around once or twice a day and ask whether people are getting hung up on anything. If so, DO SOMETHING about it! If nothing else, find out why then explain why 'we' have to live with it. For now.
D. Rose
Ranch Hand

Joined: Apr 25, 2003
Posts: 215
Also, it is important to give programmers the big picture i.e an idea about where their deliverable fits into big picture. It will give them some excitement.
I was once part of very big team building online ordering system. I got real knowledge about our project and what our on time delivery really means to business ( cost and time savings) after one presentation from business side. It was interesting to know how meaningful our product was for the real business.
[ November 27, 2003: Message edited by: Rei Damle ]
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by Jeroen Wenting:

In that case you can't blame the programmers that they're not used to work under a deadline...
You should have educated them earlier, not waited until the last moment and then blame them for your inaction earlier in the process.

Well, I did only join a month ago, but you're right, I really should've done more to educate them a few months back. The fact that I wasn't employed by them is an obstacle better manager than I would've been able to overcome.
--Mark
Al Newman
Ranch Hand

Joined: Mar 30, 2003
Posts: 716
Get used to unfair criticism, Mark. Unless you've saints around you it's going to happen. It happens to all of us and especially to new managers....
Somehow I thought it was longer than a month, Mark.
 
jQuery in Action, 2nd edition
 
subject: Feedback on public charts