Agile for government can be a very different kettle of fish than Agile in the private sector. It’s an alien context, it’s resistant to change and it’s used to playing by different rules. All the same, Agile offers fantastic opportunities for government software development, and the good news is that the public sector can learn from some of the mistakes made elsewhere.

1. Treating the Scrum Master as a traditional Project Manager

The Scrum Master has two main responsibilities:

1. Ensuring the team lives and breathes the values and practices of Scrum, and
2. Removing the impediments that prevent team members making fast progress.

This dynamic is absolutely central to maintaining a high-performing, self-organising Agile team. On the other hand, if a Scrum Master is more familiar with a traditional command-and-control approach then they may find themselves doing one or more of the following:

• Assigning specific tasks to team members
• Interfering with estimates
• Committing to things on behalf of the team
• Taking over the daily stand-up as an update for the Scrum Master

2. Implementing the processes but not the technical practices

Just because Scrum doesn’t mandate technical practices doesn’t mean they’re not important. Technical practices help to ensure that the quality of the code base remains high – and that changes can be made efficiently and with immediate feedback. Without these practices then you risk gradual stagnation as a more complicated code base starts to bog down new development. Worse, there may be a reluctance to make changes to existing code in case you break something. Since a core Agile principle is ‘embracing change’, that’s not going to do you any favours.

3. Having separate BAs and Testers

A classic mistake is to regard developers as ‘The Team’ and see Business Analysts and Testers as part-time members who have other commitments and priorities, and even a different management hierarchy. Agile relies on quality communication within self-organising teams – and BAs and Testers are a core part of that. They need to collaborate with the developers and each other throughout the whole Sprint, not just at the start or end. Having them as full members of the team is the only way to do that effectively.

4. No retrospectives or bad retrospectives

Agile processes adapt and evolve as they go, along with the product being developed. Regular retrospectives are an important element of the process, but they’re often one of the first casualties when things start to get difficult. Even when they do take place retrospectives aren’t always action-orientated enough, or else actions aren’t followed up.

Retrospectives need to continue even if things are going really well. Circumstances will always change and taking a regular pause for feedback should help to catch any problems that are beginning to creep in – before they take root.

5. The team is Agile but the Business isn’t

This is particularly relevant for government software development, since public sector procurement takes place against a backdrop of top-down bureaucracy and entrenched ideas. For Agile to be truly effective it needs the right sort of engagement from the business. That includes a strong Product Owner who can make difficult decisions and a stakeholder community that has fully bought into the approach. All too often when new teams are starting out on the Agile journey they underestimate the challenges of convincing the business to support them in what they are doing. Moving to Agile delivery is as much about changing culture as it is about changing project processes.