Re-engineering Hackney content: weeknotes 7/10/19

It was touch and go at the start of last week but is now definitely live. The homepage is out there singing its best song for Hackney with resident-centred editorial, top tasks and an array of useful signposting content. We’ve been responding to feedback hot off Hotjar and tweaking the top tasks to suit visitors. We hope to establish a mechanism whereby customer services can feed into this list on a daily basis, making sure it’s relevant to current queries. 

screenshot of homepage of hackney council
Screenshot of new Hackney homepage

We know we have work to do. Specifically, search is not quick enough and is not as logical as we want. And we need to anchor the navigation so that visitors know where they are in the site when they click on the menu. 

Developer Emma Lewis will be trialling Mohamed Mulla’s documentation on GitHub this week to make sure future developers can hit the site running. And we’re welcoming a couple of apprentices to help us clear out some of the design annoyances: any heading, icon or component that’s one pixel out, we’re coming for you.

We held a retro on Friday to work out why the DNS switch to live was so problematical when it’s normally a straightforward, five minute exercise. In our case, the site was sometimes sending you to the new site, sometimes the old. As if the machines had taken over and were forcing their own A/B test. Or, rather, Virgin Media had taken over.

After some exhaustive work with Virgin from Lindsay Rex, Mal Morris, Idowu Kusoro and Isaiah Oketola in Infrastucture, we were back on track by Wednesday. However, the retro gave us some lessons learnt to take forward that we’ll be applying to the Intranet launch this week. It was a really useful, instructive hour, due in no small part to Cate McLaurin’s sterling job as facilitator. 

One other surprise was the number of third party sites that had been hosting their CSS files on Goss, the old platform. This resulted in services including One Account, Planning Portal, Licensing and anything on the mginternet domain losing their styles. We were able to identify them quickly and host on the new servers but, medium term, these files need to be located with the rest of their code. We’re tracking down the owners now. 

Manage a Tenancy : Week notes – 4/10/19

Pushing blocks together

We send out weeknotes to give an update on progress. They highlight things we’re worried about, acknowledge achievements and show progress. They also lay out what we plan to do next. Along with our show and tells, this is the main way you will find out about the project so please read. 

Get in touch with David Durant with any questions or feedback. 

This is a particularly short weeknote, as the project only officially began yesterday.

Good Things

It is very early days, but we’re celebrating that the project has now officially begun. We have only had one day of inception, but the Manage a Tenancy overview was really valuable. The team now has a much clearer idea of scope, and ideas on the best approach are beginning to emerge. 

Learned things

The Inception phase is all about learning, and the first day with Hackney definitely gave us that. It was really useful to learn about the users of the Manage a Tenancy service – Housing Officers and Area Housing Managers. We were also able to learn about the housing processes that we will be replatforming:

  1. Hub and Work tray
  2. Tenancy and Housing Check
  3. Home Check
  4. Initial/Introductory Tenancy Visit

We also learned about the process for Enhanced Tenancy and Residents Association Meetings. Although originally out of scope, aligning it more closely to what we’re doing may save effort in the long run. 

Difficulties What we’re thinking about

We haven’t yet come into difficulties, but there are aspects of the project that we’re thinking about and would like to dig into more during inception:

  • Striking a balance between making improvements and getting the project delivered on time. There are opportunities to improve the service,  but only if this doesn’t impact our timeframe. We will agree on the best approach next week to strike this balance. 
  • Joining up front-end and back-end development. We need to ensure that these two strands of work are brought together as much as possible. The ways of working session next week is a good opportunity to define how we will do this. 
  • Making the outputs reusable. Rather than developing each process separately, we are thinking about developing individual components which can then be configured into a process. This would make it quicker to update the processes in future (and create new ones).
  • Thinking creatively about the Housing Officer user journey. The goal is to design processes that work offline for a Housing Officer, so that they can carry out their work in the field. We should think about this in terms of the end-to-end user journey, as there may be changes we can make to the journey that create a better experience, whilst also minimising issues like patchy uploads in areas of bad signal. For example, is it possible for Housing Officers to “queue” up a set of visits at the start of their day, and then synch them once they return to the office.  


Thank you to David for getting all the right people in the room and to F for asking lots of helpful technical questions during the first walkthrough meeting.

What’s next

We continue the inception work next week, which will include:

  • Tuesday 8th Oct – Ways of Working
  • Wednesday 9th Oct – Technical Overview
  • Thursday 10th Oct – Roadmapping, risks and dependencies 
  • Monday 14th or Tuesday 15th Oct – Data migration

We will also start booking in the sprint ceremonies next week, including show and tells. 

Sprint 1 will begin on Wednesday 30th October.

DevOps Practices Weeknotes w/c 23/09/19

Picture of a truck and some pipes
Pipeline coming soon…

This week there were two main developments on the DevOps Practices work: 

  1. we kicked off the planning for the deployment pipeline, which will test our containerisation hypothesis
  2. we have continued our engagement with wider teams, especially infrastructure and security on our cloud and containerisation work.

Deployment Pipeline

