, ,

Transforming SEPA

 

A while ago a few of us from our permitting service mapped out the applications process. Breaking the process into small chunks and speaking to staff about their gripes, we got an understanding of the key problem areas and areas that definitely needed fixing.

This was important because, essentially, permitting underpins almost everything that that SEPA does. Without permits our customers don’t have ownership, defence, or an understanding of their responsibilities. We don’t have control, can’t regulate, can’t work with operators to make improvements. If we make the application process unattractive, unfamiliar and complicated, we’re adding a blocker to this relationship.

We have a requirement, under our Annual Operating Plan, to deliver three online applications by the end of March next year.

This could be done relatively quickly if we took a short term view and just built individual products. Solid products that are appropriate for that specific application that would require developer input from start to finish each time.

What is better is a product – a service – that can easily be manipulated, configured and compatible with other applications. One that follows a common service pattern and made of individual components.

If we were to build these individual components and linkages between them, we could easily add and remove sections as required.

About a year ago we got together with our Scottish Government colleagues and developed a prototype that could do just that. Looking at the application process for registering a septic tank, we could see it followed most areas of the common service pattern.

Using the common service pattern and being introduced to the digital first service standards did make us consider common functionality more closely.

Working on the application for septic tanks we’re always thinking of reusability, configurability – how our service will function for all future applications. This is crucial.

So what we have is a service whereby the following components of the common service pattern have been met, and I’ll walk through these.

There’s a guidance page that explains what this is all about – what it costs, why it’s required, what happens after an application has been made. There’s even an opportunity to ask us to search for an existing registration.

The ‘apply now’ button takes the user to the application form itself. This comprises just two simple screening questions plus an explanation what happens if the applicant is screened out. When it comes to inputting the addresses of the properties that use the tank we’ve connected to a common postcode lookup.

With all information collected, there’s a summary so the applicant can check before making a payment. This payment is taken through the common platform of Gov.UK Pay. This was chosen after encouragement from our Government colleagues and would provide the user with a familiar looking service.

Once that’s been made there’s a confirmation that the application is received. The information is passed through the CRM to our corporate systems where the registration itself and the application summary are generated. These are emailed to the applicants and our Registry department for upload to the pubic register.

Now, everyone loves an analogy…

We can think of the application as though it’s a house made of lego bricks. The septic tank application is a nice semi-detached. It has most features common to other houses. If we wanted to build a bungalow using the same bricks we could, quite easily. The little connectors are already in place and each brick will fit with any other.

We could build a less complicated application – for a notification that doesn’t require payment, for example – and all the components are there. We don’t need as much in the way of development to make it work.

If we wanted to pull in a more complex application – one that requires more assessment or advertising, for example – we could use the same bricks used in our semi-detached, then add a few more to create this extension. We could build a mansion if we wanted.

That time we worked on mapping out the application process was a real highlight in my time at SEPA. A few of us worked closely for a relatively short period of time. We had a common goal and were self-managed, spoke directly to people involved, gathered insights and plotted them.

It was through working with our Government colleagues that we were introduced to the digital service standards and a focus of our work to date has been to meet these and prove our compatibility. Indeed, we passed 21 of the 22 criteria at our assessment in February and will work again towards this success once our Beta product has been delivered.

, ,

Capri Achieves Digital Outcomes and Specialists 3 (DOS3) Framework Success

, , ,

Should discovery teams be following Scrum methodology?

SHOULD DISCOVERY TEAMS BE FOLLOWING SCRUM METHODOLOGY?

SHOULD DISCOVERY TEAMS BE FOLLOWING SCRUM METHODOLOGY?

A few days ago, I attended a user researcher meet up session organised by the Register of Scotland. It was interesting to hear panel member’s experiences including dos & don’ts, insights, empathy, stories and of course free Jaffa cakes. This was an after-work meetup event and their interesting stories made me forget about my rumbling stomach.

During the question and answer session, it became very obvious that almost everyone in the room was involved in some kind of discovery phase. For readers who are new to the term “Discovery” – it is the time before you start building a service when you find out whether users need it and whether other services exist. This part of your project is called the discovery phase. (Read more about Discovery phase).

They were all facing a similar kind of challenge, convincing people that user research is a very important aspect of service design. And it needs to happen before you design any service or build any system or product. Then I heard someone mentioned that they are trying to fit the activities in a 2 weeks sprint cycle and are always under pressure to feed user stories or customer insight to the product owner to keep the story-hungry scrum team going.

Our experience:

We had a similar situation in a current project where the discovery phase was completed elsewhere, and our organisation was partnered to deliver an ecosystem which other similar government organisations can use. This was the alpha phase to build a prototype and prove technology selection. The partner organisation was kind enough to lend us an experienced user researcher and service designer who started working in tandem with the build team. They were involved in familiarisation, user recruitment and research, sense-making, journey creation, prototyping and conducting the usability tests. Soon it became apparent that these activities were dependent on the availability of external users to participate in the user research. Which meant sprint planning became unpredictable and meaningless and our daily stand-up meeting became chaotic.

I could totally relate to their challenge of not being able to feed the scrum consistently.  This caused loads of pressure for the discovery/user research team and a frustration, ‘feast or famine‘ situation for the build team.

So here is a question…. should discovery teams be following Scrum methodology?

What did we do?

We split the team into ‘User Need’ and ‘Build’ teams. The ‘Build’ team continued following the Scrum methodology but the ‘User Need’ team started experimenting with Kanban. This approach definitely helped the ‘User Need’ team to list their activities and prioritise them. We could see loads of post-its on the wall and hear telephone interviews but to date, there were no shippable outputs/outcomes. The User Need team still needed to review the information that had been gathered before the user stories could be written.

We decided to introduce monthly planning, retrospective session and show-n-tell ceremonies and run the discovery team a few sprints ahead of the build team. This allowed them to complete user research, make sense of their finding, design user journey and come up with wireframes. Enough time for the Product owner to define-prioritise-refine user stories and feed them to our code monsters!

I would like to hear from User Researchers, Service Designers, Product Owners and Agile Coaches about their approach in government or private organisations.