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.

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 the 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 hints of priority. The projects’ stakeholders all believed their need was top priority, and the incumbent architects didn’t feel empowered to contradict. 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 delivering anything.

Instead of looking inward, we looked outward to the business model for help. The gateway was in two parts: an incoming gateway, providing data security, which was then fed into their data lake for further processing. The other, an outbound gateway would provide secure data for the digital transformation project, placing data into a secure area for clients to analyse through APIs. Both gateways were on burning platforms and took a siloed, inflexible approach. Getting new data feeds on line was a tedious affair, and took weeks. The outbound gateway was more structured, and was a little more (but not much more) flexible.

By analysing the business model, it was clear the incoming data was the lifeblood of the business. Since the organisation lived off it’s data, the incoming gateway was considered a priority. This was clear, irrefutable evidence. Arguments were put for making the outgoing gateway a priority, but with no contrary evidence, the incoming gateway was going to be the first deliverable. Also, the new gateway would be faster and more flexible, therefore, more important to deploy. 

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. We also ensured the design met the governance standards to ease the deployment.

Prioritising the backlog and creating the first sprint is always a challenge. We still had very senior stakeholders who were arguing amongst themselves about priority, and this where using Provantage helps. Being impartial, we can provide an outside view of the situation, without being blinded by internal politics, or upsetting long-term working relationships. Soon, we had a good prioritised backlog, and the development began. Within just two months of being on the project, Provantage delivered the MVP.

While the incoming gateway was now under way, we started planning the outgoing gateway. As the sprint backlog for the incoming gateway was 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 quickly, and in as helpful way possible.

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

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

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

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.