How do you set up an agile software development project infrastructure?

Setting up an agile software development infrastructure will vary depending on the context. By context I mean what type of software it is, what type of team it is, what type of company it is, what’s the culture like, what tools do you have? These things vary from company to company, project to project and situation to situation.

However, there are some things that I would always do to set up an agile infrastructure from scratch regardless of the context:

Visualise a product backlog

Start by knowing what work there is to do and visualise this in the form of a product backlog. This may be as simple as a spreadsheet with a list of items or as complex as a Kanban board where you can visualise the product backlog and the flow of work through the development process.

Set up a planning process

In Scrum at the beginning of every sprint (usually every two weeks) you do sprint planning. Even if you aren't following Scrum, you do need to do regular planning and re-planning. The frequency could be anything from weekly to monthly; you probably don't want to go beyond monthly. This then becomes your planning cadence.

In our experience the sprint or iteration planning is between a one and a four hour period of time when you get the whole team together to look at what things from the product backlog you are going to do in the next sprint or iteration.

Set up a review process

You need to set up a process where you get feedback from your business or your client. It doesn’t necessarily need to be the same cadence or regularity as your planning cycle. In Scrum it is, but it doesn’t have to be. On one of our most recent projects, we had weekly reviews with our client to start with and we found it was too often. We found we weren’t getting enough done in a week to be worth showing the results to our clients. So we changed it to fortnightly. On this project we were doing weekly planning and fortnightly reviews.

Set up a retrospective process

Retrospectives are when the agile software development team looks back on what they did in the last period of work and reflect on whether improvements can be made to the approach. Again the cadence for this doesn’t need to be the same frequency as for your planning or review processes. At Equinox IT we do this monthly for an established team, or more frequently for a new team or a new approach.

Establish a mechanism for tracking progress

Earlier I stated the need to establish a process for sprint or iteration planning. But, how do you know that you are on target to do all that work that you planned for the sprint or iteration? On agile software development projects typically people use a burn down chart to track outstanding work versus time remaining. This allows them to visualise whether the agile team is on track for the sprint or iteration.

Next, consider how you will be able to know you are on track for the overall project, to deliver an application that has all of the features that the customer wants three or six months from now. In other words how do you know you are planning enough work into each iteration or each sprint to meet that longer term deadline? For this you need a more coarse grained burn down chart or equivalent mechanism. If you are estimating your work using story points or any other unit, then you need to track that you are delivering enough of those units in each iteration to be able to meet that longer term deadline.

Start trialling and adding in other agile practices

Once you have the above mechanisms and routines in place, you have a platform to start working in an agile way, but it is not everything. That’s one of the things about Scrum, it only tells you how to organise your teams to do the work or what work to do. It does not actually show you how to do that work.

So agile development practices and XP practices such as test driven development (TDD), acceptance test driven development (ATDD), modular, loosely-couple code design, pair programming and code reviews are not covered within Scrum. These are things that you can pick and choose from.

However, some of them you need to establish from the start as they are difficult to add later. Practices relating to the design of your code or test automation in particular are the hardest to add later. Some teams have a team charter, project charter or a quality management plan that dictates the sort of up front things that the team is going to do. So one of those might be 'we are going to use test driven development and we are going to achieve X% coverage'.

Having code reviews, pair programming and daily stand ups are things that you could introduce incrementally as you go through. Then you can review the impact of them, whether it was worth it and whether you want to continue with these practices.