Getting started

We had a meeting last week to discuss some of the topics we encountered at XP Day. One of the main things we all agreed was the need for more regular (and meaningful) meetings for teams small teams. Scrum style daily stand ups might be a bit overboard at the moment, but we can see real value in teams meeting at the start of the week to agree what will be accomplished that week. That and more frequent retrospectives. At the moment our current development process has everyone involved in a whole release meeting just after that release (and we release roughly every 5-6 months). This means that issues pile up and result in a huge list of actions that sometimes gets lost… Now we don’t think it should be that hard to convince team leaders to have more regular reviews. We can start there, then feed back to upper management.

Unit testing is something quite high on our quality agenda. All devs have been told to start providing estimates with time to write unit tests. (don’t get me started on estimation!) Problem is many of our developers are not very experienced with writing unit tests. This may be a steep hill to climb. The plan here is to start as easy as possible with internal workshops and coaching from the more senior developers.

Pair programming sounded good, but honestly we can’t force it on our devs, mainly because it would halve our development team. And I’m not thinking in a manager, “2 developers to do 1 task” kinda way, I mean one half of the team would probably kill the other half…or quit…or both… No, a flexible “if it helps” approach to pair programming is favored here.

Other issues we didn’t quite have time to discuss were documentation levels and possibly looking at Kanban for our issue management process. See a great intro to Kanban at Karl Scotland’s blog.

This is going to be a pretty slow process, which in a way is good, as it gives me plenty of material to blog about