Ray Arell read an agile project management book on a long flight to India, and, like all good reactionary development managers, he was sold. Join Ray on a retrospective of what went right and, more importantly, what went wrong.

One of the new roles introduced by agile software development is that of the team coach. Until agile came along, coaches were confined to the executive suite or the sports field. As with any new role, it will take awhile before it is fully understood and scoped. Agile teams can—and do—exist without the coach role, but such teams do not necessarily achieve peak performance.

If change is inevitable, and we're often able to see it coming, why are so many people resistant to it? There are some tried and true ways to help people deal with change, by listening to the reasons for their hesitation, and by making sure people know when they'll be benefitted by the transition.

Automated unit tests verify that a component is working as expected.  They also serve as a way to understand how code works, though this doesn't always happen by reading tests.  Sometimes understanding comes from tweaking the tests to observe new failures, or rewriting the tests themselves.