Weeknote 27-31 January 2020

On making connections, agile training and recycling sticky notes.

About agile in Cornwall Council

We are starting to adopt more agile and open ways of working. We have been experimenting internally with weeknotes^[1] and, with a little time lag, we would like to see what publishing these might achieve.

This week I have been trying to extend our links across and outside of the Council. Our HR department has been pleased with the agile way they have been working with one of our product teams and I am going to help them try some of these ideas for their own, non-IT, projects. I’ve also been working with a cross-functional team to build a backlog of opportunities to improve resident satisfaction. This will help get the ideas into shape and the service teams ready so we can then pass them into our IS priorities.

Outside of the Council I attended the Cornwall Geeks meetup in Truro on Thursday. There was a wide range of very smart people including developers working at Wikipedia, ARM and a company handling nanosecond timing for communications networks. One regular travels over from Cambridge to join in most months! It felt a bit awkward meeting strangers in a bar but it is a welcoming crowd and I will try to keep going.

Outside of Cornwall, I managed to call in to the virtual OneTeamGov^[2] West meetup^[3]. Similar groups in London have been able to do a lot to share good ideas and help each other. It is more difficult to organise in our region but we are going to try.

I am also trying to introduce teams working on similar things in other Councils. I am hoping Oxford and Manchester can learn a few things from our our Bring Your Own Device team. I also reached out to a group of Councils who are working together to rebuild their websites to see if we can re-use their ideas and, perhaps, some of their research, design or development work. Solihull and Durham use the same call centre system as us and are going to share what they are doing on call recording as our fast change team are going to start work on this next Sprint. These contacts have been thanks to the Local Government Digital community^[4]. I am sure we can get a lot more done by collaborating.

Adventures in agile

Last week many of our team attended certified Scrum Master training^[5] (UPDATE I think everyone passed the exam). This week I starting working through a load of parking lot items we couldn’t cover during the course. The list covers a lot of different topics such as how to adapt the ideas for non-software products, for example, physical infrastructure, and how realistic is it for teams to run without a traditional controlling manager. In some cases we can guide people to great resources outside such as articles and videos from conferences and generous practitioners in the community. In other cases we are going to need to run workshops to get into the details and create our own answers. We will track some of the big items through team Bumblebee^[6]. Other topics that have come up this week include:

• Making good use of skills that are shared across teams, such as cyber security specialists, architects and agile coaches(!), as we don’t have all the skills to do the work in our Scrum teams.
• Working out what parts of an agile approach to adopt in teams that are learning and gaining experience whilst keeping the day job going.
• How to handle multiple and, sometimes, clashing priorities, for example, where we are trying to support independent business teams on a common technology platform.

There are some ideas which come up repeatedly in these sort of challenges:

• Understand the nature of the work that you are trying to do. Scrum is a framework for product development but not all of our work is about developing products. Some of it looks like consulting, case work, repetitive process or purchasing. Some of this work, e.g. fixing software defects is close enough to product development to fold into Scrum. Other work may be better addressed by others sorts of agile technique such as those inspired by manufacturing.
• Understand the nature of the risks you face. You can take risks and try things in software because it is relatively easy to undo what you have done if is doesn’t work. The risks of getting things wrong with data, relationships, contracts and physical assets are different and need to be managed in a different way. You might still be able to get a lot of benefits from using agile approaches (unlock talent, work as a team, create in small batches, get quick feedback) but you may also need to put effort into up front planning and design.
• Maintain focus on making progress. You can usually get close to the right answer by trying to make visible and valuable progress. For example, publish something from the team every sprint, leave each meeting with something the team didn’t have at the start. In isolation, you may still be frustrated that your original idea did not work or that things go too slowly for your liking but slow progress is better than none at all and the small, individual steps do accumulate.

A word about a good cause

Like many digital and agile teams we tend to use sticky-notes and felt pens to help create an engaging and inclusive^[7] environment in workshops and team sessions. The environmental impact of this has come up at work and I joined in a Twitter debate with others having the same thoughts. My personal conclusion was to keep using them in moderation but make sure we buy recyclable ones.

Footnotes