SCM Essentials for Small Teams

[article]
Summary:
Very small teams think that SCM (software configuration management) is not for them. Even the name sounds like a big thing: CM, configuration management. "Why should I care?" They
say.

Small teams code, and that's actually a very good thing. But they normally refuse to use the bare minimum to work, the three core pillars as I usually refer to: version control, task tracking and testing.
There are teams whose problem is that they aren't aware of the possibilities they have introducing SCM into their daily work. But there is also another problem that we, SCM people, often fail to see: understanding is not always acceptance. I'm borrowing this concept from Glass' book on software creativity [1], where he insists on the difference. The point to actually move small teams to SCM best practices is not only a problem of teaching, but a problem of showing where the added value is. So let's try to focus on this.

If you work on a big team (and I won't try to define what small or big is in terms of size, I just leave it as an exercise for the reader), it is obvious that there will be a huge number of changes, each of them must be correctly controlled in order to prevent the software to break more often than expected (ideally it will never happen). There will also be a number of different roles involved, from very junior developers to senior ones, with different responsibilities and abilities. So preventing wrong things from happening is something a good SCM can achieve.

That's how small teams normally see SCM: something to control, something to prevent big problems... something for big teams only. But there are also some other issues out there: what about keeping a couple of releases in parallel? One used for maintenance and another to develop new features. What about exactly reproducing a given release? Or even more important, what about creating stable releases on a regular basis?

The last topic, releasing early and often, is the core of agile methods, but if I remember correctly I first read about it in one of McConnell's books long ago [2]. It gives you two important advantages:

  • You increase visibility. A lot has already been written about it in later writings on agile methods. You show regularly what you've achieved and then everyone is happy, from customers to upper management.
  • You get a fallback solution. Yes, create one controlled release a week (if you're a small team one will be enough, unless you go for continuous integration, but this is another story) and then if you miss a milestone, at least you have a working and fully tested release, not older than a week! This is much better than rushing the day (or a few hours!) before a demo.

And I see a really clear connection between these last two good practices and version control, and of course full SCM. You start by thoroughly controlling your changes, then your releases and then you create a fully controlled development cycle.

A number of small teams already use some sort of bug tracking system to manage issues and change requests from customers. But they usually fail (in my experience this happens in a number of big teams too) to register all changes. The advice here would be:
Whatever change you do in your code (or in your documentation, whatever) you create a new issue in your preferred task tracking system. Use the same system for both bugs and new functionality. This way you end up having a very simple and efficient way to manage your schedules. Yes, probably this is not the way you were used to doing it (do you miss your Gantt charts?) but there's something clear:

  • It is extremely simple and it doesn't introduce an extra burden.
  • There's a goal behind this: you first control all your tasks, so you can look back and know what you were exactly doing, how many tasks you can do (there's a whole link here with agile practices like measuring velocity [3]), and then you can also start controlling how long the tasks took to complete and you'll start creating an estimation database, which will be very useful in the future.
  • Developers don't need to spend a long time dealing with paperwork (something we hate). Creating a new task shouldn't take more than thirtu seconds. If it does, switch to another tool. Introducing the hours you were working on a given task shouldn't take longer than ten seconds. Anything longer will scare developers ... and they will fake the data.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03