Weeknote 8 - 12 February 2021

On agile experiments and coaching new developers

Doing

It’s been a really mixed week. Here is a random selection of my work.

• Developing options for how we organise support for our finance and workforce systems
• Drafting role profiles which will help us model the cost of the different options
• Drafting a value proposition to make clear the benefits we get from these systems
• Triggering our contingency plan to minimise the impact of delays to one of our projects
• Attending three events with other councils to share experiences
• Looking at how ideas such as Cost of Delay^[1] can help us make smarter decisions about our work
• Working out how we can better support mobile staff who don’t have access to laptops and fast data services that the majority can use
• Continuing our pilot of the cross-government self-managed learning course^[2].

Trying

Last year we launched some big changes to our finance and workforce systems. The work was organised as a big programme which, for several years, dominated the working lives of the teams involved. We’ve been taking steps to move from a programme world into a product world and, along the way, adopt some of the agile tools and techniques which have proven successful for other products over the last year or so.

The latest step is to trial sprint-based^[3] working with one of our functional teams. As well as local experience from our other product teams we are tapping into a national body of knowledge and experience based around the UK Government Service Standard^[4]. Some people are really confident this will make a big positive difference. Most will judge based upon the experience of the next few weeks. I am most impressed with the few who are almost sure it will be a waste of time but are giving us the benefit of the doubt. Everyone thinks the way we work needs to change. We will run a few sprints and see what results we get. If it works for the team we will keep going; if not, we will try something else.

Why aren’t we just copying what has worked for other teams? We aren’t copying as we have seen that, generally, copying doesn’t work. The underlying principles seem to be working everywhere we apply them but the specifics depend upon:

• needs of customer or users
• the skills and experience of team members
• the nature of the work
• relationships with suppliers, supporting services and other teams
• constraints such as funding and capacity.

We probably can’t even copy between the teams who share our finance and workforce systems. Even though they share the same systems these teams have very different skills and experience and do different things - running payroll is completely different to running recruitment.

Some of our product teams have been working in sprints for over a year but they are not staying still either. They are starting to look at what has worked well within their teams and see what improvements can be made by joining up teams. Some people call this sort of thing “Scaled Agile” but I prefer to think of it as just “More Agile”. We have a few people in the team who have experience with popular scaled agile frameworks^[5] and we are taking inspiration from other organisations^[6] including other Councils who are further ahead. Ultimately, we will still need to create something specific to us given our level of knowledge and experience, and the local decisions that have been taken about organisation and governance.

Caring

This week included another virtual codebar^[7] event. I worked with one of the students I helped in December and it was great to hear that they had started a job as a developer. We worked on some technology that was new to me so most of my contribution was around general approaches to solving problems rather than specific help with the technology. Students and coaches are matched on the day so there wasn’t really a chance to prepare but, on reflection, there were quite a few ways I could have helped more. For example, at the beginning, I reacted too quickly and tried to understand the unfamiliar technology so that I could solve the problems. I was acting more like a bad teacher than a good coach. This student was now a professional developer and didn’t need me to come up with answers. What they wanted was help to find new ways to think about the problems so they could find the solutions themselves. I will do better at the next event in March.

Footnotes: