Hackney Spacebank: Weeknotes w/c 28 April 2019

We’ve been living our best agile life this week! A fully staffed team, buzzing with the anticipation of testing next week and glowing from a successful show and tell. The tenacious conversations and hard graft of the last couple of weeks is really paying off.

A couple of specific things to highlight:

Changing up the way we do show and tell

Show and tell is one of our forms of governance at Hackney. For it to be effective, we need not only articulate our progress but to proactively offer means of gathering feedback. Here’s what we tried:

  • Offered sticky notes and sharpies to every attendee when they arrived – setting the expectation that they would be making a contribution to our show and tell
  • Provided a feedback flipchart where participants could add their sticky note (important for people who don’t like speaking up in groups)
  • Broke down the show and tell into small interactive chunks and asked for feedback at the end of each section
  • Kept our content down to three key messages, including talking about the hard stuff (not just the shiny things)
  • Only used slides when absolutely necessary (additional slides were added afterwards for stakeholders unable to attend)
  • Every member of the team spoke
  • We practised beforehand
  • Every question answered honestly, even if that meant saying “we don’t know”

None of this is rocket science, but by the end of 30 minutes we had the most feedback from a show and tell to date. It wasn’t only the quantity but the quality improved too. Some great challenge offered in a positive way, really helpful signposting and the offer of collaboration from another team.

It definitely took more thought to organise, but not much more time in the grand scheme of things. The added value was worth the time investment.  

Meeting with Councillors Selman and Kennedy

On Thursday we met with Councillors Selman and Kennedy, the Cabinet members with overall responsibility for this project. We look forward to these conversations. It helps to understand things from their perspective and to hear what they need from us to support their conversations at Cabinet level.

They track our progress closely via weeknotes (we use these as a governance tool too). This means their questions and feedback is robust and well informed. These conversations keep us on our toes, which is good, and we appreciate the spirit and enthusiasm in which this regular scrutiny is offered.

Hackney Spacebank: Weeknotes w/c 23 April

Five things you need to know about Spacebank this week:

Sprint 3 is under way

We started the week with sprint planning. Our goal:

“Defining our measures for success, drilling down into what happens at the end of the library booking process, and sharing our progress with stakeholders via a show and tell.”

Paying for and accessing a library meeting room is the final piece of the puzzle in our user journey. This involves librarians, security staff, finance officers and the end user. To find out more, Winston has been out and about in the borough’s libraries armed with his trusty discussion guide, consent forms and a winning smile.

Mining the data

Joy, our service designer has been mining the data about library bookings. This is hard graft; I am suitably in awe of Joy’s eye for detail and rapid analysis. She’s been trawling through emails for information that will help us to understand:

  • Where we can co-design improvements which will smooth out the booking experience for users
  • What we can measure to determine whether or not we are making a positive difference

Preparing for show and tell

Seeking a bit of inspiration, we prepared for our show and tell by playing the anti-problem game. Planning for “the world’s worst show and tell” was a lot of fun, but importantly it helped us think differently about how we could communicate clearly and creatively. In particular, we are thinking about how to engage attendees more effectively so we get quality feedback on our progress.

Front end developer – unblocked!

I have written about recruitment challenges in previous weeknotes. I’m delighted to say that Sebastian will be joining the team on Monday. Getting this recruitment over the line has been a joint effort with Susan McFarland and Nic Teeman. A problem shared is a problem halved as the saying goes!

Testing, testing, testing

We are over half way into our prototyping phase. We’re getting ready for some rapid testing and iteration in sprints 4 and 5. Central to these early conversations is challenging ourselves to ask the right questions. These tests will put our assumptions under close scrutiny. What we learn over the next couple of sprints will be the foundation of our MVP.

HackIT Apprenticeships – how’s it going as a line manager?

We’re five months into our first cohort of our digital apprenticeship programme – there are 21 in total, spread over (almost) every team. When we started to plan our apprenticeship programme we knew that getting the right line management support and focus in place would be crucial to its success – and we’ve put high expectations on our line managers to deliver this.

This week we got together as a group to reflect on how it’s going as a manager on the programme: what’s going well, what’s not going so well, what do we think we could do next to improve and iterate our approach?

It’s not often that this group of people gets together to share experiences and reflect as a group so we ran this in a retro format – sharing our thoughts on the wall, then grouping them into themes and encouraging open and honest discussion.

What’s going well?

  • We’re really proud of what our apprentices are doing and learning – and of being a part of that
  • We’re all being asked a lot of questions – and that’s giving the rest of our teams a sense of pride in being able to teach someone what you know
  • There’s a real sense of giving someone an opportunity – our apprentices are all from Hackney or went to a Hackney school, and making a difference for local residents is a big part of our overall goal
  • We’ve noticed a developing sense of camaraderie between the apprentices – working together on projects, supporting each other
  • They’ve hit the ground running – and the speed of learning is impressive
  • It’s made us raise our game – when you have someone learning from you, you’re very aware of demonstrating great professional behaviours and knowledge as a role model
  • The learning goes both ways – we’re getting new ideas, different perspectives, and good questions that make us think

