I don’t believe in swarming, since very often it is really hard to split work and keep it in sync between at least two pairs working on a single story (refactorings, design decisions, etc). Also do not forget merging. It sounds sweet, but in reality it may just hold development.

I’m not specifically interested in time-boxed iterations, although time-boxing tends to be a common practice in most Agile methods. I did focus on the ‘process’ areas of XP rather than the engineering practices as that’s what ties on most with the Kanban perspective.

Karl

I’d also argue that XP is more than just a set of software engineering practices (although it’s the only process that says anything about how to actually get code written), because it attempts to address (small-scale) organisational and even ethical issues.

S

The comments from Jason and William resonate with me. (I’m not putting “at” signs in front of their names because it’s a form of waste – the at-sign-equipped names aren’t clickable or usable in any other way, and they don’t aid in clear communication. No value. It’s also extra work – it takes two keystrokes. Muda.)

Karl, your example is very small scale. If there’s exactly one team and exactly one customer and the customer just walks over and asks the team to build functionality, it hardly matters what sort of process or framework they use. It seems to me the big issue these days is how to extend agile thinking across the enterprise, and how to scale the practices we’ve found to be so effective in the small. Lean tools give us a practical means to that end. XP is mainly a set of software engineering practices. Changing or adapting the process framework doesn’t eliminate the need for sound engineering practices. You seem to be interested in the question of time-boxed iterations specifically, rather than XP generally. Is that correct?

Great description! It is very close to the process I saw our team evolve to after introducing and incorporating kanban concepts. A couple of key changes that jump out at this moment that occurred were related to:
1) “swarming” on stories, rather than only one pair per story, became the norm with multiple pairs on a story and focusing on WIP first whenever possible before pulling a new one which helped visualize too any bottlenecks immediately;
2) Decoupling intervals for planning/prioritizing, reviewing, releasing, and retrospectives. Planning/prioritizing went to more JIT as needed and not on fixed 2-week intervals. We continued to conduct “reveals/reviews” on a 2-week interval but these were more ceremonial to share information with broader business stakeholders. Before any such “reveal”, stories had already been reviewed again JIT with product owners/stakeholder as the last step to DONE-DONE. Releases to the field occurred as per business needs, not necessarily every 2 weeks or after each story was completed although the potential was there, but rather more often after one or more significant features were completed (“in the can”); and although we continued formal “retros” every 2 weeks, we’d “stop-the-line” and address a problem when/if it made sense too (impromptu “huddles” at any time of the day/week/iteration to address these we common).

There was one or two more when I started this, but…I’m shutting down after a long day.

Take care,
Frank

Especially with iteration lengths above 1 week, too many teams do Scrum or XP in a mini-waterfall way, which causes a lot of pain and waste. Mini-waterfall is not a terrible way to go if you’re on 6-month cycles and just starting with an Agile approach. But it’s possible to do much better.

The best teams I see now are on one-week planning cycles, but they release every time a story is complete, which is as often as every few hours. That’s even more extreme than Extreme Programming, but if you use the Lean/Kanban analytical framework, it’s something you can arrive at very naturally.

In any event, I think that Kanban and Agile are just different view and different emphasis on the same basic stuff. It’s all good.