Gustavo Elias
IG Group


Studied Computer Science in Spain. I started working as a C# developer during my last semester, and continued during so for a few more months. Quickly moved into IT training for a couple of years, teaching people how to use the company’s tools and its APIs. Moved to London in 2010 where I started my career in Java, first in the mobile billing industry and then in finance. I started learning about Agile during my first job there, and have always been a practitioner and a fan, to the point where I highly encourage my teams to become better at Agile. I have been a developer, a consultant, a team lead, and a tech lead during that time. Currently working as a Senior Developer for IG Index in the Marketing Intelligence team, trying to make sense of Hadoop, Spark and other Big Data technologies.


How to deal with a hot potato

In large organisations, sometimes projects and parts of the code base get shuffled around between teams. Projects that have tons of responsibilities, that are business critical and that are hard to look after. What happens when a self-organised team that has a continuous delivery system in place receives one of these legacy product that is the antithesis of best practices?  The talk approaches this issue with a real life example, highlighting the problems encountered and the solutions suggested and applied to each of them.

The talk starts describing what a hot potato is: a project that breaks all the good practices a team has in place but it’s business critical and needs to be handled. After a general introduction, it gets down into more specific details of the project that need to be addressed: two months deployment cycle, extremely long start-up time, huge amount of responsibilities... And then breaks them down into smaller, more approachable problems.
Once the problems have been reduced to something that can be handled, the talk approaches possible solutions. It explains pros and cons of each of them an why one is chosen over the other: the two-months deployment cycle gets dramatically reduced by creating a bamboo plan owned by the team; the start-up time decrements in several steps that include blue-green deployment plus code refactoring; and many other issues get resolved piece by piece.
Why are these solutions chosen over others? Sometimes for its quality, sometimes it's chosen due to certain constrains like time, resources, adaptability... Reasons for each of them are the centre of the talk.
Finalising the talk, there is a comparison between how the project looked at the beginning and how it behaves after all the improvements.

link to presentation
watch on watch on youtube