What’s not going so well?

  • Managing the relationship with the training / qualification providers is hard work – and is something we need to keep focussing on so that we’re making sure that our apprentices are getting the right training and support
  • Some of the content of the apprenticeship standard they’re studying doesn’t really fit with how we’re working at Hackney (for instance, there’s a lot of Prince2 content in the L4 Associate Project Manager qualification). Whilst we know that being able to recognise a Gantt chart in the wild is a useful skill, we don’t work that way. And for some there are aspects of their course that aren’t directly related to their role – so they’re having to work on modules that don’t feel very relevant to them. We need to make sure we’re supporting them with this as well
  • Finding time to spend on a one to one basis is a challenge – as is getting open and honest feedback on how it’s going
  • We put a buddying system in place for extra support but we’re not sure it’s really working that well – it’s something for us to look at and improve
  • We didn’t manage to get everyone set up on devices quickly enough – next time we need to plan this better
  • We’re not sure we always recruited the right numbers in the right teams at the right time – the whole programme was part of our overall restructure and for some teams adding apprentices came at the same time as forming a new team. There was honest feedback on how it’s been for teams managing this

So, what are our ideas for improvement?

We’re going to work on some new things:

  • How can we generate more opportunities for apprentices from different teams to work together?
  • Having opportunities for apprentices to work with colleagues in other services on short term assignments has worked very well – how might we create more of these?
  • How can we create space and encouragement for sharing work?
  • How could we redesign our buddying arrangements so that they better meet user needs?
  • How might we form a trailblazer group with other interested people to develop an agile delivery manager apprenticeship?
  • How can we develop our own mentoring skills?

And we will also be continuing to focus on building good relationships with all our providers, setting clear expectations of delivery from them.

What we learnt from prototyping

Hi, I’m David Swainston from the Business Solutions team and I wanted to give a following up on the work we did over the last month to create a prototype for a digital end to end service for Housing.

Here’s what we learnt over the 2 fortnightly ‘sprints’ in which we built Housing Helper – a chatbot for tenants and leaseholders.

  • Be guided by the needs of the end user first: as part of the Agile methodology, this was an opportunity to let our end user needs from the discovery phase inform the basis of our requirements. Traditionally, we would gather a whole raft of requirements from the service area to build a large product that isn’t necessarily tailored towards the needs of the user. It was really interesting to see the relative level of simplicity of end user requirements for a service (i.e. only what users really need), compared to the larger scope and scale of requirements we usually gather and work to. Obviously this can be dependent on the type of service/project being worked on – but we felt this is particularly relevant when it comes to designing public facing digital services
  • Look at existing products and services for design inspiration: as part of the design we looked at various existing consumer based digital services and products currently out there and widely used. These included Banking apps, Messenger interfaces, web chat interfaces and SMS to name a few. We considered the strengths of what these services offered in terms of functionality and user experience and fed this into the design of our prototype
  • Test with end users and let assumptions be challenged: ensure that the service you are prototyping is put in the hands of the users who will be using it. Get their perspective on things such as functionality, design, user experience and also additional user needs that may be identified and incorporated as requirements for future release sprints. Although our brief was to design a service for Housing, we learned from speaking to tenants that the service could be expanded to offer services across the organisation. We gained useful feedback on the certain design aspects, for example allowing spelling mistakes and slang to be recognised within the chatbot prototype and that the interface was easy to use
  • Having the right blend of technical expertise: this was really important when it came to us exploring different platforms that could support the development of the prototype. We benefited from having developers within our team who could identify and configure the cloud platform, the various API’s between different components and coding the chat bot framework. We also had a technical architect who brought the whole platform together and summarised this in a solution design canvas that enabled other members of the team and observers to understand the different components that supported the platform
  • Having a leader in the team/Scrum master: whilst Agile is a methodology to enable quick iteration and change, we soon found out that it is still very much a disciplined approach when it came to working through the design and release phase. It was useful to have a good leader to ensure that everybody within the team is aware of the role they have, and that release sprints are delivered in time to allow for the next iteration to begin. This is something that we can still tighten up on when applying Agile and its various forms for real projects, but as a first attempt away from the traditional Waterfall approach we didn’t do too badly!

Here’s a link to the Google Ventures channel on Youtube. We adopted the sprint methods described by GV in their videos, and the team found it really useful as a framework for our exercise to come up with the final prototype.

If there’s any questions you’d like to ask about the approach or the prototype itself, please drop me an email.