On growing our team, cost of delay and a book you must read.
The next quarterly release for our finance and workforce systems goes live at the weekend so the last two weeks have been filled with testing. I’ve also been progressing the recruitment to expand our engineering team with interviews, evaluations and feedback. There will be more to do over the coming weeks such as following up references and issuing offers. Although it will be a little while yet, I have also started to get to grips with our onboarding process and how to help our new people make a great start under the COVID restrictions.
After discussing the idea for quite a while we are now seriously experimenting with cost of delay1 as a tool to help us make smarter decisions about priorities and allocating our scarce time.
These can involve uncomfortable conversations because we are sometimes asking people to contemplate waiting when their work has been sitting in our IS backlog for some time. It can also be uncomfortable talking about costs when people are, quite rightly, more concerned about the impact to our services or the risks to our staff and the people we serve. We are starting to find practical ways to model these non-financial concerns in terms we can use with cost of delay.
We need to keep experimenting but, so far, things are going well. In some cases it has helped us identify requests which are of relatively low value and release people to get on with workarounds rather than fruitlessly waiting in the IS queue. We have had other examples where we have been able to create capacity to do the work because we can demonstrate it would be more expensive to wait for our existing capacity to become available. There is other work that falls between these extremes where we can use the cost of delay to schedule work in the most cost effective way.
I’ve finally got round to the final chapters of Sooner Safer Happier2. I started enthusing about this before I finished the second chapter. Jonathan Smart will not realise this but he has written a book about how we are approaching agile ways of working at Cornwall Council.
Like Jonathan, we’ve been inspired by a body of knowledge about agile ways of working but we’ve learnt some hard lessons along the way. We’ll use ideas from frameworks such as Scrum3 and SAFe4 but we won’t follow them dogmatically. Our job is to develop great public services. Using agile ways of working can help us do that but it isn’t an end in itself.
As well as the content, I really like the structure which makes it easy to dip back in and re-read parts when the need arises.
Over the last two weeks I’ve attended another meeting of our race equality forum5 and coached at another codebar event6. I’m feeling more comfortable in both of these settings but now I am wondering if that is complacency rather than effectiveness. How do I put this to the test?