Since a few weeks we’ve really truely implemented some agile methods in our biggest project (Jongeren in Beeld). Since others may benefit from knowing how we have approached this, I want to share our implementation of the agile approach of software development in a PHP project with the world.

First of all, I actually wrote a document to outline these guidelines, as in our company (and I guess a lot of other companies) as long as it’s not documented, it won’t be followed. So I guess you could call that tip #1 😉

Iterations

An iteration is a certain set period of time during which the developers work on implementation a set of features and/or fixing bugs. An iteration always results in a release. The definition of “release” here is a stable enough codebase in the development branch to deploy safely on the testserver. More on this later. The length of iterations for us is three weeks, where one week overlaps. So the last week of iteration 1 is the first week of iteration 2. During the first two weeks of an iteration, the developers work on implementing the features. The third week is for testers to test the release, and (when the choice is made to do this) deploy the release to the production environment. So basically, the developers are always busy with implementing new features, but once the testers are working on testing the application, they may need to fix minor bugs so as to get a truely stable version that can be deployed to the production environment.

Meetings

There are two very important meetings during an iteration, and aside from that every morning has a short morning stand-up meeting. Let’s first have a look at the important meetings:

• On the first monday of an iteration at 9:30, all stakeholders gather for the planning meeting. During this meeting, all stakeholders gather around a PC on which our Trac installation is open, and discuss which features should be planned for the upcoming iteration. The list of planned features should be a little too long to be realistic. Since the rule is to always be able to deliver a stable version, it is not bad if some features won’t actually be done this iteration. It’s better to have too much planned than too little planned, or the developers might be sitting around doing nothing 😉
• On the second thursday afternoon, at 15:00, the closing progress meeting is being held. During this meeting, all stakeholders should gather to have a look at what progress is actually made during the past two weeks. Also, based on the list of implemented features, the testers may now be able to write their test plans. Based on the list of implemented features, during this meeting already the decision may be made that this release should end up on production.  

The short morning stand-up meetings are just that: A max of 15 minutes is set for this meeting, and during this meeting, everybody will tell what has been done since the last stand-up meeting, what is planned until the next stand-up meeting, and if there are any issues that might block the developer from making that planning. This meeting is held while standing, so as not to get comfortable and have endless meetings talking on things that are not relevant. Save that for the coffee machine 😉

Whiteboards, sticky notes and Trac

The list of tickets to work on is being tracked in several ways. In our room, we have a whiteboard that is divided into sections very similar to the drawing on the cover of this book. Each ticket is then written on a sticky note: That is, it’s ticket number and short description. Aside from that, all tickets are in Trac. For each new version, a “Version” in Trac is created that is named [version number]-TODO. All tickets that are being planned for a certain version are assigned this version number. As someone is working on a feature, the sticky note is moved to the “In Progress” section of the whiteboard, and the ticket is “accepted” in Trac. As a feature is done, the sticky note is moved to the “Finished” section of the whiteboard, and the ticket is closed.

Version and Release Control

First, let’s talk about the procedures concerning version and release control, and after that have a look at the technical infrastructure supporting these procedures. A developer should test his own code while developing. At this point, we are not (yet) too strict on the existence of unit tests or functional tests, but the developer should definitely try out the new functionality he implements. In theory, ONLY STABLE CODE SHOULD END UP IN OUR VERSION MANAGEMENT SYSTEM. The reason for this is simple: Since the holy aim of an iteration is to have a stable release after two weeks of development, you never ever want to have unstable code in your repository. If you have, you may not have the time to fix this before the end of the two week period. And at the end of such a two week period, the release should be stable enough for testing. So, ONLY COMMIT STABLE CODE.

At the end of the two-week period, a release is made by tagging the code that is in the development branch at that time, with a ‘-test1’ postfix. As new releases are made during the third week after bugfixing, the number at the end of the postfix may get higher. As the testers sign off the latest test-release, this latest test-release is then tagged as [version number]-final. This -final release is exported, then deployed to the production environment according to strict planning guidelines (I’ll discuss this later). Development is always being done in a development branch. This branch is created from the trunk on the second friday of an iteration (basically, the last workday before a new iteration starts). This branch is named as [next version number]-dev, and all developers should commit to this development branch. These are exceptions to this: If during the planning meeting it is decided to implement a feature that will take more than the two-week span of development during an iteration, a seperate development branch for *only* this specific features is created from trunk. The new development branch is not created before the old development branch has been merged back to the trunk, the get the trunk updated with all the new functionality.

Version and Release infrastructure

For ticket tracking, we use the Trac software. Reason for this is the tight integration with our version management system, enabling us to have a simple overview of which changesets are related to which tickets, as well as easily seeing which files have been changed for which reasons. For version control we use Subversion. We heavily rely on it’s branching, tagging and merging techniques.

Deployment planning

We have very simple but effective rules concerning deployment to the production machine:

• No deployment will happen after 14:00. If something goes wrong with deploying, you may be working into the night if you start deployment after this time.
• No deployment will happen on friday. If something goes wrong with deploying, you may be working into the weekend if you deploy on friday
• No deployment will happen of big features if there is no extensive deployment plan and rollback scenario. For deployment of bugfix releases or minor updates, a short rollback scenario as well as a database changeset is required.
• Deployment should always be planned at least a day ahead. The latter rule is not strictly enforced, but it is a good guideline to prevent surprises and allow for good planning and preparation.

Deployment to the test server is not affected by these rules, since the test server (even though important) is not critical to have down during a night/weekend.

That’s about it

I hope this is of any use to people out there. If you have any questions, feel free to contact me. I’d gladly give some advice where needed. I know for a fact that ever since we started working in this pretty strict way, the quality of our code as well as our external communication have improved bigtime. Clients will love you for this.