Joining Up Staff Data: Week Note w/c 14/10/19 – Sprint Zero

Hello and welcome to the first official weeknote for “Joining Up Staff Data”.

Our goal is to have identified and created a means to join people data together across systems and we have used this to deliver key insights about the business.

This is the first of our ‘inception’ style pieces of work, in that it’s a project within a project within a project!

It’s also the second of the HackIT ‘experiments’ asking lots of ‘what if’ questions, such as what if we worked on something in a more intense and focused manner amongst other things.

So this week we kicked off and engaged on sprint zero. A week in which the new team were able to review those that had come before them and get all of their thoughts in a row before embarking on the journey to alpha.

It’s a journey that needs a good look in the rear view mirror. Some of the team who carried out the discovery are no longer with the organisation and the origins of the project are rooted some distance back. Furthermore, the goal of this project is something that has developed after the discovery was completed from the project that sits above it in our inception structure.

We’ve also got some newbies to agile on the project, so we are all very much learning as we are going.

The good news, is that the experimental structure that we are trialling for HackIT allows us the time and the space to learn as we go and the management structure around the team has been supportive and mostly ‘cleared the path’ for those working on the project to give it their best shot!

So what did we do in our sprint zero?

Essentially we explored the original overarching discovery and drew down from that information, those insights that will help us to understand and plan out our journey to achieving our project goal.

At our kick off we:

  • Learned lots about each other and our working styles through some amusing activities and creating a basic ‘user manual of me’
  • Heard from Henry, our project sponsor, about what the hopes are for the project.
  • We worked out what was in scope and out of scope
  • We decided on the phases of the project
  • We worked out what we needed to do in sprint zero so that we could step in to sprint 1 armed and ready to start delivering insights in to the business.

During sprint zero we:

  • Split the discovery info in to categories (data, systems & servers and people)
  • We researched the discovery info and asked stakeholders about these areas and distilled the info in to important facts and questions that inform us for sprint 1
  • We created a hub document that we will refer to across the project
  • We explored the difference between having ‘comprehensive’ data and ‘enough’ data to make decisions.
  • We started a data asset register (who knows and manages what data)
  • We created a list of next steps and important questions that we could take in to sprint 1.

It was a productive week and we managed to pull everything in to place in time for the end of the week, even with a last minute change in the team!

Being sprint zero, we weren’t really expecting to deliver a value nugget, but Lisa, in her work researching who would be best to speak to about what data inadvertently started the creation of a data asset register. It’s e

We’re really looking forward to heading in to the coming week where we embark on sprint one with gusto and a want to win this!

Before I go however, this is a big subject area. One of our consistent temptations was to get in to the bigger thinking, to try to figure out way too much stuff too quickly – so we found this video to be of use…

That’s it for this week!!!

Until next time…


Network Redesign “Safe as houses”

Week notes 18/10
Getting our house in order
It’s a common perception that a building that is built on a solid foundation is something that cannot be knocked down easily. This week we have seen the closure of SPRINT 14, which I am happy to report our team has delivered on a majority of the tasks bar two, which is a huge improvement from the last SPRINT.

Getting the basics/foundation right
Two of the fundamental reasons for the turnaround which shifted the odds into our favour, were:
1. Resource – Our manpower was back at an optimum with key members of the team returning from leave.
2. Planning – The team has been encouraged to begin to look at SPRINT planning with deeper thought and from a different lens. The key rule of thumb being,
‘Only commit to what we can deliver on within the lifecycle of a two-week SPRINT.’

Value to business
The direct value to the business, as a result of this SPRINT, has been the following:
• Port density report (This will be used to help stakeholders decide the cost estimate and number of new ports required. Also a steer on potential ports which can be decommissioned)
• First draft Firewall design (High-Level design security configuration network. This allows the business to understand how security can be configured from both the user network and the main data center security configuration)
• Mapping Procurement process steps £5K level under (This will streamline the process for future vendor contract procurement that falls under this criteria)
• Comparative vendor network solution discovery phase complete (This report will help validate the final vendor solution for the network redesign project)

What we have found challenging
Legal authorisation of vendor contracts – This is an important step in the progress of the project. Historically, the progress of similar projects has slowed down at this point in the cycle. This may be unavoidable, however, our team is keen to find any workarounds or new ways of working to produce a better workflow with legal and reduce the bottleneck which we are currently experiencing. This, in turn, will have a huge impact on our ability to deliver all our procurement requirements

Next Steps
– Compile 1st draft recommendation vendor report
– Have a decision made on the ‘Port Density’ recommendation
– Agree on proposed procurement steps
– Begin looking at a new proposed workflow with legal

Manage a Tenancy week notes – 18/10/19

Week ending: 2019-10-18

Week notes are a way for us to keep people informed about progress on the project. Given the technical nature of the re-platforming work we will use them to explain technical choices that we are making, including the benefit and impact of these choices. 

The goal for this week was to better understand the project’s technical constraints, and to prioritise the most important elements.  

Project goals

  • Enable housing officers to use Manage a Tenancy offline when there are mobile coverage blackspots
  • Enable Hackney to support, develop and deploy future improvements to Manage a Tenancy more quickly, at lower cost

Good Things

The team now has a very clear steer on scope and priority, which we can turn into a more realistic roadmap for this phase of the project. We will focus initially on building offline processes rather than the hub and worktray; the benefit is that we can meet the needs of the Housing team first and foremost:

  • It is the most rapid route to making the digital processes work offline
  • It gives Hackney the greatest opportunity to practice building processes in React, putting the team in the best position to digitise further processes in future.  

We also discovered that the work to replatform My Rent Account should be relatively straightforward; this is what we were expecting, but it was good to validate this assumption. This is work that the team will tackle at a later date, after the initial dxw-phase of the project is complete. 

Learned things

We learned more about the API that the Hub and worktray currently use, and we explored different ways in which we can ‘futureproof’ this aspect of the work. Importantly, we agreed on a way in which we can decouple the front-end work from the API; we can do this by having an object in the front end that can deal with changes to the API endpoints. 

This was a useful discussion and should help Hackney in the longer term; we will continue exploring this once we start delivery on 30th October. 

We learned about the status of the continuous integration pipeline project, and were able to feed into the planning of that work. This was very useful, and should remove potential blockers further down the line. 

Other things we learned:

  • The Google SSO project is at a relatively early stage for Hackney; this is now something that we can safely deprioritise from the Manage a Tenancy work for now
  • The Outsystems contract is in place until September 2020
  • The Qlik dashboards pull data either directly from Dynamics or from UH; this is no longer a dependency on us
  • The work to replatform My Rent Account is relatively straightforward, and this can be picked up after the initial dxw phase of the project, and will benefit from the React groundwork that is laid in the Manage a Tenancy phase.


The trade-off that comes with prioritising offline processes is that the replatforming the hub will need to come at a later stage in the project. Although this can be done in time to decommission Outsystems, this does carry some degree of risk. 

The work involved is largely front-end development; this is not currently a widely held skill in Hackney Council. A good mitigation would be for Hackney front end developers to get involved in replatforming at least one process, so that they can learn how to build things in React.  


  • We have a clearer and more realistic scope for the team to focus on during the first phase of this project; thank you to Matthew for giving us the steer that we needed. 
  • Thank you to David, Mirela and Shweta for being so flexible when we had to move meetings around because of illness.

What’s next

We will :

  • Update high-level roadmap that we created together, which will help us prioritize work and talk about the risks and dependencies more clearly. 
  • Amend the statement of work to reflect the revised scope and priorities.
  • Carry out some technical prep before we start sprinting on 30th Oct; this includes things like:
  • investigating how we might build React and HTML/CSS/JS components from the same source for Hackney’s component library
  • looking into how we might automate testing our internal reflection of the API against the Swagger JSON

Improving the Repairs Hub 18th October Weeknotes

For those of you who don’t know, Hackney built a service which allows repairs call centre agents (RCC) to raise repairs. It’s called the repairs hub and it works in conjunction with the neighbourhood contact centre customer relationship management service (NCC CRM) and Universal Housing (UH) to raise repairs against particular properties.

The service has been live long enough now for us to have gathered good feedback on what works, what doesn’t and what would be really useful to have. That means it’s time for some iterative improvements! Luckily, we have a support agreement we can draw on with the wonderful Unboxed and some in house expertise who can help us out with this!

After reviewing feedback from agents, HotJar and by working with Lindsey (the product owner) and Barnes (the service expert), we were able to really clearly articulate and prioritise the improvements that would have the most impact and value for both staff and citizens. We also identified and prioritised features which warrant a more holistic assessment and so are progressing these outside of this round of improvements.

So, we’ve got priorities, we have colleagues ready and willing to work on the improvements so we got cracking!

This week we have been busy tackling (and making great progress with) the top two issues:

  • Connection issues
  • Missing SOR codes

Our intrepid developer, Bukky, has updated the SOR codes identified as missing and they have been added to the live service. We’ll be keeping a close eye out for feedback or any more missing codes.

He’s also been doing his best detective work to find and diagnose connection issues.

So far, it looks like we have some problems with a connection to a third party. This isn’t helped by the fact that we aren’t providing a useful error message to front end users meaning the true cause of the connection problem is being misrepresented. We will need to pick up with our colleagues at Unboxed as to how we can make this more informative for users (and us!) and also with app support to get to the bottom of the third party connection problem.

Our show & tell will be over in the Repairs Contact Centre on Friday 25th October at 12:00. It’s listed on the Open Events calendar so, do pop a long if you want to know more.

Manage a Tenancy week notes 11/10/19

Week notes are a way for us to keep people informed about progress on the project. Given the technical nature of the re-platforming work we will use them to explain technical choices that we are making, including the benefit and impact of these choices. 

The focus this week has been on defining our ways of working, and learning about what’s required for Manage a Tenancy. As a result of the inception work we have built a draft roadmap to indicate the order in which we’re going to do things. 

Project goals

  • Enable housing officers to use Manage a Tenancy offline when there are mobile coverage blackspots
  • Enable Hackney to decommission Outsystems, saving £80,000 per year
  • Enable Hackney to support, develop and deploy future improvements to Manage a Tenancy more quickly, at lower cost

Good Things

This was the first time that the technical delivery team was able to come together. We now have a much better understanding of the work and risks involved in replatforming Manage a Tenancy. 

We agreed how to make our work more reusable for Hackney colleagues in the long term. Rather than building complicated bespoke pages for user journeys, we will approach a data-driven front-end. We intend to do this by building components that can be easily assembled into a new process by writing a config file. The benefit of this approach is that it should make it easier for the HackIT team to digitise new processes in future, rather than relying on third parties to do this. It may also be useful for other digital projects in Hackney.

HackIT and dxw worked together to create a DACI matrix, to agree what everyone is doing on the project. One of the key takeaways from this activity was that we want to avoid front-end vs. back-end silos. dxw and HackIT developers will work closely together. We will co-locate to help this as much as possible.  

We now have a high-level roadmap that we created together, which will help us prioritize work and talk about the risks and dependencies more clearly. 

Learned things

The members of the team from dxw learned a lot about the existing technical architecture and constraints for Manage a Tenancy. Some of the key takeaways:

  • The Hub and work tray currently use an API which talks to CRM Dynamics 365. Next week, we’ll explore whether we can work with this API and still achieve the project goals or whether we’ll need more help from Hackney developers to make changes to the API. The benefit of refactoring it, is that it will make future improvements easier to deliver. 
  • There is a degree of conditional logic in the processes which we need to replicate. Our current assumption is that by using configuration files written in TypeScript (rather than a simple JSON mapping) we should be able to minimise issues in handling this logic.
  • The re-platforming project could benefit from otherHackIT initiatives – this includes implementation of a new continuous integration  pipeline and Google SSO. Each of these adds some degree of risk to the project, which needs to be managed carefully, or we could decide to take advantage of these initiatives at a later point.
  • A shared component library for Hackney is currently being built, but will need some work converting to React (the framework we’re using to build the user interfaces) components before it can be used in this project. We intend to do that work as we need it, rather than doing it all up front.


We now have a clearer sense of the challenges involved for Manage a Tenancy. The project currently carries a high degree of risk which we need to manage carefully.

  • Frontend scope: there is a lot to deliver in just 5 sprints. We may need to extend the timeframes, or tackle My Rent Account in a second phase.
  • Backend scope: there are still discussions required in order to fully realise the scope of the backend work required, specifically around whether changes to the hub API are required. We are working together to understand how the scope of these changes will affect the speed that the team can deliver the frontend features; we may need to adjust priorities to ensure the frontend work is unblocked as soon as possible.
  • Managing expectations: once we’re clear what benefits can be delivered when, we’ll need to work with Lorraine so that she can set expectations for housing officers and senior stakeholders. For example, some user experience changes have been identified and implementing these will require additional user research and testing. Given the need to de-risk the project we think that it makes sense to descope these changes for the time being, and address them once the new system has been built. 
  • Dependencies on us: there are dependencies on us outside of the core scope (e.g. implementing Google SSO, managing defects, and corporate dashboards). We think that it is sensible to reduce any risk on the project and this likely means deprioritising things which are not on the critical path. 


  • We’ve drafted a DACI and a roadmap for MaT, which will help us work together in delivering the project
  • We’ve agreed a rough technical approach for creating data-driven frontends with reusable components
  • Thank you Mirela and Shweta for taking the time to talk us all through the existing setup, and for answering all our questions!

What’s next

We will continue inception work next week. Some of the key areas we will be digging into include:

  • My Rent Account technical overview
  • Changes required to the existing Hub API (which may be a blocker for the frontend work)
  • Agreeing the priorities  for Manage a Tenancy
  • Further investigative work for how we might achieve some of the more technically challenging aspects of the project
  • Scheduling key meetings (planning, show & tells, retrospectives) 

Sprint 1 will begin on Wednesday 30th October.