Scrum and Continuous Integration
I’ve been rambling about Continuous Integration a couple of times before and I just noticed that I have misspelled Continuous every time so I guess I’ll just have to go through all of my old posts and correct that. I have, on the other hand, gotten a lot of Google traffic from fellow misspellers around the world.
Here’s a google search with misspelled articles, and here’s a search with the corrected ones.
If you find any weird language constructs or words in the future please tell me. A big reason for blogging at all is to keep my english alive.
Anyway, I was thinking a bit more on Scrum and it struck me that Scrum is Continuous Integration for people. I know it won’t take a genius get that idea, but it made me feel even more comfortable with Scrum. I like to enable continuous delivery of value to the customer.
A customer should be able to stop a project (almost) any time and still get some value out of it.
Check your automatic builds frequently
Make sure your automatic, daily and continuous, build actually works.
It is just like checking that your backup procedures actually works. You do not want to find out either one of those is not working when you really need them.
This weekend our Team Foundation Server was moved and everything looked all right on Monday morning. There was no problem at all to connect to the new server and the Cruise Control Tray icon was a comforting green. I did have that uncomfortable feeling that something was wrong though…
… and sure enough; the configuration for Cruise Control wasn’t changed so it looked at the old server and kept on building the same old stuff.
Broken builds sucks and it should be a cooperative effort to keep the system in a buildable state, but there has to someone responsible for the automation. Someone who verifies the build frequently.
Continuous builds instead of meetings.
Lots of times I have been involved in lengthy discussions about how to solve a problem and trying to guess what the user really wanted based on his initial request. It is not uncommon that implementing all of the possible solutions and lettings the user choose the one that satisfies his needs would have been done in a shorter amount of time than discussing it.
I’m probably rambling but if we have a continuous build, that is releasable, we could in many of these cases give the customer builds with all of the solutions and let the customer decide.
I have heard of development teams that has taken deliverable builds to such an extreme that they build Virtual PC images with their system preinstalled every night. So even if there is server software involved it is possible to create agile deliveries.
Installable daily builds and salesmen
I have quite often ended up in situations where the salesman has promised new or existing customer non-existing functions. Functions that took lots of overtime and ugly code to get done. When developers, more or less loudly, protests against this practice they are either laughed off or told they don’t understand the sales process.
Quite often these forced solutions are not tested enough so the client isn’t satisfied anyway.
Assuming you took my previous advice and created releasable daily builds, I suggest you deliver what you have at the moment and update with new functionality as it is done. With shorter iterations everyone involved gets a feeling of success. This will probably not work for all kinds of systems but I think that generally it is not devastating if you (re-)introduce a bug that a large regression test would have found. The risk is quite big that a suite of test that are run a couple of times a year will find less than an ever growing suite of tests that are run every day. Furthermore, the receiver knows it it non-critical since there a new deliveries soon.
I don’t think you should be afraid to deliver often. One way of removing that fear is to have a well organized automatic test suite and build environment.
Releasable daily builds
Share and store documents… Free.
When you do daily builds, a practice I think is essential for high quality software development, it is important to make sure the build is so complete and easy to find that the test team and sales force can choose what version, and when, to install by them selfs.
It is an accepted truth that the longer you wait to fix an error the more expensive it gets. If the test team can verify a fix the day after it is checked in to the source repository instead of waiting for the next sanctioned release both the feed back loop and cost gets smaller.
For this to work all of the organization has to work in union to keep the daily build complete. It will not work if someone is working by him self and checking in bad code because he ‘knows’ there is a long time until the next release. If the development is done for a customer that expects to see continuous progress it is extra bad if someone is checking in bad code. It is a problem that is not solved with unit testing since the result of those is easily manipulated by the rouge developer.
Everyone has to work together to make each and every daily build ready for release.
Broken builds
Nightly builds are almost useless if there is no collective responsibility to keep the code in a buildable state.
Why should I even bother to make sure my code builds before checking in, when the build has been broken for a week and no one, who can/should do anything about it, cares?
Is it the responsibility of the ones who do care to be a PITA, or should we take it upon our selfs to fix all error just because we care?
Building
When doing pc based development I think that having a working build environment that you can quickly recreate on a developers machine is very important.
I also beleive that making it possible to have more than one instance of said environment on any computer should be a prioritised goal.
This will:
- save a lot of time when introducing new developers.
- make it easy to do more than one thing at a time.
- enable nightly builds.
- visualize cloaked dependencies
… and if you do nightly builds along with some automated testing you will:
- find errors early
- always have someting to deliver
- feel confident in your work
