Last week I took part in the innovation spike at RBS. This post is my personal retrospective of the spike, findings and lessons learned.

Outline:

• What is an innovation spike?
• Format of the spike
• Technologies and tools used
• Findings and lessons for the future

What is an innovation spike?

In RBS the innovation spike means an event where small team works in a startup mode, trying to deliver new product or a service by using new technologies. The reasons for the spike are to explore new technologies as well as prove technical possibility and produce proof of concept for business.

The prototype that we delivered was functional enough to spawn discussions around business model and to take a look at product from the user perspective. It was also small enough to simply throw away if business assumptions doesn’t hold or technology is not good enough.

It is possible there is a better name for this event, however “Innovation spike” sounds great and naming things is hard.

Format of the spike

Our small team had 6 developers, graphics designer and a product owner. As a team we had all the technical and non-technical skills required to work on every aspect of product development.

We did prepared a little bit for the spike. Our product owner had a pretty good idea of business that we would like to validate. We had a small infrastructure prepared with some basic tools and did read on the choice of technology for the spike.

The spike took place in The Bakery London, which is a great place for a startup gigs with fantastic people ready to jump on problem and help. We run it for 4 days (Tuesday to Friday) with one day of preparation (Monday) and demo to business on the last day.

Technologies and tools used

There was a number of candidate technologies we wanted to try during the spike. We ended up with the following:

• Microsoft Azure for our infrastructure needs. Ubuntu VMs with Docker for spike tools and for our applications deployment
• GitLab, Let’s – Chat, Taiga.IO, Jenkins, Docker, Docker registry with Front-end and ApacheDS as LDAP authentication was our development tools stack.
• Meteor framework for all front-end and some backend development and Vert.x 3 with Java as a backend API services.
• VirtualBox with Vagrant for consistent development VMs.
• Atom, Visual Studio Code and IntelliJ as development IDEs

Some of the technologies were familiar to us, some were entirely new. We picked the above technologies as we wanted to give them a try and provide feedback to the rest of the bank.

At the end we didn’t use Taiga.IO at all as good old fashioned boards with stickies worked great.

Findings and lessons learned

The bellow findings represent my thoughts after holding conversations with others in the team.

1. Location is important

Being away from the office in a different location changes how you think. I mean it. Many things adds up towards it. Lack of dress code and non corporate style of office made everyone feel relaxed. Food and drinks took away the need of thinking about those things during the day. Little technical touches made us being more productive. Things like fast and easy Wireless Internet, big flatscreen connected to Apple TV so that everyone could share their screen when needed.

2. Cross functional, co-located team is important

It was great for all of us to sit around one big table, where we could pair with each other, ask each other questions or simply showcase what we’ve just done. Business (or product) owner could provide constant feedback and get us on the right path. Spike team in turn could immediately report back what was technical doable or what would take more time than we had.

The range of different skills across our team meant that we could handle all aspects of delivery lifecycle: design, development, testing and release.

There was simply no time wasting and no communication issues.

3. Having a leader is important

Having a leader is important as we got constantly refocused on the goal and next piece of work to handle.

A leader is not there to manage! Role of a leader is to propose initial structure and adapt it as we go along. Innovation spike is no time and place for a project manager.

In our case, our Mighty Leader prepared everything for the spike, time, place and the right people. On the first day of spike he introduced initial structure. We had a session with product owner, than we jumped to a small design phase and we started coding. In average, once every 3 hours we stopped and synched on what we managed to do.

4. Coming prepared is important

As I mentioned earlier the innovation spike is about exploring new technologies. It’s a learning exercise. However, we did prepare a bit and here’s why. Having a good starting point saves time.

Not everyone have to prepare on every aspects of the spike. I took time to learn a bit about Azure Cloud and prepare some basic infrastructure for our team. Others did complete introduction and tutorials on Meteor framework. Someone else created Mockup APIs. We all learned from each other. Someone always had an answer to a problem others were facing. Being prepared is always good.

5. Simple and good enough is GOOD … ENOUGH

Simple and good enough is more than enough for the innovation spike because it’s easier and faster to make. At the end, the final product is something that could be simply thrown away or taken as a proof of concept for a bigger project.

We were constantly reminded about not paying to much attention to unnecessary details, but to focus on the business functionality and pushing boundary of the tested technology.

Summary

Innovation spike was great learning experience. Finding out about new technologies and business opportunities. It was also great fun to be on. The key to its success was location, cross-functional team and being prepared. Having a good and focused leader made us very productive and good enough approach caused us to deliver successful and working proof of concept in a very short time.