I’ve been Coaching Scrum for government agencies in Canberra (Australia) for quite a few years now. It’s an ideal framework for managing product development and support because Ministers can change their minds about policy or suddenly announce new ones and it enables systems that support the machinery of government need to adapt to new technologies, new stakeholder needs. I’m finding, though, that while many agencies have attempted Scrum in the past, unfortunately many have had mixed success and sometimes failure.
What does it take, then, to produce results when using Scrum in a highly regulated, hierarchical, and often risk-averse culture like a government organisation? Here’s my top 5 tips:
1. Adopt all of Scrum, not just the bits you like
You adopt an agile framework to create change in and improve the way you work. When you take a smorgasbord approach to Scrum, and pick and choose the bits you like, you don’t end up adopting Scrum. You end up just maintaining the status quo.
Some people start out using Scrum only to find that the Daily Scrum (or “stand-ups”) doesn’t work for them. So, rather than meet daily, they change it to twice a week or abandon it all together.
Since Scrum is based on empiricism, its key events help to identify issues and help the team to improve. If key meetings aren’t working well, rather than discard them, identify the key events that aren’t [apparently] of value, identify what’s the root cause, and act upon it to improve the Scrum’s efficiency. And if you really want to change the way you work, adopt the whole framework first, get to know how to use it well, and then contextualise it to your needs by adding different patterns on top.
2. Continuous planning is needed, not just upfront
The ANAO [1] suggest that estimates of project costs and timeframes at early stages of project planning are likely to be inherently uncertain. Scrum helps managers, Product Owners and the team undertake detailed planning on a continuous basis that builds on earlier planning to remove ambiguity and produce clarity around tasks, deliverables and outcomes. This confirms business needs are sufficient to guide a project to deliver planned outcomes that are of value to the project now and avoids, therefore, wasted planning effort and issues associated with the risk of unrealised expectations amongst stakeholders. To be successful, though, adequate time has to be made for planning at the beginning of the Sprint, as well as mid-way through to review with the whole Backlog with the team prior to the commencement of the next Sprint. Ultimately, planning is the same as in hiking or even warfare: when the terrain differs from the map, trust the terrain.
3. Governance is key to enabling removal of impediments
There’s only so much the team can influence. Good governance ensures that those on a project board or committee have been selected because, should the project hit a bump in delivery, these individuals can act to help move the project along. This can encompass anything from procurement of servers for integration testing through to influencing other teams to assisting in providing requirements in a timely way. One important factor to consider is how involved business stakeholders are in contributing to items in the Product Backlog and informing the Product Owner of their needs and priorities. When the Project Owner is informed, they’re empowered to act on behalf of internal and external stakeholders so that each Sprint achieves its goals and delivers value.
4. The Scrum process produces transparency and accountability, not reporting
Most projects are used to creating reports of current activities to increase transparency about what is going on in the project — current goals, milestones and risks. Scrum itself produces transparency with its key meetings, like the Daily Scrum, and its artefacts like the Product Backlog and Sprint Backlog.
One of the keys to successful Scrum is to recognise the simple artefacts that come out of the framework that can be immediately used for reporting.
- Sprint Backlog – What the plan for the team this Sprint.
- Product Backlog – What the team will deliver next.
- Increment – What the team produced last Sprint and is potentially releasable.
Even if the project operates in a PRINCE2 environment, there are many equivalences that can be drawn between PRINCE2 reporting artefacts and key elements that are produced by Scrum. I find that the synergies between the Scrum and reporting work best when both cycles are 2 or 4-weeks in length — so when a Sprint Goal has been defined, the previous Sprint’s achievements are reported along with the next Sprint’s goals.
5. Your team doesn’t know what they don’t know — it’s why a coach matters
It’s very difficult for most teams to be accurate in their introspection and identify what it is truly doing wrong and what factors will contribute to improvement and success. Scrum coaching goes beyond training. It’s designed to take the guessing game out of why, for example, a team might fail to achieve their Sprint Goal, or why certain Waterfall-style behaviours might actually impede the success of a Sprint. Overall, a coach helps teams to learn, improve, become more efficient, and helps to reduce the risks associated with the team’s behaviour impacting adversely its ability to deliver. One key factor in choosing a Scrum Coach, however, is finding one that understands the needs, accountability, and processes of government, and can frame Scrum in a way that aligns with this vital perspective.
Conclusions
It takes both a sound knowledge of Scrum and an applied understanding of how to use it in order to reap the benefits that this agile framework has to offer. These 5 tips only represent a fraction of what’s required for successful adoption. For more information, request a copy of our whitepaper — Agile Adoption in Government.
– – –
1. Australian National Audit Office (2010) Better Practice Guide. Planning and Approval – an Executive Perspective.
