Deputy head of digital comms Alex Pardoe on how our newly-formed content team has transformed the way we deliver content.
This post is about the new way of working for the Digital Officers. Where previously we assigned project work to individual staff members through the project framework, now we’re assigning projects to the newly-formed “content team” and they’re using a modified version of Agile Scrum to get them not just done, but done-done.
Scrum for content?
Scrum has been used for years in software development, and we liked it for its simplicity and open-ended application. We felt it could work well for discovery and content design work as a team activity. Jeff Sutherland’s wife, Arline, adopted Scrum practices to improve communication and productivity in local churches. It’s not just for coding.
Scrum team principles
As Scrum absolutely needs a teamworking ethos, we defined six principles that would underpin everything we’d do as a team:
- Teamwork for the win
- Fail fast
- Iterate
- Nurture momentum
- Show over tell
- Leave no debt
Roles and responsibilities
We also had to match the roles and responsibilities from the classic developer-focused Scrum team to our content team:
- Senior developer = Digital Manager as team leader
- Developers = Digital Officers
- Scrum Master = Deputy Head of Digital Comms (the servant-leader)
- Product Owner = Project sponsor, from within our team or external
Ceremonies
Scrum’s simplicity is very attractive but demands a lot of organisation in and around the core ceremonies. We adopted the following:
- Sprint planning (3 hours)
- Daily stand-ups (15 mins)
- Sprint review (~1-2 hours)
- Sprint retrospectives (1-2 hours)
Artefacts
Scrum isn’t bureaucratic, which is great. But there needs to be some paperwork! We’re using:
- Backlog – spreadsheets
- Planning board – Trello
- Calendar(s) – Outlook
- Reports – Word/PowerPoint, whatever’s appropriate
Making it work in a complex environment
A big challenge was how to best structure the regime so that the ceremonies and work between them could integrate within our already too busy lives. I held a workshop with the team so they could find the answer with me. The result is, I think, rather neat!
We identified three ‘modes’ for team sprints:
- Discovery – why, where are we now, what do we want to achieve, metrics
- Delivery – content strategy and design, building a better website
- Downtime – it pays to take a break
We identified a routine schedule for sprints that fit across our availability, ensuring all team members can attend the ceremonies:
- 3-day sprint (short)
- 8-day sprint (standard)
- 13-day sprint (extended)
Wednesday is the start of a sprint with sprint planning in the afternoon. Sprint reviews and retros are conducted on Tuesdays. Putting the schedule and modes into practice means that every sprint is followed by another sprint in continuous cycles. Again, rather neat!
The mode and schedule are determined in the project board meetings that run weekly on Wednesday mornings. It’s here that the duration of and mode of each sprint are determined.
How’s it going?
It’s going really well! A series of blog posts from the team about content sprinting will be coming soon.
Feel free to get in touch if you want to know more about any of this.
Alex, this is great to read about! We are in the process of moving to agile ways of working at the Department of Education (Victoria, Australia) and it’s always good to hear about how others are succeeding (or at least failing fast and correcting quickly). Due to the size of the Department and some of the governance and delivery overhead, we’ve got a lot of alignment between new and old that we’re currently trying to resolve. Great to read about your journey thus far and to hear you’re doing well!