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 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

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.

Difficulties

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.  

Achievements

  • 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.

Difficulties

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. 

Achievements

  • 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.

What a week for learning

Week ending 11/10/2019

From embarking on a journey to uncover the best value technology for network core switches, to understanding the audit for the desktop port density in Hackney office sites.

The discovery of new technology took the shape of another workshop lab test session hosted by the ‘Open Compute’ vendor. The lab test consisted of a brief presentation showcasing the Open Compute network capabilities, followed by a workshop session in which our engineers were given access to a virtual staged environment giving them the opportunity to carry out a range of networked related stress test and any other common problems which they may typically encounter within our network environment in order to establish if the ‘Open Compute’ network solution will be able to adapt and indeed surpass our network needs.

What we aim to deliver

The primary deliverables for the team in SPRINT 14 will be the audit for the port density, finalising and shortlisting the discovery to core and distribution level network vendor options, first drafts of firewall design and to begin mapping and streamlining the procurement steps for this project. 

What we have found challenging

Cisco vendor solution: Currently the one thing we are finding challenging is organising Cisco test lab. They tend to want to steer the direction of our requirements. I put this down to a legacy vendor relationships in which we have been lead by the vendor.

Procurement Process: We are currently experiencing a bit of back and forth in the procurement process. Our current bottleneck is the internal legal department who are currently in receipt of a vendor agreement pending approval. No clear indication of the turnaround.

Next Steps

  • Organise the Cisco test lab
  • Complete the port density audit
  • Hash out the mapping doc for the procurement steps

Hackney Digital Support Services: Weeknote, W/C 07.09.2019

Hello and welcome to the Digital Support Services weeknote.

This week I am going in to full divergence. The overarching Digital Support Services suite of works has cascaded down in to distinct arms of works, which in turn have trickled down in to bitesized projects, which in turn will feed up and cascade in domino like fashion to deliver a transformation to our digital support services.

We have two project nuggets that we have been preparing to undertake, one of which is rather excitingly a HackIT experiment where we have asked a number of ‘what if’ questions about the way that we work.

The two projects are “Joining up people data” and “Improving our forms”.

Joining up people data is going in to alpha and it’s the experiment. It’s exciting for me as the Delivery Manager, as it’s both my first Alpha that I am delivering for HackIT and it’s also a first agile project for the product owner.

This week on joining people data, we have been “pulling back the bow”. Both the product owner and I have been learing and understanding how the project has reached its current position and we’ve been planning how we’ll take it forwards. We’re keen to keep hold of the vision and intention of the discovery and stakeholders and at the same time, taking from that discovery and applying it to alpha.

We’ve done this by combing through all of the documentation that has been captured, looking really carefully at the minimum viable products that presented themselves after the discovery and talking about these with the people that envisaged them. We’ve also been reaching out to those who were involved in earlier parts of the project to make sure we’re properly understanding what was found.

In terms of the alpha itself, it’s a little unusual, as we are trialling and testing an assumption presented in the form of a minimum viable product that emerged from the post discovery workshops and discussions. So in some ways, it’s a mini project within a project, within a project (crickey, this is starting to sound like the movie “Inception”).

However, being part of the experiment, we have a strong opportunity to really make good use of the resourcing levels proposed and also to maximise our concept of ‘sprint zero’, which is the concept of a structured lead in to enhance the velocity of the project overall.

To achieve this, Lisa (the Product Owner) and I have been refining the kick off for next Tuesday and thinking really carefully of what we are going to try to achieve in each sprint of the project. Whilst agile by nature is flexible and adaptable, we’re thinking along the lines of a week long sprint zero lead in and then three fortnightly sprints with a specific goal for each.

At the same time, Lisa has been working super hard to understand the nuances of agile and get a solid feel for her role as Product Owner. Agile can be a peculiar animal to understand at first, because by it’s very nature it’s malleable and adaptable and it can be tricky to understand when some rules apply and when others don’t and why. As Jeff Sutherland (inventor of Scrum) described , Scrum is easy to grasp, but difficult to master!

But… with all that in mind – we kick off on Tuesday. We’re up for it, we have a healthy sense of nervousness out of respect for the project and we’re excited to do this thing!!

The other project that that’s kicking off next week is “Improving Our Forms”.

Here also, we have been doing lots of prep for this in understanding all of the work that has happened before us. In fact, I traced conversations dating back to June 2017 on this one, so to say that this has been explored for a while is an understatement.

For Improving Our Forms, we are stepping in to a rapid discovery phase to properly test a hypothesis that has been bubbling under the surface of this conversation.

The hypothesis is that: There is a tool available that can help us to improve 70% – 80% of our current forms.

Our goal is to get to a place where we have an adequate understanding of the digital services that we need to build, so we can then make a decision on what we will use to build them.

There’s a lot of appetite for shifting this forwards and to determine a number of debated points, so going in hyperdrive, we are condensing this down in to a two week discovery. A discovery of two parts… sprint one (1 week), insight and discovery, sprint 2 (1 week), investigation and recommendation.

Paul, the product owner is super clear about the vision and outcomes and so I’m really excited about working with him to really drive this forward rapidly. That said, we’re both keen to get the right outcome and to derive real value for the business, so we are thinking about great ways to maintain high levels of guidance and governance as we shift forward with pace.

So there we have it… one week… two kickoff’s.

It’s going to be fast (although hopefully more humorous than furious!), it’s going to be intense, but hey, it’s agile – I’d expect nothing less.