The unconferences were designed to bring together professionals from the local government digital sector to discuss common challenges for people working in the sector. They were also put on to foster collaboration and to encourage more councils to sign up to the Local Government Digital Declaration (LGDD). The Declaration was launched in January 2018 and already has 145 signatories.
Before we broke out into groups to discuss topics suggested by the delegates the LGDCU project and technical leads talked about their goals. There was heavy emphasis on their role in facilitating collaboration and shared fundings.
The talks covered Local Digital Fund (LDF) support for digital collaboration projects, free GDS academy training credits for LGDD signatories, the 16 projects currently in flight (10 discovery, 6 alpha) under the Unit’s supervision and Pipeline as a place to open source and share builds. There was also a very cool talk by the digital guys from Barking and Dagenham on their Social Progress Index.
The topics that were covered in the breakout sessions can be seen in the following graphic.
Too many to attend them all!
I chose to attend sessions on data and APIs, how to gain leader support for digital transformation, successful digital delivery and procurement decisions.
From a Digital First perspective it was great to hear other councils talking positively about the design pattern library we have created to guide our web and app builds and have now opened up for others to share. It was also great to talk to Bloomberg’s smart city representatives who were very interested in our IoT housing sensor project.
Coming back to Brighton and Hove I felt enthused about what is happening in local government digital and will recommending that our council sign up to the Declaration at the earliest opportunity.
Follow LGDCU at LDGovUK and #fixtheplumbing #localdigitalfund
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.
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.
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.”
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.
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)
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.