SCM Essentials for Small Teams

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.

Why all this fuss about tasks? I won't explain why but will try to show the added value: if everything is a task, everything, then all your work is somehow under control, which is good for the team because they learn about past mistakes with a strong foundation. This is also good for the team because they can show management what they were doing. The last one itself is worth the effort (remember it will just take a few seconds per task!).

Some teams stop here, but then we still have a missing link: what's the relationship between the tasks we've just defined and the source code? Because we must remember that this is all about the code. Forget the code and then developers will see all as a waste of time. And they can be right!

Here is when the version control enters the scene. Probably, if you're a small team, you don't think you have to control what developers do, you trust them anyway, you don't need a complex security mechanism or a whole set of rules to enforce policies and so on (or maybe you do, because I've seen small teams being really successful by introducing a number of best practices in their daily work).

If you see version control as just a way of managing the changes, then obviously you won't get all the benefits. Lots of teams use version control just as a (sometimes painful) delivery mechanism. You finish something, you check in the code. That's it. You don't create intermediate changes, you don't back up your changes while you develop, you don't run diff debugging (looking for potential problems just inspecting file's history before setting up a debugger session), and so on.

Were you ever coding and then you said: "uhm, this was working five minutes ago but it's not working anymore. If I only had a copy...". What if you had checked in the code five minutes ago? Then you could check the differences. "Hey!"—I hear you shouting—"but the code wasn't even compiling!"

Here you are: you're using your version control tool just as a delivery tool, not as a productivity tool. What about using task branches [4]? Then you really close the gap between the issues created in your favorite task tracking system and your version control. Easy, fast and efficient. And then you unveil all the benefits task branches (or workspace branches, there are many options available) can bring to your team. You ask your developers to commit as often as they want to, but then they only merge changes together when they're done. It is just one step ahead in the regular version control usage, but
it provides everyone with a lot of added benefits.

You can also think that you don't need a good version control system because you seldom do changes in parallel. And here you've hit the key point: there's something that both small and big software bases have in common: most changes are performed on a reduced set of files and directories. So if you're serializing your changes... you're losing productivity!

Probably your team members need to synchronize themselves continuously asking when they're done with something, or use locking checkouts for that. Is there a better way? Of course: make changes, forget about what others are doing, and have a tool capable of reconciling changes back seamlessly.

What I like about small teams is that they have a huge potential. According to some studies [5], the most productive teams have around five to seven members. Of course small teams, especially in small companies, have a lot of surrounding risks too: what about managers changing their minds or focus twice a week? What about multi-tasking? [6]. Of course the risks are there, but correctly managing the situation with the help of some of the best practices described above will greatly improve the situation and put things back under control.

There's one thing left which is not entirely under the control of SCM which is testing: it is deeply related to release building but an entire story itself. Small teams can move very fast: they can set up a task tracking system, version control system and start doing tests in a week, and these three practical practices alone can push their productivity, control and results to a new level.



References
    1.    Software Creativity 2.0. Robert L. Glass.developer.*. November 2006.
    2.    Rapid Development, Taming Wild Software Schedules. Steve McConnell. Microsoft Press. July 1996.
    3.    Agile Estimating and Planning. Mike Cohn. Prentice Hall. November 2005.
    4.    Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Stephen P. Berczuk. Addison-Wesley. November 2003.
    5.    Software Estimation: Demystifying the Black Art. Steve McConnell. Microsoft Press. March 2006.
    6.    Manage It!: Your Guide to Modern, Pragmatic Project Management. Johnanna Rothman. Pragmatic Bookshelf. June 2007.