[vannevar]

These are really good observations. If there's a common thread, I would say it's the intolerance for failure exhibited by managers who don't understand software development. I'm not sure that intolerance would be lessened by another system, whether it be waterfall or kanban, or ad hoc. Prior to agile, when failure happened, it tended to happen in a big way near the end of the project. But if a project were two or three years long, as is common in software, everyone could move on to other jobs after having spent two or three years without having to report progress every day or demo features every two weeks. A couple years in one job is pretty typical nowadays. So in some ways it was a more comfortable environment for engineers.

Agile was introduced so that failure could be amortized and tracked. It makes the development process more transparent so that mid-course management corrections can be made and the corporate ship can be steered around the icebergs instead of running blindly dead into them. But in order for it to work, management must be tolerant of small failures. If it's not, then scrum will become theater with failure swept under the rug, and you'll be right back where we were, with failure becoming apparent only near product launch, when the iceberg suddenly appears out of the fog too late to avoid it.

Now, it may be a valid criticism that agile expects too much from management, that most software company managers aren't competent enough to use it. But that pretty much says we're all doomed anyway, regardless of what system (if any) is employed.

I'd be interested in your thoughts on why you feel kanban is better, since my impression is that it is essentially the same process but without sprint intervals.

[beckler]

So kanban and scrum are fairly similar, but the difference is that with kanban, you don't have to estimate a point value to it, as time isn't the priority.

I view this as an advantage for two reasons:

- 1. Most non-technical clients view point estimates as absolute expectations. They can't comprehend an estimation in any other way. So if I can do 5 points a day, and I give a story 13 points, it's expected to be accomplished in ~2.5 days. If I exceed that amount of time, I've missed their expectations, and now I have a client who considers that work behind schedule.

- 2. Large complex problems can be solved without the pressure of accomplishing it within a finite deadline. I think this leads to more robust implementations, and helps prevent large amounts of technical debt. To compare, I have never seen a scrum project that didn't have a runaway amount of technical debt that lead to some insane scope creep in stories later on.

It has a downside of potentially hiding some problems, but I think it helps with individual responsibility when it comes to tasks. Every time I've used kanban, it's usually been for pretty short periods, but those periods were extremely productive and way less stressful.

I mean, this is just all my opinion, so take it with a grain of salt, but this is what my agile experience has been so far.

[vannevar]

Thanks, interesting perspective. The advantage of sprints is that you're demoing progress on a regular basis. I can see the possibility of people focusing more on the demo than the ultimate purpose of the code, in which case as you say you'd accumulate technical debt in the form of hacks. But if you don't demo regularly, you run the risk of hidden problems where everyone assumes something works when in fact it doesn't. Either way, competent management is needed to avoid the pitfall.

[spronkey]

The 'hack a demo' problem highlights one of the rationales behind having a Definition of Done in Scrum. Unfortunately Scrum doesn't put hard and fast rules behind what should be in it, but most good Scrum teams take principles from XP such as all code should be tested. This helps reduce the 'hack' factor at the expense of getting it out the door faster.