Improving our e-forms: Week Note w/c 14/10/19 – Discovery.

We’ve kicked off!

Improving our e-forms is a somewhat contentious title, as there are many debates surrounding what is a form vs what is not a form and that changes depending on who you talk to, but not wishing to get locked in an apprentice style forever meeting about team name, we plumped for this and cracked on with actually doing!

We’re anticipating a rather swift discovery, as those who have come before us have also discovered, so we’re keen to take the conversation out of spiral and in to a more linear direction.

How to do that?

I’ll admit, it’s not the easiest.

It’s slightly chicken and egg, because what are currently using forms for, are not necessarily good for the user and so we are trying to navigate how we might understand what we are currently dealing with at the same time that we are in the knowledge that they are not what the users want, whilst at the same time trying to discover whether a hypothesis about a potential solution might be available on the market…

Confusing? We’ve already worked through three blocks of post-it notes, a tray of Mr Kipling and even used the emergency pom poms to try and tease this out…

However, our first week of our first sprint has begun to show some emerging pieces.

We completed a comprehensive workshop on what we think the important aspects of the criteria might be for the solution, which was extremely well attended – which talks to us about the level of interest and engagement around this piece of work.

The criteria for a solution might, however, have been a bit premature if truth be told. We attempted to correlate an existing list of functions that involve forms in some way with that criteria list and the activity struggled to reach a natural and organic conclusion. That said, it may be that we were trying to connect the wrong dots and Paul (the product owner) and I will see what we can do to move the pieces around tomorrow, or in fact see if there are any pieces missing.

Despite this however, all of the data we are capturing is really useful.

After doing a blind exercise on the criteria for a potential solution, the average scores lined up in such a way that the core team could split the criteria in to quartiles around importance. This is a cheeky little win that we might be able to share with other projects thinking on a build/buy matter through and save them the trouble of having a workshop.

This week, I sense that it will benefit us to check in on the project briefs and definitions of done, to see if we can tighten anything up that may help to spot any other possible temptations to step a bit too far forward. (I take the rap on this one as Delivery Manager that we perhaps jumped too far in to a possible solution within the discovery phase).

We are working swiftly, but it emphasises the importance of resisting the temptation to whizz ahead, as it has the potential of costing more time in the long run. It’s not necessarily what’s happened here, but it is possible we have and it is worth checking in to make sure we avoid the potential to do so again (if indeed we did).

I’m looking forward to planning our show and tell on this one, as I think we’ll get loads of feedback – it seems that a lot of people really want this to succeed and the team working on this really want to make a difference and an impact.

Onward to week 2 – let’s see where the discovery will take us and how we can splice these unruly concepts together!

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…

Ian

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.

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.