So..are 2.0 Projects always a graveyard for ambition?
I’m writing this on a plane having been called in a rapidly growing Irish company to kick the tyres on their 2.0 project. It has put me in a reflective mood…
First up it goes without saying that 2.0 projects should only be undertaken if there is no alternative.
Scaling your existing platform to achieve the business goals is massively quicker, cheaper and less risky.
If that’s not an option and you really (really) need a new platform for some reason then how can you stop your 2.0 project being a graveyard for your ambition?
Do not make the mistake of setting up the 2.0 project as some sort of cathedral where the business will get nothing for ages until some time in the future (usually later than promised) where there will be a grand reveal and everything will be wonderful.
Stay true to the principles that have made you successful so far…the 2.0 project needs to deliver early and iterate, achieve continuous benefit delivery, and create a simple, agile, scalable system without any single points of failure.
How do you do that?
For the Hailo 2.0 (or H20 or H2) project which kicked off in June 2013 project we;
Set up using a standard scrum team structure and rituals.
Put everyone together in the same room.
Appointed a great scrum master in Simon Edwards.
Set up some clear business goals of
(1) Ingesting the high traffic Driver App GPS points by the end of July 2013.
(2) To have successfully completed a single transaction or “job” on the new platform by the end of 2013.
Promoted a very talented developer to architect in Dave Gardner (subsequently poached by Apple) and empowered and encouraged him to create something truly transformative.
Taking inspiration from Netflix Dave created a great blueprint of an API fronted queue based micro services architecture.
We created a couple of guiding principles/catch phrases for the team of “Config not Code’ and “Tech Free Cities” in that we wanted to able to launch the Hailo service any where in the world using web based configuration tools and dynamically configured apps.
So far so good..off we went.
Obviously not everything was “sweetness and light” though.
Some of the developers not in the H2 Team fundamentally disagreed with the suggestion that we might jettison some of the previously deployed technologies (PHP/Redis in particular) and some of them were left with bruised egos when they weren’t put in the H2 team despite their monumental talent.
So we had strong leadership (ahem), clear goals, a talented team, a transformative architectural blue print..next we needed to select the technologies we were going to use…