Futures Academy 3: Time to think, space to create

Earlier this year, Greg, Bob and Sean, James, Dan, Harvey, Jack and I, assembled to form the third Futures Academy cohort, tasked with creating and prototyping innovative solutions to the Council’s trickiest problems.

Our problem statement, saying the tech services portal isn't meeting needs and is pushing people to call instead. Improving this will lead to fewer calls.
We came up with a problem statement to focus our work

What brought us together

We signed up for loads of different reasons.

Greg had worked in the videogames industry and so already had a really good grounding in Agile practice and wanted to see how it could fit into the way the Council works.

I initially thought I was signing up to develop new skills and ways of working, but to be honest, it just looked like it would be a lot of fun. I’d just finished a really intense piece of fieldwork for a research project we were working, and fancied doing something different with some protected time to get really stuck in.

"Previous participants went on to join the agile-using Service Design team which is an exciting area within ECC"


Even though my background is in research I wanted to try a more collaborative way of working. I was hoping that slowing down and taking a step back to use new tools and matrixes would help improve the quality of the research that we do and prevent us making assumptions early on.

Bob was curious about Agile and passionate about ensuring we design our processes around residents.

And Sean got the call last minute and jumped at the opportunity despite not having much prior experience and got stuck in straight away.

A3 pieces of paper with our user research guidelines for interviews and desktop research written on them
We came up with a plan for user research to validate our assumptions


How it works

This cohort was a bit of a departure from previous groups. Instead of having 5 days to ideate and prototype, we committed to 2 days a week over a 10 week period, alternating between learning weeks and practical weeks.

We started by framing our problem statements then moved on to designing and conducting our research. Once we’d analysed the insights from this we started ideating and sketching. Then we could prototype these ideas and start the process of iteration.

"It's completely different to other courses I’ve been on. We really learnt at pace and it felt very liberating to be presented with a new challenge each sprint."


For me, this was great. I feel like we were always learning, and every week we managed to expand on the skills we’d developed in our day jobs.

"I found learning one week and applying that knowledge the next  really embedded the information and cemented the learning.”


I think we all really benefited from the structure, and found it really helpful embedding what we’d learned by carried out in practice. It was also really liberating to work at such a frantic pace. Applying what we’d learned straight away helped build up everyone’s confidence.

Picture showing post it notes on brown paper
We mapped the process to understand pain points

How did it go

Once we got going there was a real sense of comradery. We learned a lot from each other, as well as from Ashley and Kurtis, who were leading the programme.

We were all slightly out of comfort zones, and there definitely was what Sean called ‘healthy debate’ over next steps, but it was always super-supportive. I think we’ve all taken away things from each other that will help with our day jobs, that I don’t think we would have learned otherwise.

"Working with people from other parts of the organisation meant I learnt new skills away from the programme that I am able to now apply in my day job."


It was quite a challenge to balance the space and time needed to fully commit to the programme. I know I found myself giving up my evenings and weekends to keep on top of the work we were doing.

"I’m incredibly grateful for the support of my team to give me the ‘space’ needed to get the most from the project."


Experimenting with new ways of working is really tough, and does require a bit of space to think and make sense of it all. It’s important that teams and managers understand this.

Picture showing the team presenting their ideas
We synthesised our findings and presented them

What we learned

We all learned loads from the programme, whether it was the ‘correct’ technique for ripping a post-it note from the stack or how to avoid letting 'perfect' get in the way of progress.

The process really tested our knowledge gaps and assumptions before we got anywhere near thinking about solutions. It definitely highlighted the way a lot of what we do is based on preconceived ideas about what we think people need.

We codified this approach in the double diamond.

An agile double diamond diagram, showing how teams discover, define, develop and deliver
The double diamond method was our guide throughout the process

Overall we found the whole experience really rewarding. It was great to have the freedom to really prototype an idea knowing that we weren’t constrained by the normal organisational processes.

"It’s a really rewarding training programme.  It does require a lot of commitment but at the same time I had fun and got to network with some great colleagues."


Bob presenting findings at our retro
We had a show and tell at the end of the programme to feedback what we'd learned

We were free to innovate and produce a solution that resolved the problem statements.

We all had a great time working with each other.

"Absolutely fantastic. Tremendous fun, interesting challenges and worthwhile knowledge all while working with some brilliant people."


Personally, I found time a huge barrier. It’s something that you’d have to consider if you were thinking about applying.

One of the biggest takeaways  for all of us was that Agile can work here, and that there’s a growing appetite for it across the organisation.

It must be doing something right, Greg and I both now work in the Agile Service Design team.

Share this page


  1. Comment by john mortimer posted on

    The councils trickier problem, is only a problem if we assume that demands should be self served. That idea is an internal view of what we think is right. However, if we look at government services from the perspective of the person who needs than, the evidence shows that many demands and the peoples circumstances who are making those demands need to talk to a person. This is in particular for those who: are in need to arrange a debt repayment, anyone who wants to ask a question, many people who already have a case open with the council and need to communicate with their officer (eg Planning), people who have just moved into the area and need to set up arrangements, people who are in need in general, people who are desperate (no heating for repairs), people who are being messed around by the council (repairs not being completed), people who have questions that need a follow up discussion before deciding (e.g. licensing), those who are not online or have emails (homeless, or in financial trouble, basically those most needy)
    Service design is about designing services, rather than Digital front ends (eg Universal Credit fiasco)

    • Replies to john mortimer>

      Comment by John posted on

      Hi John, thanks for your comment.

      The project that the team worked on was looking at ways to improve the current self-service portal for raising internal IT issues.

      Their research showed that staff liked being able to self-serve, but wanted the portal, and the process behind it, to be clearer and easier to use.

      Instead of starting with a solution, the academy gives staff a chance to frame problems, test prototypes with users and iterate on them.

      This aims to give them the skills they need to design and build robust, user-centred services for the residents of Essex.


Leave a comment

We only ask for your email address so we know you're a real person