Feedback on my 30th Inception

Andreas England
5 min readMay 10, 2021

I’ve just completed a short Inception for Ofgem, the Uk’s non-ministerial office that protects consumers in the energy sector, and more importantly for me, is part of moving the UK towards a greener energy system.

Remote Inception setup

Our project is to set up the service by which the UK will pay subsidies to the producers of bio-methane into the national grid. We’ve just passed our Alpha service assessment, and decided to run a weeks workshops (called an Inception) to start the Beta phase of our project.

The timing of our project cycle meant that the Inception would fall on a week with a bank holiday week, IE. I had to run a 5 day workshop in 4 days.

Tooling up

Due to the security restrictions that we’re obliged to follow, and the ongoing pandemic, the workshop (as indeed the entire project so far) was run using Microsoft teams and Mural. I’ve issues with both of these tools, and consider Zoom and Miro to be far less intrusive products. You opinion may differ, however I’m going to be keeping 8 people engaged and productive for a working week, so I reckon I know what I’m talking about.

I work on an 18 month old Mac pro 15" coupled with a hi-res external monitor, a pair of Sennheiser HD650’s which have to be powered by a DAC. This kit enables me to run a remote workshop for 8 hours, without fatigue or aches & pains. I’m old enough to need to wear glasses for screen work, so appreciate the Sennheisers not giving me a headache when the arms of my glasses are pressed into my head.

Team Makeup

As the team are already established and other that a few substitutions of contractors, this group of people are able to begin being productive with the minimum of encouragement. Indeed if I’d chosen to ‘warm them up’ up with a cute icebreaker, would have been counter productive.

Though product management is my discipline at Made Tech, in this scenario, I’m acting strictly as a workshop facilitator, and so enabling the incumbent product manager to take ownership of their domain from the start. This neatly summarises the key objective of the Beta Inception — to enable the team to be delivering value quickly.

Juicero video screenshot
Juicero

Methodology

Day 1 starts with a presentation from myself, and the project sponsor providing a rallying cry. We set ground rules, IE. be present — no wallflowers. Instead of an Icebreaker, I showed the team the ‘Juicero’ $120m startup failure. It raised a laugh, nobody had heard of this Silicon Valley startup, and I believe I made a point about ridiculous over-engineering without common sense. We then populated a lean canvas board to identify areas of weakness in our proposition as it stands at the end of Alpha. We the negotiated the scope of the Inception , prioritised an Affinity grouped Inception backlog of epics that had been identified in Alpha.

Day 2 runs with just 2 identified sessions, a morning of To-Be Blueprint Mapping, and an afternoon of To-Be Prototyping. I’ve used To-Be user story mapping for the majority of the Inceptions I’ve run, due to it’s lightweight and quick-to-learn nature. This service however has lots of backend, or behind the scenes work, so I added swim-lanes to the To-Be user story map. This enabled the journey to be modelled along a linear path, with stage gates and other user journeys to be aligned.

Risks & Risky assumptions using Cynefin grading
Risks & Risky assumptions using Cynefin grading

Day 3 starts with a Risk & Assumptions session, this enables all the worries and concerns the team have been gathering over the Alpha period and the first 2 days of the Inception can be shared, collated, grouped, and ranked. Following this session, the rest of the day is a continuation of day 2.

Risks & risky assumption mitigation board
Risks & their mitigation

Day 4 begins with a session aimed at managing the risks identified on the previous day. Sleeping on a problem is a method of problem solving that’s often ignored because we think we need instant results, however as this project is running for another 6 months, I feel we can afford the luxury. The rest of the final day is spend agreeing governance, ways of working and what we’ll achieve within the next few sprints.

What went well

The team had felt like a disparate group of people, organised around their capabilities, and only sharing knowledge when required to. By the end of the Inception the team had begun showing high performing traits. They assembled quickly in the morning, acceptable behaviour was quickly established and self indulgent monologues (a particular problem on this team) was minimised. The fact that we’re a mix of Ofgem, Made Tech and contractors from both sides was dissolved into us being a single team working towards our agreed goals.

I ran a Feedback session at the end of each day. I felt that calling this a retrospective was too heavyweight, and so used the Thoughtworks style of calling out appreciations for team members, then defining the days themes and attributing ‘engines’ and ‘anchors’ to them. This resulted in a 10 minute session that didn’t fall flat when little content was forthcoming.

What went wrong

We didn’t do any prototyping. I’d assumed the sessions would be a morning of user story mapping, followed by an afternoon of prototyping to wireframe level. The team mix (no service designer or UI/UX capability) and unclear policy intent resulted in a lack of impetus to move the stories to prototype level. I chose not to push the need for prototypes, instead got team buy-in to iterate the To-Be story maps.

I almost ‘snatched defeat from the jaws of victory’, when I asked the team to estimate the work we’d done in the Alpha and the Inception, and then plan the sprint capacity. I’d totally misjudged the state of the project stories, and the teams confidence with them to reasonably ask them to begin sizing and planning (“your compounding guesswork on guesswork”). Thankfully we’d agreed to define sprint goals and the team where happy to work (and populate the roadmap) using this model.

what will I keep doing

The overarching strategy of enabling a team to begin working in a collaborative and agile manner is still a the key benefit of running an Inception.

The business needs for a prescriptive workshop schedule with predefined outputs has irked me since I designed my first Inception in 2014. These workshops proved no different, and I’ll move towards defining outcomes over outputs.

I’ve always sold Inceptions as being a tool to reduce project risk, and this project has cemented this view in my mind.

--

--

Andreas England

Head of product management at Made Tech, Manchester, UK