Pipeline is a digital service that is designed to help us all work together to deliver digital services, so good that people prefer to use them: https://pipeline.localgov.digital/.
Adopting Agile at Hackney
Over the last two years we have been working hard to change our approach here at Hackney, adopting Agile delivery and user-centred service design. This has meant lots of big changes in our team, how we work and the way that we manage our portfolio of projects.
With the move to Agile delivery comes a dramatic acceleration of pace and our shift from large projects to quicker, sprint based delivery has meant that our portfolio has become much more complex than before. As Lead Delivery Manager responsible for coordinating that I’ve been working with colleagues to look hard at how we can make that as easy as possible.
Hackney has devised its own Agile lifecycle, based on the Agile delivery principles set out in the GOV.UK service manual, and although we know that we need effective governance in place, it’s essential that this doesn’t slow down delivery. One of the key pieces of governance we need for delivering projects is an easy way to see what projects we are delivering and keep track of status and updates.
We are working as part of the wider local digital community
Hackney have committed our support to the Local Digital Declaration and want to help support collaboration in digital local public services. You can read more about why we think that’s important on our blog: https://blogs.hackney.gov.uk/hackit/in-support-of-the-local-digital-declaration. As well as managing our own portfolio of delivery, we also wanted to make sure that we could be open about the work we’re doing, share learning that others can use and identify opportunities to work collaboratively with other councils who are looking at similar challenges.
We started with user needs
We identified the following user needs:
- As a delivery manager I need to report once on the status of my project so that it’s easy to update stakeholders
- As a portfolio manager I need to see an overview of all my projects so that I can communicate our projects
- As a manager I want to see other authorities’ pipelines so that I can identify opportunities for collaboration
We looked to see what tools might meet those needs
We did an initial pre-discovery exercise to see what tools might best meet our needs. Agile isn’t new and there are a wealth of tools that are being used by Agile teams across the globe. But we didn’t find anything that felt like it quite fitted the bill.
We felt that the best match of the tools we looked at was Pipeline, which had been built as an alpha in 2014 by LocalGov Digital. This was a good fit with our aim of working collaboratively, but would need some tweaking to give us the portfolio tracking capabilities that we needed.
We decided that rather than buying a thing or making a thing ourselves, it would be best to contribute to a community tool and see how we might ‘stand on the shoulders of giants’. We got in touch with the LocalGov Digital team and were delighted that they were up for that.
So, what did we do?
Acknowledging that we needed something quickly and with our internal developers all at capacity we devised a brief and posted it onto the Digital Marketplace. We got strong bids and chose Rainmaker Solutions to help us to build on and iterate the great work that had already been started in 2014.
We held a workshop with key users to tease out what else was required to make the Pipeline service a tool that would add real value to Hackney and other public organisations. The previous iteration of Pipeline had a promising start but its use had declined, so we needed to create a tool that would add enough value that people feel compelled to use it. A quick discovery exercise delivered lots of feedback which was captured as user stories and prioritised in a backlog for an intense 3 sprint project.
As the Product Owner for the project I ran a session at the recent LocalGovCamp event in Birmingham to demonstrate the updated service and get feedback from peers. I presented these slides and ran two quick workshops. The first was to gather ideas of the functionality that people would like to see in Pipeline and the second was to discuss why people hadn’t used the first iteration of Pipeline and consider why they might not use the updated version. The functionality discussion threw up a few ‘Robocop’ items but the main thing we found was that Pipeline would meet the needs of the users in the workshop (you can see the feedback we captured here). The barriers gave us more to consider. We asked ‘why won’t people use Pipeline’ and found a range of concerns in response (the feedback from the discussion is here):
- Fear of working in the open
- Scared of failing in the open
- Duplication of effort
- Didn’t see what value it would add to their organisation
- A gimmick that won’t be used
- One size fits all won’t necessarily work for their organisation
‘Fear of working and failing in the open’ was a really interesting barrier. We were incredibly lucky to have Mike Bracken (one of the founders of GDS) visit Hackney this week. He spoke passionately about working in the open and failing fast and learning. I believe his comment was ‘it’s easier to deal with failing if you’ve been open about what you’re doing’. Fear of failure is a cultural issue in many organisations, including local government – my view is that working in the open enables us to focus on being clear about what we’re trying to deliver.
‘Duplication of effort’ is a tough one and is something we’re mindful of. Currently our project updates are posted in a public Google+ community, HackIT Delivers. Our Delivery Managers will continue to post their updates in the G+ community and will link status updates in Pipeline to the G+ posts. It’s not ideal, but is minimum duplication to share our work with a much wider audience. Further iterations of Pipeline will hopefully include open APIs that we can connect other project status update tools to.
‘Adding value’ and ‘it’s a gimmick that won’t be used’ aren’t technical blockers that can be fixed. We’ll show through doing. It’s a case of hitting critical mass: when the product is used widely there will be value derived from the tool and a compelling reason to use it. We can make that happen if we all use Pipeline.
‘One size fits all’; this was a challenge for this next iteration of Pipeline. At Hackney we follow the GDS approach for many things, but our project life cycle (HAL) has project phases that use different naming, which fitted better with how our organisation manages projects. To stimulate collaboration it was decided that Pipeline would use the standards that have been developed by GDS as that’s a model that we all recognise. So, it is a one size fits all approach but that one size is award winning and widely recognised as a beacon of best practice. We think we can adapt to it without much difficulty.
What Happens Next?
We are starting to use Pipeline and we’re keen that you benefit from it, too.
We’re meeting LocalGovDigital colleagues and the MHCLG Local Digital Collaboration Unit shortly to discuss how Pipeline might be used to help publish all of the collaborative projects they’re looking to fund and deliver – including applications for the Local Digital Fund that has been launched to support the Local Digital Declaration.
This latest iteration of Pipeline was delivered in 3 sprints. There were lots of user stories and additional functionality delivered but there is still a big backlog of additional user stories that we identified through the discovery work (you can see these on this Trello board). We will be looking at how we might fund an additional development sprint in the next couple of months, maybe using Pipeline we might find another organisation that wants to work with us to deliver the next release!