Two for the price of one

If you see Two in One — I only see One in Two — Rumi

As we’re a little behind on our blogging updates….so this blog captures discussions and progress from the last two sprints to 26th February 2021.

At our workshop on the 12th February 2021, scenario testing was high on our agenda for discussion. We’d undertaken the first two rounds of officer testing with officers from Buckinghamshire, Camden, Lambeth and Southwark, asking them to test a set of 10 different scenarios that we’d created.

There’d been some great feedback from the officers both verbally and using our testing plan document

This information had been collated into one spreadsheet — so that we could see all of the feedback in one area.

Additionally — we had some great feedback from the feedback widgets provided which were collated into a central log by our developers OSL.

We agreed it would be good to share scenarios with the BoPS (Back Office Planning Service) team — however discussions with the BoPS team had established that at this stage, synchronizing wasn’t essential. However, it was agreed it would be worth having a conversation with BoPS about sharing those scenarios and that Emily of Bucks would hook up with Tom from Southwark leading the BoPS project to discuss this in more detail.

The main thing we want to develop for future testing has been plans to go with the scenarios. One question we posed was whether we wanted plans for the existing 10 scenarios that had been tested, and then re-run those scenarios with plans recruiting new officers for testing — or whether it would be better to move onto new scenarios with plans. The latter would mean we could ask the same officers who had already undertaken testing for us to try out the new scenarios. As officers are so busy with their day jobs, it may be easier to get the existing volunteers to stay with us and move on to new scenarios. A decision to be made on this — but we agreed to see how things went, and really this decision would be dependent on how easily we were able to get new volunteers to work with us.

We agreed a priority for Round three should be the ‘weirder’ edge case scenarios — where there are nuances to interpretation, common but ambiguous issues.

One outcome from that first sprint was that Bucks would provide one of their graduates to get involved in drawing up rough plans for future use.

The GPDO Brains Trust

We also engaged with the Lambeth Planning Lawyers to discuss GPDO edge cases. Respectively labelled as the GPDO Brains Trust. For the benefit of avoiding this blog being way too long, we’ve posted a separate blog called GPDO Brains Trust questions for those who are interested in knowing more!

For our second sprint work, meetings were held between the Lambeth and Buckinghamshire IT teams and members of the project team to go over the GovPay requirements — more on this can be found in the Show & Tell at the end of that Sprint (see S&T recording on ripa.digital’s project log page)

Another topic of discussion in that week was the fact we were running out of volunteers for user testing. We agreed we would encourage all of the partners to ask internally in their councils to see if they could drum up some volunteers for testing. Preferably officers from Housing and Regeneration — and other areas where they have some understanding of the planning application system — but more from a user’s perspective than a qualified planning officer.

We also went over the Retro board. This week’s board was a little ‘quieter on card content than is normal — hopefully a sign that there is more satisfaction with things at present rather than an indication that the team forgot to complete it…!

In the ‘What Went Well’ area, we unanimously agreed that the backlog session which was run by Michael from the MHCLG team was hugely useful. It included the Henrik Kniberg diagram showing the best way to build an MVP (minimum viable product).

The overarching message being — if your customer wants a car, don’t build them a car in one go — meaning they are waiting endlessly for the end product, instead produce it iteratively tire, by chassis by engine by full car. Building it iteratively means a focus on the underlying need — they want a car, they want to get from A to B — so develop the smallest thing — the mvp — that allows them to start testing their journey of getting from A to B. In the Henrik Kniberg diagram — the first iteration of solving the customer’s need was building a skateboard. Not ideal but something for them to test…!

We all agreed how useful this was to help us really frame the project and road plan head.

In the ‘What could be better’ area — there was one query raised around holding shorter Show and Tells. We went around to get everyone’s views and they ranged in opinion. The various comments are summarized below:

· structure good, pitched well — sometimes things gets dragged into detail — perhaps have the start and end all at the start e.g.: where are we now and where are we going with it and the detail in the sprint is here.

· They should be as short as they can be but as long as they need to be.

· Some things work really well — other things done work so well.

· Some things are too much detail — be more high level and select few key points.

· Whatever you show — make it count.

· Look at the data — how many we lose at a specific time.

· If one area is going to be longer — then perhaps something else needs to be trimmed

· Instead of trying to pre-empt potential questions in the actual show and tell section — wait until the end Q&A section and see what the viewer wants answered

· Could we look at the data and see when people drop out — would that help us with a bit of analysis about what works, what people find interesting, where we lose their interest?

· We should expect the viewer to do us the courtesy of knowing about the project and not give them an intro every Show and Tell about the project

· If we want to engage with new people and see our audience grow, we should give them an intro — look at home improvement programmes such as the BBC’s garden design — every single programme they always show the premise of the programme — it’s the same intro — it’s boring if you already know the programme, but if you’re a new viewer you’re more likely to stay if you understand the premise

· They may be lengthy but information is valuable — wouldn’t want to lose things just in an attempt to make things tight

In the ‘Actions/Questions’ section — the main ask was to have some dummy transactions going through GovPay tool so that we can see what the actual output looks like.

It’s not next up on the developer roadmap, but perhaps is something, if there’s a quick fix, to pick up. This would be hugely useful for finance teams to be absolutely clear on what to expect and there aren’t delays because suddenly it doesn’t look as they expected it to. This could cause delays if internal finance teams then need time to resolve the different output to that expected.

Well — that’s it for this two in one. Thanks for reading if you’re still with us at this point! Next Show and Tell: 12th March 2021 at 10:45 am.