Cases Against Applying Schedule Pressure(stickyminds.com)
stickyminds.com
Cases Against Applying Schedule Pressure
http://www.stickyminds.com/sitewide.asp?ObjectId=9947&Function=DETAILBROWSE&ObjectType=COL
5 comments
Quality can only be attained by employing quality people. Just by giving folks more time will not automatically turn into quality product. Many times quality people do not require more time to make a better product. They just need to be left alone.
Having said that Quality people are also people. People need deadlines or else will fall victim to student syndrome (all assignments and projects are done last 2 days before the deadline, refer http://bookoutlines.pbworks.com/Predictably-Irrational Title: Problem of procrastination).
Quality people loving what they do, need to be put on deadlines which they agree to as being reasonable. The business should for the most part function around these deadlines. When a customer imposed hard deadline shows up on the radar, a healthy conversation should settle the acceptable quality/feature cuts to meet it.
The essential task of the leader is to make such sudden showing up hard deadlines as minimal and as far apart as possible through insight and foresight. The quality of the leader can be directly judged using the number of such deadlines that prop up in a given span of time.
Having said that Quality people are also people. People need deadlines or else will fall victim to student syndrome (all assignments and projects are done last 2 days before the deadline, refer http://bookoutlines.pbworks.com/Predictably-Irrational Title: Problem of procrastination).
Quality people loving what they do, need to be put on deadlines which they agree to as being reasonable. The business should for the most part function around these deadlines. When a customer imposed hard deadline shows up on the radar, a healthy conversation should settle the acceptable quality/feature cuts to meet it.
The essential task of the leader is to make such sudden showing up hard deadlines as minimal and as far apart as possible through insight and foresight. The quality of the leader can be directly judged using the number of such deadlines that prop up in a given span of time.
They'd say, "We want to be this far along by July," or "By August we need to be able to handle these types of transactions." I'd ask them how they'd established those deadlines. The answer was always the same: No businessperson had asked for a specific amount of progress by a specific date, but the team had decided how far along it needed to be at various checkpoints to feel good about the overall progress.
It's unfortunate that the author had this awesome insight, and then went off on a tangent about people being more comfortable with schedule pressure than with quality pressure.
"Feeling good about the overall progress" as presented above isn't schedule pressure, it's a measure of quality and efficiency. "We want to be this far along by July" is a way for the team themselves to gauge if, for example, they are spinning their wheels doing the wrong thing (because it's taking too long, because it's too hard, because it's not broken down into subtasks properly, whathaveyou), which directly relates to quality. As this "deadline" approaches, one can judge if with greater accuracy if it's going to be made. And since these "deadlines" are not hard and fast, or at least not as hard and fast as if some business person had set them, tweaking them is less work and less upsetting. Don't think all seven of the transaction types are going to be done by August? Scale it back to five, work on getting it into a state where these five can be handed off to the next team to work on the next part and build it such that new transaction types can be added later so more people can work in parallel. Dependency handling (with the core dependency getting the project in a shippable state within a reasonable amount of time) is the reason schedule pressure exists in the first place.
I've often had to say to my team "We seem to be spending a lot of time on X, and are close to [or past] the initial estimates for completion. Are we doing the right thing here? What else are we going to have to cut? What do you want to cut? Is it too complex, and can we simplify it?". Too often, even the list of things (features) that need to be in the final product are determined externally (read: by business people), without any input from the people who are actually going to do be doing the work. The implementing team should be involved in both the feature list and the schedule (a regular topic on HN). I've been on both sides of the table too many times where there is a "technical" resource included in the scheduling planning/meetings just for show and their insight and participation is discouraged, usually because promises have already been made and the planning meeting is just a big Tetris game, an attempt to fit a bunch of lines and shapes into a fixed size box.
That all being said, bluishgreen's comments about revolving around the customer are spot on too. A lot of that comes down to handling expectations. In my experience, schedule pressure is often the result of improperly used Gantt charts. Gantt charts should be living documentation used to answer questions about scheduling and dependencies, not a static bible to be used to browbeat people (both the implementors and the customer) into buying into some fantasy dates.
It's unfortunate that the author had this awesome insight, and then went off on a tangent about people being more comfortable with schedule pressure than with quality pressure.
"Feeling good about the overall progress" as presented above isn't schedule pressure, it's a measure of quality and efficiency. "We want to be this far along by July" is a way for the team themselves to gauge if, for example, they are spinning their wheels doing the wrong thing (because it's taking too long, because it's too hard, because it's not broken down into subtasks properly, whathaveyou), which directly relates to quality. As this "deadline" approaches, one can judge if with greater accuracy if it's going to be made. And since these "deadlines" are not hard and fast, or at least not as hard and fast as if some business person had set them, tweaking them is less work and less upsetting. Don't think all seven of the transaction types are going to be done by August? Scale it back to five, work on getting it into a state where these five can be handed off to the next team to work on the next part and build it such that new transaction types can be added later so more people can work in parallel. Dependency handling (with the core dependency getting the project in a shippable state within a reasonable amount of time) is the reason schedule pressure exists in the first place.
I've often had to say to my team "We seem to be spending a lot of time on X, and are close to [or past] the initial estimates for completion. Are we doing the right thing here? What else are we going to have to cut? What do you want to cut? Is it too complex, and can we simplify it?". Too often, even the list of things (features) that need to be in the final product are determined externally (read: by business people), without any input from the people who are actually going to do be doing the work. The implementing team should be involved in both the feature list and the schedule (a regular topic on HN). I've been on both sides of the table too many times where there is a "technical" resource included in the scheduling planning/meetings just for show and their insight and participation is discouraged, usually because promises have already been made and the planning meeting is just a big Tetris game, an attempt to fit a bunch of lines and shapes into a fixed size box.
That all being said, bluishgreen's comments about revolving around the customer are spot on too. A lot of that comes down to handling expectations. In my experience, schedule pressure is often the result of improperly used Gantt charts. Gantt charts should be living documentation used to answer questions about scheduling and dependencies, not a static bible to be used to browbeat people (both the implementors and the customer) into buying into some fantasy dates.
One of the problems with no schedule pressure, which I believe is best, is that software can always be better. Clicks can be removed. User interfaces can be made cleaner and easier to look at.
To remove the schedule pressure, you have think differently. Instead of, "This project is done on Friday," Think, "This project is done when no one has complained about this form for 3 weeks." This project is done when no bugs are reported for 4 weeks. Etc.
To remove the schedule pressure, you have think differently. Instead of, "This project is done on Friday," Think, "This project is done when no one has complained about this form for 3 weeks." This project is done when no bugs are reported for 4 weeks. Etc.
I agree with this. Nine times out of ten, schedules tend to be arbitrary guesses anyway. I don't know if I agree that scheduling pressure should be totally removed, but I feel that a lot of organizations place it too highly compared to other pressures.
Though I can't help but boggle at the author encouraging a team to abandon all milestones/deadlines in the pursuit of quality. While perhaps the given team really was looking for a convenient excuse for any quality problems, I can't help but look at it as pragmatism.
"Take all the time you need - but make sure it's perfect," is a good way to discourage completion.