Last week we got agreement for our general approach and had started to pull together a list of high level needs (for more detail: This week we sat down with the team to try and turn this list into our first sprint. Although we set aside 2 and a half hours for this, we did not get to the stage of having a full planned sprint 1 for our Deployment Pipeline.

However we did manage a lot. We first started by prioritising the list of needs. We went through them all and prioritised the top 10 to discuss further. This resulted in some really good back and forth discussions about the value that we would deliver such as should we be focused on optimising speed or getting other testing right. In line with our general focus on quality over speed we focused on further testing.  

We then built out our list of needs into full stories focusing on the impact of meeting these needs. Our final list of 11 (one got split into two) user stories was: 

  1. As a developer, I want to automate deployment so that I can deploy a set of code changes quickly.
  2. As a developer, I want to prevent secrets from being distributed in the open so that our services remain secure.
  3. As a developer, I want to know that no vulnerabilities through code changes have been introduced so that our services remain secure.
  4. As a developer I want automated accessibility testing so that are services are usable by all our users.
  5. As a developer, I want to know that no vulnerabilities from 3rd party libraries have been introduced so that our services remain secure.
  6. As a technical architect, I want reusable components that I can utilise to build a pipeline for my project quickly so that I can ensure code is delivered to the standards expected by HackIT
  7. As a developer I want automated load testing so that I am confident that the service can cope with peak demand
  8. As a service owner, I want visibility of quality measures (build metrics, automated test reports) so that I am reassured the automation is working
  9. As a technical architect want to know that code being written conforms to best standards and is follows the development style at HackIT so that it is supportable, scalable and consistent.
  10. As a technical architect, I want a consistent naming convention for all objects (code repositories, infrastructure, libraries) so that people can find their way around and understand the architecture of the code
  11. As a developer, I want a way for our technical documentation to be generated automatically from our code base so that I don’t have to remember to update documentation every time a change is made

At this point they are quite developer heavy. I think this makes sense in the current context of separating our Terraform infrastructure from our applications but it is something that we are aware of and will be keen to redress the balance as we go further forward. Let us know if you have any feedback on these as they are still open to being refined.

Once we had done this we agreed our definitions of done and acceptance criteria for five of these stories.

Continued Engagement

We have continued to engage with a number of teams to feed into this alpha. People from the infrastructure team are going to be participating in the pipeline work. This upcoming week I will be working through the backlog with them to feed into our discussions on Friday. We have continued to engage regarding cloud capacity and these discussions have helped to refine our thinking on cloud procurement. 

We are in a really good place to square the circle between keeping the infrastructure team and their skills a part of whatever cloud we procure, while acknowledging that not everything that they are responsible for will be cloud hosted in the foreseeable future. 

We are also working alongside the security team to feed into the deployment pipeline and also to see if we make sure we can embed a culture of security being baked into development. 

Next Steps

The team are meeting on Thursday to break down our prioritised stories (with acceptance criteria) into actionable tasks. We will also continue to explore our strategy around procuring a primary cloud supplier. 

As always any feedback is much appreciated. 


Week ending 27/10/2019

This week has been all about getting into the technical and beginning my journey to understanding the ICT procurement process.

Let us start with my team’s discovery this week, which was easily one of our highlights. The Network Redesign Team were tasked with exploring the potential for new vendors, to improve our current network – Cisco-based closed environment solution and providing an alternative future proof solution which also meets our current requirements.

With this in mind, the team used two days this week to attend workshops held by vendors offering potential answers to our challenges


We were invited to two demo workshop-style presentations –  

 ‘Aruba’ and ‘Open Compute’. Despite both companies being leading networking specialists, the two had very different approaches to the requirements presented to them.

Aruba is a very established industry brand. The report back to the ‘Mothership’ following on from the workshop revealed that they had some unique enterprise features. One that stood out, in particular, was the ‘RAP’, an offering which includes role-based network access and Adaptive Radio Management (ARM), which gives remote workers the same high-quality Wi-Fi experience as being in a central hub.

The Open Compute workshop was very impressive. As the name suggests, Open Compute is open source technology networking solution. We were particularly impressed by their ease of integration and ‘relatively short up-skilling window’, (although the jury is still out on that one). Another plus is the ease of scalability as the system environment has no ‘lock-in’s’ so our engineers would not be tied down by licenses, which would allow us to be flexible with our IA design making us more agile to user needs.


As we actively embark on the hunt for new networking solutions for Hackney, we explore exciting technological advancements available on the market in this fast-evolving world of networking.

Each of the above approaches equally has its fair share of pros and cons. However, we are still in the discovery stage. More will be revealed as we bring our scuba diving kit for a deeper dive into both of these platforms and other solutions.

Manage Arrears weeknotes: w.c. 23/9/2019

Phase 3, Sprint 2

This week’s highlights:

The Team

I am really proud of the Manage Arrears team this week. We have had a few challenges to overcome both internally as a project team and with stakeholders. I would like to thank everyone for their dedication, support and for handling constructive criticism well. I can see that the whole team have a genuine passion and an invested desire to deliver the best product possible. A special well done, also goes to +Miles Alford and +Maysa Kanoni for their achievements this week.

Roles, Permissions and Patches Workshop

Earlier in the week, we brought the Income Collection team together with the Leasehold Services team in a workshop, to understand the differences and similarities between their roles. The purpose was to help the developers get some insight into how they will approach this part of the build. We now have a clear and simple structure to work from. This part of the development will be a Corporate benefit as it will allow multiple service areas including Leasehold Services to be easily embedded with the Manage Arrears system for future phases.


Elaine Geeves has done a great job, gathering potential efficiency savings that Phase 3 will offer. Each saving identified can be supported with evidence. The biggest value that Manage Arrears can demonstrate once delivered in phase 3 will comes from the automation of income collection’s letter 2. Letter 2 is the second letters sent as part of the escalation policy.

Next week:
*Usability Testing of the priority scoring adjustments
*Starting to work on the backend of the system to adjust the priority scoring