Many companies talk about how awesome (yes. I am American) their development teams are because they use agile project management techniques. However in my experience it rarely, if ever, is the case. But it helps us sleep at night to think this thought.
The theory (AFAIK)
A good manager is worth their weight in gold, however there are A LOT of bad managers in the world.
Enter "Agile" Management
I'm convinced agile techniques were dreamed up by an engineer for the sole purpose of insulating them from bad managment. e.g. constant interruptions, pivots, context switches, creative flow disruption, ID10T errors, PEBKAC errors, etc.
The gist of the issue is you should hire good developers/engineers, then give them a task, and get OUT OF THE WAY.
Companies are no longer ruled by engineers...
Unfortunately for consumers who care about quality, accountants not engineers, rule the business world. The day where an engineering could veto something as crap, have been replaced by cheaper and faster.
In this mess we're asked to account for hours, versus actually doing the thing. Being forced to account for hours, estimate time to completion, and any other method that correlates estimated development time to actual time is a detriment to said development.
This shouldn't be something that a developer actively tracks. Why? Simply put, it slows them down. Its not something we like, so like cleaning up one's room, we'll avoid it as much as possible.
From our point of view this is why management exists! To figure out how long things will take! (and also as upper management's whipping boy or girl.)
The diry secret: Its all fake anyway!
The dirty secret of project estimation, which no one seems to readily admit is that human beings are horrible at estimation! Or we just fake it because we have no friggin' idea.
For most software development, we're in new territory. There is a shame in admitting we've (and probably no one) has ever done it before.
In my opinion, agile tries to solve this by establishing an individual's or a team's bias in estimating "things". The theory being that people esitmate incorrectly but they do it consistently incorrectly, i.e. estimates are accurate but not precise. Agile gives a fudge factor that can be used to adjust the estimates and get something close to what will actually be the estimated time, i.e. accurate and precise!
estimated time + established_bias ~ actual time
Don't force your developers into artificial constraints!
Strive to allow them to figure out how to do the thing vs. figuring out how long it'll take to figure out how to do the thing!
- Hire good people.
- Trust them.
- Facilitate the road blocks.
- Prepare to be amazed.
A Good General Rule
You can either do the thing or figure out how long it'll take to do the thing, but you can't do both! Which one do you want your people doing?