Behind the Scenes at Global-Roam

You don’t have to of read much of this blog to realise that over the last few months Global-Roam’s software development practises have been changing as we adopt a more structured, and more agile, approach.

As has been made clear by a recent visit by Steve Hayes from Cogent, and our other attempts to learn more about agile, there is a thousand ways we can improve. This makes it easy to be stunned, like an animal caught in headlights, and instead do nothing.

So last week, Stephen and I worked out what the next level of low hanging fruit was, and have put together this plan to reach it.

Revisions to our iterations

Over the past couple of months we have been doing extremely frequent iterations of only 3 days coding, and 1 day testing. Whilst we have been able to deliver significant business value during these iterations we feel the time in each release is too tight so we are stretching our iterations out to two weeks.

We are also introducing a few new “events” to each iteration:

Planning Meeting

This meeting will be held on the Monday morning when a sprint starts. During this meeting we will be doing proper developer signups when the developers can choose which user story they wish to work on.

Brown Bags

We already have lunch delivered on Fridays, so the brown bags themselves will be unnecessary. But nevertheless each Friday at lunch we will be allowing time for our developers to share knowledge about code that they have written or investigated.

Show Cases

At the end of an iteration we will be more proactive about showing the new version off to everyone in the company.

Retrospectives

At the end of each iteration, and even more so, at the end of each major new version of our software we will be spending time to understand what we did well, and where we can improve.

A different testing structure

We are moving towards Test Driven Development (more on that later), but will still always need manual testing. We will be moving this forward a day so that we have more time to fix errors in the current iteration, and also to provide us with a proper “release day”.

Hierarchy of Environments

We are going to become more savvy about the level of access we provide to the regular releases of our software. Recently we have found that bugs that we missed during our test day quickly came up when we showed the software to clients, but by then the installer has already been available on the web.

We have previously adopted an approach where for each major release, versions x.0.x (i.e. 6.0.1) were strictly internal, x.1.x (i.e. 6.1.6) are public beta, and x.2.x (i.e. 6.2) is our “stable” version. Instead we will have 4 levels of access (or “environments”, and as a version proves itself it will be promoted between the levels.

As a company we lean towards pragmatism in the given situation rather than strict rules, but here is an example of how our hierarchy of environments may look:

• Developers - There are no limits on what developers have access to. As such, the most recent version they’ll use will come straight out of source control.
• Internal – Once a version has been given at least a day of manual testing by the developer team it’ll be cleared for use internally. We’ll put it on our display machines, and use it when we do visits and web conferencing to get client feedback or do marketing. This way, we’ll hopefully catch any huge errors before they get to our users.
• Beta – After a week of internal use, we’ll make the version available to install from our web site. But with the caveat that it is a beta and thus may not be suitable for organisations with lumbering IT juggernauts. It is still in development after all.
• Stable – After a month in the wild, if we find no problems, we may make the version our officially supported “stable” release.

Organising Jira

We use Atlassian’s Jira for our issue tracking. It has served us well over the years but recently we have noticed that it doesn’t quite fit the way we do software development.

So we are re-configuring our Jira installation (which is remarkably flexible) to fit our needs. Our new structure will support us all the way from when a client first makes a complaint or suggestion, right through the investigation of possible solutions, and down to the instructions we give our developers. There will be a more detailed post on this  later.

In fact, we have already spent the last few days setting this up, and will be testing it on the next release of NEM-Review.

Code Standards & Principals

We’ll be adopting a common set of code standards and principals, to help us work together and also motivate good code.

There are several different forms that this takes.

• Text Structure – Conventions about the naming of variables, and where {‘s sit in relation to function declarations.
• Code Standards – Stuff like using the EventHandler<T> delegate when creating events
• Project Structure – The way we organise projects on source gear to fit into our testing structure.
• Principles – Ideas like “don’t over-engineer” and “sustainable pace”.

At this stage we are more concerned with the items lower down the list.

Estimation

We’ll be assigning maximum and minimum estimates in “story points” to our user stories via estimation poker. Over time we will track our velocity and get a better understanding of how much we can do in each iteration.

Pair Programming

We are going to experiment with pair programming. At first we will just try it on the larger or tricker user stories and see how we go. We will make a determination of how well this works for us after trying it for a few weeks.

In fact, our first experiment with this was just last week.

Test Driven Development

We are moving to test driven development – starting with the next iteration of NEM-Review. After looking at the different versions we’ll be using NUnit for our automated tests, as it is the simplest tool that meets our needs.

Personal White Boards

Today Stephen went over to Office Works and bought us all personal white boards. There is nothing better to create designs and share ideas between developers.

Tags: Agile, Agile Software Development

This entry was posted on Monday, February 22nd, 2010 at 5:24 pm and is filed under Methodology, Project Management, Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.