Delivery during a pandemic

We have worked hard at Deeson to develop a robust DSDM agile framework for the delivery of our projects, which has held us in good stead for the type of work we regularly do. Typically these are four to six-month development projects, developed iteratively in two-week Timeboxes. However, when COVID-19 hit, we had one client wanted to respond rapidly to the crisis and we knew that our full process wasn’t quite fit for purpose.

We needed to be even more nimble and agile than we’d ever been before and focus everything around delivering a minimum viable product (MVP) within eight weeks from concept to launch.

Background

Our client, the Tony Blair Institute for Global Change’s Generation Global programme, wanted to ensure that despite the vast extent of school closures around the world students would still have access to safe and inclusive dialogue spaces to develop their global citizenship skills in a time of increased need.

How we solved their problem

The process

We started with a remote strategy sprint using online collaboration tools such as Mural, to better understand the problem and to develop a solution together. This remote strategy sprint allowed us to rapidly develop a solution that involved the creation of ‘learning pathways’, designed for students to individually complete themselves.

Define the outcome

We worked together to define an outcome for the project; it was this outcome that our client would be buying, rather than a set of features:

“Individual students will be able to register themselves as Generation Global users and complete learning pathways followed by interaction with other students on that topic, both written and verbal.”

Identified the themes needed to deliver the outcome

Our strategist and lead developer worked together to identify the Epics i.e. the themes/chunks of work needed to deliver the outcome and distributed the budget across these to illustrate how the budget was likely to be spent.

These estimates were not a commitment but allowed us to be confident that the outcome we set at the start of the project was achievable.

We then used those numbers to forward plan throughout the project to give us an idea of what was achievable within the remaining budget.

Defined how we’d like to work

We agreed on an outcome and a number of development days tour client had the budget for. We then worked together to achieve that outcome.

We delivered this using the Kanban methodology, with the Product Owner deciding daily on the priority in which we worked through the backlog of tickets.

This is different to our previous projects with Generation Global, where the Product Owner has planned a full timebox based on fully-specified tickets with estimates, and therefore a clear understanding of what will be achieved in the two-week timebox.

Agreed how we’d track progress

We wanted our focus to be on flow efficiency i.e. ensuring a consistent flow of work through the board which provides a faster, more predictable and reliable delivery and delivers value earlier to our client. In order to achieve a good flow efficiency, we were intentional about creating all tickets to be a similar size.

We used T-Shirt sizes for estimates. T-Shirt sizes are extremely rough estimates in terms of a small number of predefined categories e.g. Small = up to 0.5 days, Medium = up to a full day, anything larger than 1 day was broken down into a series of smaller tickets.

Defined a release plan

We tagged each feature with a ‘release’ which gave us a view of how well we were progressing through a set of features related to a release. As priorities shifted and changed, we could easily update the release.

Agreed on a workflow

Typically, we use a dual-board setup in JIRA but, for this project, we had both the refinement and development taking place on the same board.

The first column was where the product owner prioritised tickets for development. As they were being refined, we would pull them into ‘solution design’ before moving them into ‘ready for development’ for the lead developer to estimate and assign. Developers would then pull tickets from this column in priority order.

Set work in progress limits

In order to maximise flow, we minimised work in progress so each column had its own worked ion one ticket at a time and didn’t work on another ticket until that was delivered.

The work in progress limits changed depending on the size of the development team which could vary during the project. However, for the majority of the project the ‘In progress’ column was limited to two items only, one for each developer.

Talked about the risks

As this was a change in approach for our client, it was important that we clearly outlined the risks associated with it. We couldn’t guarantee from the start that their budget would get them everything they needed!

One of the risks we identified early on was that our high-level estimation was based on a very condensed discovery period and therefore it was highly likely that our understanding and effort involved to deliver the MVP would grow.

Another risk associated with not undertaking a detailed discovery was that it might lead to inefficiencies later on due to change/additions in requirements which we collectively missed or couldn’t have foreseen.

We tracked ‘additions to the scope’ and discussed them in our weekly account calls. We continually had honest conversations with Generation Global about when we thought a project outcome might be impacted.

What interesting things did we find out?

Nothing stands still

We quickly realised that a normal delivery plan in a google doc didn’t suffice, so we created a more dynamic version in google sheets which was quicker to update. We reviewed this weekly with the client and project sponsor and used this time to update on progress, track additions to the scope, and discuss the potential impact on the delivery of outcomes. We also discussed Forecast dates for future releases.

Estimates

I was interested to hear that a couple of developers found the idea of not estimating in hours or tracking time uncomfortable. The team were concerned about how we would know if we were “on track” and they felt it was harder to track how well they were doing against the “estimate” as the sizing was intentionally vague.

In retrospect, we probably under-estimated the need to educate the team on the process and approach.

Results

Overall we found this new way of working to have worked really well for both our team and the client.

Here are just some of the “wins” we’ve already seen as a result of working in this way together:

• We did our first release after two weeks of development starting
• We can quickly understand where delays form — a heat map report indicated that items tend to stay in QA and ‘ready for development’ longer than they should, which gives us a focus for where we need to make improvements and find further efficiencies
• We learnt that Kanban works well for this type of project
• We’re working towards using metrics to determine cycle time and throughput so eventually we might anticipate removing ‘estimates’ all together

And finally…

We’d like to say thank you to the Tony Blair Institute for Global Change and the Generation Global team for their role in making this a success.

This wouldn’t have been possible without your ‘buy in’, trust and product ownership. The outcome (https://adventure.generation.global/) is a real testament to the brilliant partnership we have built.