We had decisions to make, testing sessions to arrange, bugs to fix and staff to prepare for new ways of working. Keeping everything moving around people’s availability was a challenge, but we got there through a huge effort from many teams across the council.
Four applications, lots of moving parts
Over these four sprints, we finalised our two new apps:
- complaints, comments and compliments
- requests for Information
The latter covers the following request types:
- freedom of information (FOI)
- environmental information regulations (EIR)
- subject access requests (SAR)
We also built an internal application for staff to report and manage data breaches, alongside a new application for Members’ and MPs’ enquiries.
Although these applications do very different things, they share quite a lot underneath. They all need:
- clear ownership
- good audit trails
- structured workflows
- reporting
- a straightforward way for staff to see what is happening
Being able to reuse parts of what we had already built definitely helped, but it didn’t remove the complexity. Every service has its own requirements, terminology and ways of working. The closer we got to launch, the more those important differences came to the surface.
That is not necessarily a bad thing. It is exactly what you learn when a system moves from diagrams and demonstrations into the hands of real users.
Working around the people using the applications
One thing that became very clear was that we needed to fit the project around our users, rather than expecting them to fit around us.
For the Members’ and MPs’ enquiries application, that included providing evening sessions for user research and user acceptance testing. Members cannot always attend testing sessions during normal office hours, so we needed to find another way to involve them properly.
Those sessions gave us a much better understanding of how members manage enquiries and what they need from the application. They also reinforced that user involvement cannot be a box to tick at one point in a project.
Every time we brought more people into the conversation, we learned something new. Sometimes it confirmed what we had built. Sometimes it meant making changes. Occasionally it meant going back and reconsidering something we thought had already been settled.
That can feel difficult when you are working towards a launch, but those changes are often what distinguish a product that just works from one that genuinely meets the user need.
The launch was just the beginning
Once the applications went live, we moved into a full month of hyper-care. We ran daily drop-in sessions where staff could:
- see the applications
- ask questions
- report issues
- talk directly to members of the project team
The sessions also gave us a much clearer picture of how the applications were being used in practice.
As more people became involved, we received more feedback. That meant more questions, more bugs and more requests for functionality that had not necessarily been obvious earlier in the project.
For a while, the development team was releasing changes every day.
It was intense, but it was also useful. Staff could see that we were listening and that their feedback was turning into visible changes. The applications improved quickly because the people using them were able to speak directly to the people building them.
Looking back honestly
This week, we brought the major stakeholders together for a retrospective on our first major low-code build at Luton, it was well run, honest and respectful.
We used a 4Ls exercise to structure the discussion around what people:
- liked
- learned
- lacked
- longed for during the project
It gave everyone a simple way to reflect on what had worked well, where we had struggled and what we should do differently next time.
More importantly, it created space for an honest conversation involving all of the teams that had contributed to the work.
The strongest theme was the collaboration between DDaT, Transformation and the lead services. The Complaints, Security and Compliance, and Civic Services teams worked alongside us throughout delivery, bringing different perspectives, challenging assumptions and solving problems together.
None of this was perfect, though, and that is really the point of holding a retrospective.
There were a few themes that came up repeatedly. We need more user research and user acceptance testing, and we need to start both earlier. We need to engage sooner with the staff and members who will be affected by a new application.
We also need a clearer backlog, with wider ownership across the project. Priorities should not be decided by the development team in isolation. Services, product leads, users and other stakeholders need to understand the choices being made and play a more active role in deciding what gets done first.
I think we also underestimated how much work happens after launch. Hyper-care, support, communications, training and rapid improvement all need to be planned early as part of the delivery, rather than treated as something extra at the end.
The good thing is that these are practical lessons. We can do something about them
Building the team we need
The timing of the retrospective was particularly useful because our Digital Development restructure has now been approved, giving us an immediate opportunity to act on some of those lessons.
That means we can begin recruiting to new roles across product management, user research, service and interaction design, content design, testing and development.
Several of these roles directly address what came out of the retrospective: involving users earlier, creating clearer product ownership, strengthening testing and making sure we can support and improve services after launch as well as build new ones.
New roles need to work closely with service teams and end-users, and those services need to remain involved throughout delivery. If anything, one of the lessons from the summer is that we need more shared ownership, not less.
The restructure gives us an opportunity to build on what worked, address the gaps and make this way of working more sustainable.
It is about more than filling posts. It is about developing the multidisciplinary team we need to design, build and continually improve services around the people who use them
Moving into waste
While all of this has been going on, the development team has started moving onto the next challenge.
Over the last few weeks, we have begun building the first of our waste applications. They are due to go live in October and will improve two very common resident journeys: checking bin collection days and reporting a missed bin.
These might sound like fairly simple transactions, but they are used regularly by large numbers of residents. When they do not work well, they create frustration for residents and avoidable contact for the council.
The aim is to make it quicker and easier for residents to find out when their bins are being collected and to report a missed collection when something has gone wrong.
Moving into waste also feels like an important step for the platform. Much of our delivery so far has focused on corporate casework, information governance and enquiries. Waste takes us into a high-volume operational service that affects residents every day.
For this build, we are working with a different project manager, business analyst and group of stakeholders, but using the same platform. It is great to see the platform reaching such a broad range of services only six months after we arrived.
More importantly, we are taking the lessons from the retrospective with us. We need earlier engagement, more user research and testing, clearer ownership of the backlog and more collaborative decisions about priorities
What I’ve taken from the summer
At the beginning of the summer, I was talking with my peers in DDaT’s senior management team about how teams really form.
My view was that we had not yet been through the kind of difficult, shared experience that turns a group of people into a team. Looking back, I can see a clear parallel with this project.
People from DDaT, Transformation and the service teams came together with different roles, perspectives and ways of working. We formed quickly, worked through the inevitable storming as the pressure exposed differences and challenged assumptions, and gradually found a more settled and effective way of working together.
The tight deadline helped catalyse that change. There was no option to retreat into separate teams or wait for perfect conditions. We were united by a shared vision to make the process better, and achieving that meant listening to one another, making decisions together and changing direction when something was not working.
By the end of the project, we had begun to operate as one team. We understood each other’s strengths, were more comfortable challenging one another and focused on solving problems collectively rather than protecting individual areas of responsibility.
That is what enabled us to deliver four significant applications, support staff through a month of hyper-care and continue improving the products at pace during a very difficult period.
The most important thing we built over the summer was not an application or a platform. It was a team, brought together by a tight deadline and held together by a shared determination to make the process better. That is what we take into the next phase.
Like
Love
Haha
