[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.