Our take on innovation Friday

Innovation Friday is a day we dedicate every week to plan and produce new customer facing features which have been chosen by developers. We are challenged to complete our features within a day which has proved to work really well. Both Front and Back End teams work together to transform innovative ideas into products that provide a solution to our customers. The products created are fully functional and are used by many of our customers, whilst some of the innovative ideas have been reverted and shelved as potential products for the future.

Innovation Friday began in October 2013. Instead of allowing developers to ‘innovate’ anything they desired, the managers strategically planned the innovative ideas that would create a solution for customers or speed up any daily tasks within Codeweavers. However, Codeweavers developers are still given the opportunity to come up with their own ideas for the business. Initially, this worked well, until some developers were still working on weekly MMF’s that they didn’t get time to finish within the week. Furthermore, on Innovation Friday, some developers were working on big projects that couldn’t be created within a day, which went against the reason why we started to allow 20% of our time to developing innovate ideas.

How we made innovation Friday work for us...

Friday 17th January was the date we decide to change Innovation Friday for the better. We were challenged to develop a single product in a day which required the combined effort of the entire Codeweavers team. A customer requested from our Sales team a product that was non-existent. We could all see how beneficial to our customers this product would be if we were to develop and it so the challenge was set, to create this product and get it to live in just one day.

How did it work?

Our Operations Manager and the Managing Director were classed as the ‘clients’ when we, the developers, were creating the product. If the product didn’t meet their requirements by the end of the day, the product would be deleted and thrown away.

We began the development with a ‘top down’ approach, to create a walking skeleton of the product. The Front End planned out a non-functional web interface and delivered it to our live environment promptly. Anything required to make the product functional was then pushed to the eager Back End.

The Back Ends first task included setting up the customer as a dealer in our system, and creating a range of test data including vehicles/products. As the web interface developed, further requirements on the back end were discovered and developers broke off into groups to develop the requirements.

We aimed to keep our environments ‘Green’ so we were always in a committable state and good to push code straight through to the Live environment. When the code wasn’t in a committable state the developers were straight onto tackling the root cause.

We found that as the project developed, it was like working with real customers. We had an instance of feature creep in the middle of the day with a responsive UI required for mobile devices raised by the client. At this point we all thought that our attempt at creating a product in a day was about to fail and so consequently, pushed back on the new feature.

However, we worked hard and by the end of the day our efforts were rewarded as the product was working with most of the required features. Our in-house clients were thrilled with the development and keen to try out different scenarios. Though the development did continue the following week with 2 MMF’s done, 1 defect raised and tests being added round the production code, we did deliver a fully functional product in one working day.

Problems we encountered

The main problem we encountered was our clients for this product were called into a last minute meeting. This caused problems because we had services that didn’t do what we intended so the choice was to change the service or alternatively create a new service to deliver the product we intended. We opted for the latter choice and within 10 minutes, had created the service to return what was needed, until we realised the information required changed to our original thought. The good thing at this point was that not much time was wasted and we had learnt more about the services needed.

If the client was available to discuss this problem, they could have informed us that the service we were to create wouldn’t return the required result. In the future we will make sure that we have all the information from the client prior to completing the development and ensure both parties are available to communicate throughout the journey of the product development.

As developers broke off to complete the services, they were not always informed of developments outside those required for their current task. This led to some tasks unfortunately being missed because of their similar nature. In one instance, a developer was working on a particular task and other developers assumed they were working on task that was intended to be completed at a later stage. For Example, as the day came to an end the final calculations were not yet started, as it was the initial calculations that were been completed. In this case a KanBan board would have highlighted these issues quickly.

We found developers with less experience found it more difficult to get involved in the product development due to the time requirements to get it done. The main issue for the less experienced developers was our internal applications which were combined to develop the product. Another problem we encountered was we needed to develop on our local machines, but certain features such as importing data for testing only functioned on the Live environment. This resulted in some initial work being done at the start of the day, to get this functional for both Local and Demo environments.

What did we learn?

Based on the tight deadline to produce this product we paused our demo service test and this should never happen. We have all been in this situation where we need something pushing to live and other issues are hindering that. We would like to say that the next time this is done we would not need to pause the test but do not hold us to that.

Due to time constraints, some best practices of TDD, SOLID principles, stubbed services, Kanban boards were not used. Reusing services designed for different purposes caused some issues and the short-sighted gains we initially thought we had did cost us time throughout the day in the long run.

Working in a team of 15 developers with a range of specialist skills, covering the full spectrum of web application development, we found that each developer played a key role in the project regardless of experienced. This showed us which developers out of the current team would be interested in working on different areas they never usually get chance to.

Was it worthwhile?

Definitely, after all the hard work and efforts the results were what we hoped for, with over 30 dealerships having now rolled out the new product.

A great result and an even better team effort, thanks to all who played a part.


By: Codeweavers - 01/04/14

More stories by Codeweavers

Our cookies

We use analytics cookies to collect information about how our site is being used. We use these cookies to allow us to improve our services. Tell me more