I was surprised that no one at the workshop seemed to have heard of Kanban or Scrum, much less practice it. Burndown charts and point-based estimation are a really interesting modification of the outside view by comparing your team to your team in the past, rather than to other teams.

I've worked with Scrum before. My general impression is that it's about one part useful to two parts extraneous formalism and fluff; a lot of what I interpret as fluff is probably designed to handle some failure mode I've never seen, but any given team is only going to exhibit a subset of possible failure modes, and the Scrum methodology doesn't encourage or give you the tools you'd need for that kind of tailoring. It does beat naive development styles, but that's mostly because naive development is incredibly inefficient: twenty percent technique, talent, and education and eighty percent not getting distracted by the Internet, to paraphrase a friend of mine.

The most useful change, when my team tried it, seemed to be offloading most coordination burden into short, regularly scheduled informal meetings at less productive times of day rather than indigestible semi-random clots scattered throughout the week. That helped quite a bit, although it also created scheduling problems of its own.