Kevin, you seem to have many years of experience in IT consultancy. What would your top 5 learning points be for startups in FinTech related to the delivery services pitfalls? What are some of the recent cases you have seen in your practice?
Currently, I am working in the DevOps field which deals with delivery, but I have spent many years in the industry as a developer, an analyst, and architect I also spend several years as a trainer and mentor in the technology areas. Today I am talking from the DevOps experience. Some of my most recent examples would include technical delivery for a defence industry company, one of the world’s leading data and publishing companies, as well as banking and payment solutions companies. My first point which may seem obvious is that DevOps is still quite a new phenomenon and you need to follow good DevOps practices to ensure the code which is being developed, is tested and deployed rapidly because that’s where the business gets the value from. You can spend a very long time developing code and making it perfect but business gets no value until the delivery is happening as often as possible.
I would also say build automation from the beginning, starting with the infrastructure itself. You really want to make sure that the environments you build are always the same because that simplifies the testing and the delivery. When it comes to environments for developers there is an argument for maybe using a cloud-based development tool, but at the very least you need to standardise the development environment – again using automation because you see problems where developers all like to develop in their own favourite tool and perhaps end up with different versions of software libraries and if issues arise it could take a long time to resolve. The more you can standardise the environment the better. Also, you will want to build and refine an automation pipeline – so a tool like Jenkins is industry standard and we have used that in a lot of projects now. It helps you build and define the pipeline and all the steps that have to happen – the build, the test, and the deployment. Automation is key.
One last idea here is testing automation as this makes the whole deployment cycle quicker. You need to ensure that you are deploying a standard set of tests and of course, there are a lot of frameworks out there (and of course, Estafet is very big on quality engineers. For example Cucumber helps you automate your testing).
So most of my learnings at the moment are around DevOps and Automation fields and that’s where I find its key pitfalls. You want to automate early and as much as you can and that will speed up your deployment.
Where do challenges arise in the ideation, development and implementation of a software solution and how does Estafet approach the resolution?
The way Estafet approaches things is by using an agile approach. Now it can get all sorts of challenges, just like in any project, that could arise from the beginning like analysis-paralysis because you end up spending so much time worrying about what the solution is going to look like and analysing the problem that you never end up delivering anything. But then again, later on, you might get a churn from developing a solution without good automation and you have to keep on returning to the solution and run the same things again and again. With an agile approach, which is what we have always followed, you have to have a certain amount of upfront analysis so you can agree on the key elements of the solution, build in your automation early and aim to deliver often, in small increments.
Yes, everyone says they use an agile approach, but does everyone use agile properly? I am not totally convinced. Estafet has been doing this for a very long time with a lot of history of delivering projects, using scrum-based approaches. Doing agile correctly is what Estafet aims to do.
What was the most challenging assignment you engaged in while in Estafet and how did you approach its solution?
I was a scrum leader of a very large project team for a smart water meter solution for Arqiva for Thames Water. They contracted Estafet to pretty much do the turnkey solution and build the whole thing. They had one external traditional project manager while Estafet was doing it on our agile approach. We had the full resources in place – developers, testers, specialist database administrators, onshore and nearshore Estafet employees and contractors working on the team. So it was quite a challenge how you make this work with such a big team which is normally expected from an agile project. The way we did it was that we were very patient, split the team in 2 and worked on parts of the solution we had a scrum of scrums to bring the two teams together and we actually delivered the project. It was hard to keep such a big team together and focused but we succeeded and delivered to plan. Managing a multitude of different personalities including people who are not full-time employees of Estafet did have its challenges for sure.
When would you advise a start-up to outsource tech-related tasks and when should they keep such tasks in-house?
My personal experience is that there is no problem with outsourcing technical tasks. Currently, I am working with Elsevier and they have a great history of mixing internal employees with Estafet people and other external contractors. They have onshore, nearshore and offshore. The challenge is to ensure the technology that you use is well documented and implemented in a way that it can be picked up by anyone new joining the team. We work in a world where we move as much as possible towards open source technologies, whether you believe it’s truly open source even when we say it is. We are moving towards the situation where there will be many people doing the technical job of producing the code and even producing the analysis side of things. So I don’t think that a company should worry if they don’t have technicians on board at the beginning. If you are a startup, finding the people will slow you down even more and we already said we want to start delivering as quickly as possible. So for a startup outsourcing is a very sensible decision as long as you can trust your partner to produce things in a maintainable way. I have worked in the industry now for many years and what the best consultant should be doing is to make sure they can leave the project and be replaceable. Unfortunately, that’s not what some contractors would do – they try to build from the view that they make themselves indispensable. But I have never taken this approach and nor has Estafet. We always try to produce something that is maintainable and can be handed on so that in the future things could be brought in-house and this is the best approach. Estafet effectively makes itself dispensable by producing a good design that can be taken on by others in the future.
In your view, how is Estafet different from other nearshore delivery partners?
I am going to be slightly biased on this. I am in the UK and I would say that Estafet has a unique blend. We have a whole bunch of keen, talented, mainly young developers and test engineers in Bulgaria and other countries, the nearshore element, but alongside those, you have very keen and multi-year experienced people in the UK. That blend is very special and unique that Estafet could offer to a customer, the blend of old grey heads with the keen young, talented enthusiasts works quite well.
