I recently helped a friend out with the technical side of going “agile”. This meant setting up some project source control and automation for build and test. I have a pretty advanced automation setup on most of my projects right now. It’s far from perfect (I don’t have nightly releases being tagged, etc), but it gets the job done. But I sometimes forget how long it’s taken me to learn the lessons and get things set up correctly (AFAIK – I’m no expert). I may be missing a lot but I always try to improve what I’m doing and review it often for lessons learned.
As I said previously I had about 2 hours with my friend to set up an automated build, and teach him the virtues of Test Driven Development and Continuous Integration. We set up a project with a simple NAnt build file that had the basic targets – init, clean, compile, test, and build – and then got into some code with a 3 tier project (presentation, BLL, DAL) and a test project. This all went well and he caught on quickly which was nice. I sometimes have a hard time teaching things because the ideas are so ingrained into me that they are difficult to explain to others.
I raised a red flag with him because he was trying to introduce a lot of new technology at once. I asked him to really think about which technologies he wanted to implement and get started with. The obvious ones to start with are automated build (Ant/NAnt), unit testing (PHPUnit/NUnit), and Continuous Integration (phpUnderControl/CruiseControl.NET). Beyond this I asked him to wait until he was comfortable with these before adding things like an ORM he was unfamiliar with.
One of the worst things to do is jump into a new project with 100% new technologies that first have to be learned. We always want to play with the latest and greatest and there’s a good reason for many of them to exist. But taking on too much at once and not coming away with a good understanding of any of the technologies can also be harmful. Pick your new technologies for the value they will bring, not for the coolness factor.
The other side of this coin is that with a good automated build, testing, and continuous integration, later down the line it is much easier to introduce these new technologies that may have real benefits. Your code will be much more flexible, and your team will be much more comfortable switching out older technologies for new ones because the tests will tell the truth. And with a good source control setup, you can always branch new technology development and merge it later if the team deems it worthy enough to add into the mainline development.
I would like to write up a series of posts covering the very basics of the technical side of agile, with this post being the first. Agile development encompasses everything from technical issues to management to customer interaction. It can be difficult to jump into without knowing the how or the why of each part. There are also several different ways to implement agile development. But it is often easy to start with simple and sound technical practices. A grass roots technical movement can have a great effect on changing a teams culture. And, it’s usually easier to ask for forgiveness than permission, and definitely easier to ask for it when your project is wildly successful because of some small steps taken in the right direction.
Another good way to get involved with agile development is to find a local user group or a development shop that may be willing to have regular meetings with you to show you the ropes and review what you’re doing. My office has been good about allowing me to do this through community training and user group interaction. Part of the reason for this is that my projects are on sound foundations and they value the fact that I don’t waste time developing terrible code…