Essentially everything we’re doing is the best way we can currently think of, so this is our “best” practice… for now. We are fortunate to be able to change things very quickly if it stops working. Saying that the metrics are a recent addition have proved very valuable, the short iterations not so popular with some of the developers, but the short feedback cycles have meant we’ve been improving our processes at a lightning pace. The build monitor creates more conversation than anything else we do and has really highlighted some problems that people had been avoiding.

One place we’re still pretty sucky is requirements and our relationship and communication with the rest of the business. We’ve got a pretty poor reputation and it’s not yet really been addressed, but we’ve been taking the approach of “do things right” before “doing the right thing”

The most significant factor in our team’s practices and progress has been having a Dev Manager who really understands the importance of what we’re doing and also real buy in from the senior management in the organisation. Without them you’re never really going to succeed.

One of the points made by Mark Baker at XP Day 2008 was that team leaders need to know capacity, throughput, cycle times (which I see in your process) and what’s working and what’s not.

Can you share any observations about which areas you think aren’t working or that you’re looking to improve?