Weeknote 21 - 25 September 2020

On bots, onions and virtual good byes

I’m trying out a slightly different format for this week’s note.

Doing

Robotic Process Automation (RPA) is a fancy name for a simple idea. It basically means getting a computer to pretend to be a human user of another computer program. There are often much better ways to get computers to work together but RPA can be a useful work around to some problems; for example, when it is too difficult to change the program. I’ve used this sort of thing so that people don’t waste time copying bits of data around. With the advanced tools now available, computers can also take on some of the time consuming and tedious data processing that our teams have to do.

Where we can, we design away this sort of work but we also have some instances where RPA might be a useful temporary solution. For example, the COVID-19 crisis is changing the demands on our services. Some manual tasks which are currently a regular annoyance could quickly become an overwhelming bottleneck. This week I have been working on a trial to understand where RPA could help us tackle these sorts of problems.

We are working in a very agile way to develop our new website^[1]. We made some estimates of the effort involved before we started and, so far, we are expending less than we expected. That sounds good, but is it really? Low effort could mean that we are more productive than we thought but it could just mean we are going too slow. Ideally, we would put the new features live every sprint^[2] or so and it would be easy to judge our progress. At the moment, we are also applying a new design and experimenting with new public cloud infrastructure so there will be quite a gap before we know for sure that each feature is done. This week I’ve been going through some hints and tips with the delivery manager to reassure us that the productivity is real and we won’t get a nasty surprise later on.

I’ve written before about how we are introducing light weight agile processes^[3]. This week a small group looked at system implementation. We already have thorough processes for this but they are not always used in the best way or at the ideal time. Learning from some of our earlier work, we have drafted some simple guidelines in the form of a “Ready for Implementation” definition. This isn’t a substitute for the processes and controls but we hope it will help people decide what is right for their particular work. Next step is to iterate it with some of our delivery managers and then add it to our handy collection of “House Rules”.

Learning

We are rationalising the number of tools we use to manage our backlogs^[4]. This week I joined a workshop for one of our teams that is moving from their current tool to join the rest of our department. We all need some freedom to manage our work in a way that suits us but some common guidelines can make it easier to manage bigger bits of work that involve coordinating several groups.

I joined the regular show and tell for our website development^[1:1]. I had seen some of the features demonstrated before but, this time, we got to see how these looked using the new website design. The developers also used our new public cloud environment so the team that manage our website can log in and try things out for themselves.

This week I participated in another workshop on Liberating Structures^[5]. These sessions are a way to both learn about the structures and also help the community work out how to use them online. I must admit I struggled with the “Drawing Together” structure this week but I shared how I felt with the group and got some useful ideas to try next time.

Many agile techniques recommend that a team has all of the people it needs to create and operate the product it is developing. I’ve only worked with one organisation that has managed this entirely. Most people have to call in part-time or ad-hoc help to get their work done. Sometimes this is not a major problem but we have several activities which are regularly being blocked because of this. I’m taking a fresh look at Emily Webber’s work on the Team Onion^[6] to get some ideas to try. At some point we might need to look at merging or reforming our structure to make it easier for people to collaborate on our most important work.

I am going to be getting more involved with the groups that manage some of our big, back office systems, which handle staff and financial information such as budgets, spending, absences and formal approvals. These systems rely on close collaboration between several departments (such as People and Workforce, IS and Finance) so I have spent some time finding out who is involved and how it is organised.

Caring

With the help of some cross-Government contacts I’ve been looking into anti-racism policies. In the UK, most organisation policies on race are based upon the Equalities Act 2010. They probably help prevent many explicit acts of racial discrimination and provide remedies if something has gone demonstrably wrong. I’m learning that this doesn’t go far enough. We are not really treating people fairly unless we also think about unconscious bias, different levels of privilege, systemic racism and the toll that racist crimes on the other side of the world can have on people here. There is a good body of evidence about all of this^[7], but it is also easy to find people who have doubts about the scale of the problem and a few who think further action on it would be unfair to them^[8]. I am going to keep looking but also investigate alternatives. An anti-racism strategy^[9] might be a better way to get the kind of support and action that is needed.

A couple of people are moving on to new things and are leaving the Council - one of them is going to the other side of the World! Remote working has been good for me in many respects but saying good bye over a video call really isn’t good enough.

Footnotes: