Everyone knows that when you start working for a new company there's some kind of discovery phase you have to go through. For me it wasn't different here at The Reference. During my first week I started of with making an inventory of:
- Applications we are using for Developing
- Tools we use for setting up our local environment
- Tools we have for issue tracking & project management
- Systems we use for code management
- Tools we use for internal communication
- Tools we user for documentation
I'm quite sure that every person who's working in a technology environment agrees with me that the landscape of tools we use can be very huge and confusing in the meantime. In order to have efficient working teams, you should aim to limit your tools to the bare minimum. The more tools your company is using, the more knowledge you expect from your team and thus the more time they have to spend on learning these tools.
Quick wins and prioritising tasks
When auditing your current setup and your current workflow the first things you want to look into are the small bits that will only take a little time to improve but will drastically improve your team’s efficiency.
I did exactly the same and I noticed that there was no consistency in the local environments that our team was using. Some of the developers were using a custom built Vagrant box while others were using an open-sourced Vagrant box and some others were just using a local XAMP stack. Team members working on the same project in a different local environment is a recipe for disaster. Soon or late one of them might face an issue with their infrastructure and the other team member won’t be able to reproduce it on her/his environment. We all know the statement: Works on my Machine. For me this was a no-brainer and a first quick win. In the next blog article I will share with you how we decided which tools would fit our purpose.
As I found out during my discovery phase that we were using various systems to store our code another quick win was deciding which system we should use, move all projects to this system and eliminate the others. By doing one thing I achieved two wins: there was only one single place of truth and we got rid of expensive license fees.
Agile working is in the DNA of The Reference and in 2017 there’s no way that you can avoid this anymore. As there were still areas of improvement we decided to create a product backlog of all the bits we would like to improve. This is now our internal project and we treat the project as if it were a client’s project. We estimate the workload on these stories and we are planning sprints to start working on these tasks. Ideally we would like to spend time on doing contributions towards Drupal or other open source software but first we need to make sure that we can increase our velocity for our client’s projects as they are still our number one priority.
With our internal team backlog in place and with our priorities all set we are looking towards a more productive 2018 where we actually start with giving back to the community. Actually we are already giving back to the community:
- We co-organised DrupalCamp Belgium
- We are actively involved in the organisation of Drupal Europe 2018
- We sponsored DrupalCamp Belgium
- We recently released robo-lando under the MIT license
Our next article will go deeper in the decision we had to make for the tool we are using now for our local environment.