Rescued Project

A client had a very large and complex gateway, which they were struggling to deliver. We were asked to look at the design and come up with a way of delivering it.

The Brief

When we were called to look at the project, it had already been running for some time. The idea was simple: to collect data from several sources and ingest it to their data lake. On the way, it had to check it for format, and ensure it is safe and secure to use. It was large, complex, and also fed data out to interested parties.


At first glance, the design covered most of what the client needed. It had content checkers, virus checkers, format checkers, and ways of ensuring data flowed one way. But there were many different configurations of hardware and software, which were confounding the client’s different parties.


We did a full review of the design, requirements, need, and business case, looking for were hints of priority. The project so far had taken the view that everything was top priority, therefore it was impossible to cut it down into smaller deliveries. Our experience has shown this is never the case. However, the warring parties, each decrying they were top priority didn’t help the situation. It had led to everyone wanting everything, and no one delivered anything.

Instead of looking inward, we looked outward to the business model for help. The two sides of the gateway provided data to support two core business capabilities. One was long-established, providing market analysis from ingested data. The existing gateway was very old and on a burning platform. The other was to support a digital transformation programme and was in its infancy. This then provided our priority – incoming gateway would take top priority.

The next challenge was to pull the design apart to extract the incoming gateway. A visit to the backlog revealed there was no indication as to which side of the gateway the stories, features, and tasks belonged to. Workshops helped with this categorisation and soon we knew what was needed for the incoming gateway, the outgoing gateway, and what was common between the two.

Prioritising the backlog and creating the first sprint is always a challenge, but eventually we whittled down the backlog into what we could deliver as the minimum viable product (MVP).

With the first sprint underway, the next three sprints were roughly planned and we discovered we could deliver the whole incoming gateway in quick time.

While the incoming gateway was now under way, we started planning the outgoing gateway. As the sprint backlog for the incoming gateway were completed, and if there was spare capacity, the engineers were allowed to start on the outgoing gateway’s issues. Steady progress meant by the time the incoming gateway had been completed, the outgoing one had been started on.

By taking a systems approach, and using the business model to direct priority, we were able to provide solid evidence to shut down priority arguments.


Split design

Using our extensive experience, we were able to split the design into easier deliverables.

Rapid delivery

By splitting it, we were able to deliver two smaller systems, rather than one big one.

Everyone satisfied

Rather than no one getting anything, we improved the situation and delivered it all.

Agile worked

Using scrum worked well in this case. Bringing our Scrum Master certification into use, keeping stand-ups to 15 minutes, and taking the problems away from the development team, meant the solution was delivered.


Splitting the solution into two different systems, got to the bottom of the priority.

Getting the solution delivered, after many months of arguing, was our priority. We put all our effort to increase the pace without sacrificing quality.

By settling priority arguments using irrefutable evidence from the business model, delivered a good outcome for all parties.