On always changing things, better priorities and remembering.
This week we started testing the latest quarterly release of our finance and workforce systems. As the big implementation project winds down the quarterly releases will probably become our main development heartbeat. We take these systems as a public cloud service and the supplier does much of the work to maintain and develop them. We’ve agreed a fixed quarterly timetable with our supplier and there are good and bad parts to this. It is good that we can’t put off updates and store things up for a big, painful upgrade in a year or two. Unfortunately, we cannot postpone an update for even a couple of days if something isn’t working for us.
On balance, I think the good parts outweigh the bad1. This is our third quarterly release since we went live with these systems and they are starting to feel more routine and less like a frantic imposed project. We have a two week testing window but, this time, we completed most of our critical testing in a week. Teams in finance, procurement, people and payroll are more in control with guidance and support from IS. Earlier releases were tightly controlled by the IS team.
When we are ready, I want to go further and have a shorter development cycle. The quarterly releases will remain but there are patches, optional features and external data flows which don’t need to wait. I’m imagining quarterly tides with smaller and more frequent waves in between. There are a few things we need to sort out before this will work. Some are planned, such as filling some of our vacant posts. Others are under discussion, such as shortening the time it takes to get issues resolved with our supplier. A few haven’t been tackled yet, such as automated testing.
I ran another regular retrospective for one of our infrastructure teams. A couple of weeks ago the team raised the issue of distractions taking their time and attention away from their planned work. It seemed interruptions from outside the team were the main problem. This time, distractions were still the main thing the team wanted to address but the spotlight had shifted to things coming from within the team. I followed up with the Delivery Manager and will need to catch up with the Product Manager next week because it will need their influence and authority.
At our Team Bumblebee2 session this week I proposed some ideas to develop the way we prioritise our portfolio of work. Our Programme Management Office (PMO) team have made massive improvements to this in the year I have been working for the Council but we had to start with something simple. This enabled us to get control but has had unintended side-effects. Large bits of work tend to crowd out small fast improvements which might, in aggregate, have more impact. Strategically important work tends to get postponed in favour of urgent tactical work. We can mix these things together into a richer portfolio but not with the simple prioritisation that has got us this far. Some of the team have used more advanced approaches before joining the Council, such as Cost of Delay3, so we are going to experiment with some of these ideas using support from Team Bumblebee.
This week I joined a virtual meet up organised by Software Cornwall which covered things like psychological safety and the impact COVID restrictions are having on our teams. I also had a catch up with the cross-government team that has been rolling out a new self-managed learning programme about developing digital public services.
Like many events this year, the Council’s remembrance ceremony was online. Once again, the organisers made good use of the tools we rolled out during the lockdown to create a really poignant event.
If you want to know more about Cost of Delay you should probably start with Don Reinertsen’s work. In the Council we may need to blend this with other approaches as it will be difficult to assign an agreed monetary value to all of the things we are delivering. ↩