James Carr

Some of you may have attended the MidMoXp usergroup which I began organizing on behalf of CARFAX in September of last year. Although the usergroup always had very good meetings and even a couple notable speakers, it’s always suffered from on again off again scheduling, mostly in part due to my own rather haphazard, sometimes conflicting schedule.

Luckily, the on again off again scheduling will be gone as the group will no longer be solely organized and put together by yours truely… in other words, if I fall off the face of the earth, the next meeting will still take place.

But, that’s not the only news, there is much more activity afoot! When we met to plan the next meeting, we discussed several topics, and a specific question came up.

Why cater only to the eXtreme programming?

Which is a good question… only one organization in town (that I know of at least) does XP, while most might just be doing a few of the practices. By focusing just on XP, perhaps the group is a bit too narrow. We then decided perhaps it’s best to broaden the scope to include all things agile, but again, why stop there? There are quite a few people in town I know of who have no interest in agile, but they are interested in some of the agile practices or software development in general.

Which is why the group will be undergoing quite a bit of evolution. It’s no longer just focused on XP or agile anymore, but Software Development Best Practices. The topics will be a mix of technical, hands on activities (we will be organizing tutorials and coding dojos) with process related practices. You’ll still find a lot of agile related stuff, but as best practices versus promoting one methodology or another.

Our next meeting will be December 9th at 6:30 P.M. at CARFAX’s Columbia, MO data center. A co-worker of mine will be giving a presentation on Kanban boards with hands on exercises illustrating some of the advantages of using Kanaban boards to communicate progress. Hope to see you there!

Recently I’ve been following an interesting thread on the XP yahoo mailing list asking the question… should we measure individual velocity?

The general response seems to be “NOT AT ALL!!!”, but I won’t repeat the discussion there when you can read it yourself, but I thought I’d pick out an interesting point from the thread that was mentioned and expand on it.

Velocity is not a team performance metric, but a planning tool that
helps the team realize how much they can commit to a given iteration.

This seems to be a general point of confusion that always seems to come up and definitely bears repeating. From my point of view, velocity is basically a way of saying “the team completed on average x number of units per iteration the last y iterations, so the customers can expect x units will be completed next week. So, dear customer, with x units to spend this iteration, what features would you like to see implemented?”

Using velocity as performance metric is dangerous imho because it assumes that a team is either doing poorly due to a decline in velocity, or that a high velocity means a team is superb and probably deserves a hefty bonus. Rubbish.

Measuring individual velocity would be a disaster of epic proportions imho… it would go against the grain of teamwork first of all, since why would individuals or pairs feel motivated to ensure that the overall team does well velocitywise? Likewise, it would be a poor metric. If pair A completes 10 1 unit cards that were freakin easy (lets say each card was doable in a session or less) and pair B completes one 3 unit card and one 1 unit card that winds up taking awhile due to external factors, you can’t really sit there and say “pair A is a lot more productive than pair B, since pair B only completed 4 units. Maybe we need to do something to get them moving!”

Velocity is not about performance… it’s about providing your customer with a close to accurate amount of “points” they can spend on features this iteration. Remember that.