Doing the hard work to make it simple – with help from the Local Digital Declaration

We are taking stock and looking toward the future at the moment. Digital First won’t be here forever and we need to start sharing our knowledge and embedding our learning now so that the kind of work we are doing carries on.

At one of our Product Manager meetings, we discussed some common themes causing delays, or blockers.

We decided that one very positive thing that we could do is to make a set of standards to share: what any third party system being bought should have; what APIs need to be able to do; what customer facing elements should be in any new tool.

We have already got an approved set of requirements for any new system so that it will definitely connect to My Account. So we have started, and with a positive mind and open heart will aim to continue.

However, there was no need to make our own set of standards, as the Local Digital Declaration was launched, including service standards and a technology code of practice. It was compiled by central government with lots of local authorities’ input.

Local Digital Declaration

The declaration is a set of guiding principles that will help support local authorities to deliver digital services and platforms that meet the needs of citizens and describes what organisations can do to achieve this. It covers all the common themes that we discussed, which are outlined below along with the relevant part of the declaration in italics:

1        There is a lack of ownership of some decisions. It can be really hard to get anyone to say that the decision is definitively theirs. This happens in all sorts of scenarios when trying to get sign off on product decisions.

The declaration commits co-signatories to “make sure that digital expertise is central to our decision-making and that all technology decisions are approved by the appropriate person or committee. This will ensure that we are using our collective purchasing power to stimulate a speedy move towards change.”

2        There are cross-cutting service elements we need that are either missing or still in the process of being put in place. These can be tools or platforms that allow us to share data, allow customers to tell us once, that modernise how we pay and invoice, or how we book appointments. So we will get quite far with discovery or innovation and then all get blocked by the same kind of elements.

GDS have committed to making their tools available to Local Government as part of the declaration. Work to incorporate Gov.notify with one of our services is in our current sprint. 

Screen Shot 2018-10-04 at 15.12.08

3         Sometimes a different support team develops separately and implements change at the same time as we are already working with a service, meaning staff disengage from our work and our ability to deliver is impacted. Some strands within the organisation are not joined up enough.

The declaration commits leaders, service members, board managers and politicians to “support our workforce to share ideas and engage in communities of practice by providing the space and time for this to happen.”

4         Teams don’t always know about the cross cutting work to create a single system, for example, to ensure standardised data gathering and customer single sign on. If they buy separate products it can severely impact the plans to develop one system and the data that we will get out if it. They would have no idea of this impact and we need to fix this. We need to get that knowledge out there.

Procurement has moved on and we need to catch up with that. We don’t need to buy just one big system anymore. It is possible to buy enough to start and then add on elements that are required, if the right basic system is bought in the first place. We need to share our knowledge about how to do this with the right people.

The declaration commits technology teams and leaders “Where appropriate every new IT solution procured must operate according to the technology code of practice, putting us in control of our service data, using open standards where they exist and contributing to their creation where they don’t.”

As always, the Government Digital Service have co-developed something that follows one of their own principles of doing the hard work to make it simple.

In this case it was our team who benefited. Rather than can create our own set of standards, we now need to spread the word about the Local Digital Declaration and adopt its framework and principles. Then everyone can benefit.

DF volleyball
Digital First doing the hard work to keep things simple

 

Staying cool with Agile

Housing Technology presentation DF with hot weather

You may remember an earlier post about the environmental sensors we have installed in one of our sheltered housing developments. We had intended these sensors to measure high humidity and unusually low temperatures, in order to prevent the development of black mould, increased vulnerability to infections and also to detect early signs of fuel poverty.

However, elderly and vulnerable residents are also at risk when it gets really hot – just as it did during the July heatwave, which now seems like an increasingly distant memory! Towards the end of July, the system which captures the sensor data showed that a small number of flats were experiencing temperatures which never dropped below 27°C, even at night – very uncomfortable and potentially hazardous. We were able to alert the scheme manager, who immediately visited the affected residents and was able to offer advice and support for keeping cool.

Of course, the beauty of the Agile Method is that we are able to respond quickly to new requirements. In collaboration with the integration team in IT&D, we re-prioritised our work for the next sprint, creating a new business rule on our integration platform, Dell Boomi. In future, when temperatures exceed a certain threshold over an extended period, this will automatically create a task in our case management system, iCasework, and assign it to the relevant care worker. We have also successfully tested this approach using the API provided by the GOV.UK Notify service, which will generate SMS and emails containing the information needed by the care worker.

It’s early days yet as we understand better what our new technology can do, but it’s looking very promising.

Value beats umbrellas and onions

I recently did an introduction to Agile training session for the development team at Digital First. We’ve used agile practices for a while but I wanted to put what we do in context. As with most training sessions the first thing to do was to define what we are talking about, in this case – Agile.

Agile is a small word that is surprisingly hard to define in the software development context. Some people will say it is a set of tools and practices. Some will say it is a set of principles. Some will say it is a methodology, a philosophy, a mindset … and so on.

In truth it is an umbrella term which captures all of these views. However, that doesn’t really help trainees who are new to Agile to get their teeth into understanding what it is and more importantly why we are doing it. What I needed was a simpler definition to capture what the purpose of Agile is.

I turned to the internet. Unsurprisingly there were many definitions out there. Some agreed on the umbrella term and had supporting graphics of jolly umbrellas with lots of agile buzz words sheltered under them. Others graphical explanations said Agile was best understood as an onion, the layers representing tools, practices, principles and so on. Both excellent metaphors but still missing the simplicity of definition I was looking for.

Then I found it. A definition that captured the essence of why we do Agile and that rang true to my own experience of deploying it in digital teams.

Agile is early delivery of business value with less bureaucracy (Alistair Cockburn)

That’s it.

When I flashed this up on a slide the team looked happy with its simplicity. Then I asked them ‘what do you notice that is odd about this definition?’ After some brow rubbing and chin scratching someone piped up ‘Wait, there’s no mention of software’.

No mention of software. No mention of digital. Nor even technology.

At first this seems a bit strange especially as we are a software team, but in fact this is what I love about this definition. It succinctly declares the wider context for why we use Agile at all – to deliver early business value. It just so happens we use software to deliver that value.

We use Agile because it’s the best way we know to do this in complex environments with changing requirements and developing technologies. Agile enables us to bring more certainty to our product builds to identify what’s important and to build and ship the high-value parts to the customer early so they can start enjoying the benefits now, not at the end of a long project cycle.

Umbrellas are useful. Onions I’m not even sure we can live without. But value is truly where it is at.