[kerpele]

I completely agree with this article. I've worked in scrum and kanban teams and also lead both kinds at some point. To me kanban is by far the better option for the exact reasons outlined in the article.

The point is that deadlines are bad for the people doing the work when they can't influence the amount of work. Not that deadlines should be removed completely, but they should be moved to a level where the amount of work can be influenced, namely project/product management. They should then, completely independently from the development team, adjust the backlog and/or deadlines in case the project schedule starts to slip. If the deadlines are needed because there are doubts that the dev team is not working as hard as they reasonably can then there are bigger issues that any project management method cannot fix.

[kokokokoko]

I find it interesting that in other building projects, like in construction, almost all of the pressure and responsibility for meeting deadlines is placed upon the project management. Not the ones doing the direct labor.

The reason for deadlines in software, they way they are used today, is simply to get more hours out of a week from a software developer. Unlike in construction, software developers do not get paid hourly, nor do they get overtime pay. Abitrary micro deadlines coerce developers to work extra hours which makes their cost per week for amount of work to go down.

In construction, if they made up an arbirary micro deadline that was too short, the workers would get overtime pay at 1.5x their normal rate. Plus the additional hours. So for them, a too short deadline makes their cost per week for amount of work to go up.

We debate endlessly about all these estimates becase we're all pretending its about things that its not. Its almost completely based upon getting more hours per week per developer, as it makes the labor less expensive.

[wrnr]

One point of contention for me is the dichotomy between the managers and programmers where one takes care of the "what" and the other the "how" in order to learn "when".

To find a solution within the constrains of this problem-space there need to be made tradeoffs that require creative thinking at every level.

I used to focus on technical work until I realised we where spending millions on projects that go nowhere.

Like in the Dilbert comics its ok for management to wast the time of the developer but a developer should not be allowed to wast his time. It may sound like a cop-out but its much more productive to be able to say, ever so politely, "no this is not something we are going to do".