Weeknote 10 - 14 August 2020

On innovation allies, always learning, fighting for flow and more shared learning.

Innovation allies

Team Bumblebee¹ will be a little quieter than usual as we enter the peak of the summer holidays. We had another good session this week with a proposal for some public cloud work from one of our product teams. The product team already had a well developed idea of what they wanted to do but needed some help with funding and prioritising the work. One of Team Bumblebee volunteered to act as an ally to help the team make the case for some investment.

Never stop learning

Some agile coaches may think they have nothing left to learn but I am not one of them. 30 years experience can be very useful but people are complex animals and are full of surprises. Put people into teams and they become a new creature that even the team members have never experienced before. An agile coach does not need to know everything, but they need to know how to learn and how to help people and teams learn. Also, in a fast changing field like IT, what you know can get stale quite quickly. You need to be ready to let ideas go when they are no longer useful.

One of my lessons this week was about keeping people safe. I am grateful to some of my colleagues for helping me learn by challenging the way I handled a situation. I had approached an issue in an open and direct way without taking into account some tensions between a couple of our teams. As a result I ended up creating a stressful situation for some of my colleagues.

I’m pleased that they called me quickly to help sort things out but I should have taken more care. I’ve been working on changing organisations for years. Change can’t happen without a degree of tension and, over time, I have become a bit too complacent about it and have forgotten how it used to feel earlier in my career. I’m glad my colleagues helped me to learn but I’m sorry that they needed to on this occasion.

Fighting for flow

Lots of my work this week has got me thinking about flow. Flow is one of those agile ideas that has been around long before agile became fashionable. In a factory, the flow of parts through assembly and on to distribution is important. In my work other types of flow are important, such as the flow of ideas and needs into improvements to a Council service. The agile manifesto² emphasises the flow of working software features. Thinking about flow can help you optimise a whole system or activity, but it can have odd side effects which can get in the way.

Eliyahu Goldratt³ wrote extensively about this and has loads of interesting stories about having to break conventional management thinking to maximise flow. For example, many managers strive for high utilisation which means keeping a person or some equipment fully occupied. Idle time is a waste and so you might think it is good to minimise it. It turns out that this is only true in isolation. When you look at a service or activity with many steps, high utilisation can result in queues, delays and interruptions which disrupt the flow. This can be more expensive than the waste you were trying to avoid. It is better to suffer some local idle time and protect the flow that you are really interested in.

You probably have lots of examples from your work, or from being stuck in one of those phantom traffic jams which seem to form and disperse without any obvious cause. This is why busy motorways have variable speed limits. Reducing individual speeds protects the flow and avoids the traffic jam which brings everything to a halt.

In my department there are several things which can threaten our flow.You will see similar things where you work, such as:

• queues of decisions awaiting attention from an authorising manager
• inconsistent priorities across teams
• competing demands for the time of engineers in a specialist team
• too much attention on projects to create new systems at the expense of keeping existing things working well.

I think I need to get my copy of The Goal³ out again and be ready to fight for the flow.

A word about a good cause

I joined an online meeting on a new initiative⁴ to build up the digital skills of public sector leaders. To be honest, I was a bit out of my depth and in awe of some of the people involved. A degree in Digital Public Services won’t be for everyone but the group want to find creative, non-traditional ways to get the material out to people. We might be able to use some of this as part of the cross-government digital learning I am involved⁵ in or as part of a local development programme at Cornwall Council.

Footnotes:

1. There is more about Team Bumblebee in a previous week note. ↩

2. The manifesto for agile software development. ↩

3. I really like Eliyahu Goldratt’s thinking and he uses novels in an authentic and effective way to get them across. My favourites are The Goal and Critical Chain. ↩ ↩²

4. Teaching Public Service in the Digital Age. ↩

5. I covered this shared learning initiative in a previous week note. ↩