The challenges of a small and competitive High-Tech company
AX2 is evolving.
That is what any good digital development agency should do. Constantly. In this domain of activity, there is no room for complacency. And with evolution — a.k.a. changes — come challenges.
Here are some of the challenges we are facing right now:
How do we effectively lead day-to-day production for multiple projects at the same time? How can we dedicate some of our time to R&D? If so, what should we get out of it? Is there a best way of integrating new people? How do we launch new projects while including more people in the process, and dealing with current production?
Finding time for the day-to-day production
Our clients are the most important to us and we want to provide them with the best ideas, tools and support.
In this regard, we need to make sure that we have enough time to spend on developing new features, functionalities, modules, tools and ideas for them.
It’s a day-to-day job, but we want to figure out the best way to plan ahead and provide constant improvements while still being reactive enough to their emergencies.
How we do it:
We are using the Agile methodology and are still figuring out the best durations of our Sprints and how to fit the unplanned in the process. So far we are on 2-week duration sprints, which means 10 working days minus the R&D days. In each sprint, we incorporate up to 5 different projects to work on.
We use Trello to organize our sprint board. The whole team logs in to the same board. We organize lists and cards, each card being a task to do.
At the kickoff meeting of the sprint, we go through each card, define it and evaluate the time we think it will take. We then attribute the card to team members using the tag system in Trello.
Once the sprint starts, each member is free to pick from the different lists, although a “Next up” list is a priority compared to the others. The cards are being moved during the sprint depending on their progress. We have dedicated lists for Testing and Approval, so by the time a card is moved to the “DONE” list we are sure that the work that has been done is working well and is stable.
Doing R&D
Because we want to always be up to date with the latest technologies and innovate, R&D is essential to us.
By now, we all know that the best way to learn and be good at something is to love it. Fortunately, we are a bunch of passionate people and the list of things we are curious about is endless.
The problem is that Research takes time. It involves reading articles, watching conferences, discussing, experimenting… all of this takes time.
That is the reason why AX2 strongly believes in the “20% time policy”. We all know how Google encourages their employees to spend 20% of their time working on what they think will most benefit Google in the future. They use that time to be more creative and innovative. Well, we follow that same path.
How we do it:
“Friday R&D” had been a regular part of our weekly routine for a while at AX2. Dedicating one day of the week for R&D is great but we realized that at the end of the day, we couldn’t accomplish enough and we would have to wait a whole week before coming back to the same subject. This meant investing time again to get our brain back where it was when we left, as the momentum had been killed.
On the flip side, we wanted to capitalize on that momentum of the first day and so we naturally decided to switch to “Thursday and Friday R&D” once every two weeks. The switch enabled us to take advantage of the reactions and findings of the first day, carried over to more concrete work on the second, instead of leaving a whole week to pass in between.
It has made setting and achieving higher goals for those two days of R&D much more realistic. Each of us really enjoys those R&D days, but we are still trying to figure out the best way to get something tangible out of it, either a presentation to the other teammates on a new technology, a new server set up, etc.,
We are discovering new tools, like Screencast-O-Matic for example, to help us in the process of sharing the information together as efficiently as possible.
Integrating new people
Going through transitions and growing implies involving new people in the process, and integrating new people also takes time and energy. Each person has a different background, a different learning curve, different habits, personalities, and so on. At the end of the day we all need to work together, and enjoy ourselves while doing so.
How we do it:
We started by changing the office layout to improve communications between teammates, making it easier to show screens to each other. The idea behind that is to make it easier to talk together without disturbing the focus of the rest of the team… Some of us prefer moving to different tables and rooms during the day (or even working remotely from cafes sometimes) to kill the routine and get their creative juices flowing. We encourage that for people who need it.
Using Github as their development platform, our programmers and integrators interact with one another. Pull requests let them tell each other about changes they have pushed to a repository on GitHub. Once a pull request is opened, they can discuss and review the potential changes with other team members and add follow-up commits before the changes are merged into the repository. Pull Request reviews, also known as PR reviews, are a good way to involve team members on different projects and also to double check and test the code.
We are putting a lot of effort in improving the knowledge transfer. For that we need to define new conventions (for naming files, commenting codes, etc.,). We need more documentation, guidelines, and oral presentations but also more sharing with others, hence this Medium account. So feel free to comment on our posts and share your ideas with us.
Launching new projects
We recently started two very exciting new projects. Big ones. There are many ways to launch new projects, but less ways to get it right from the beginning.
We want to avoid each department working one after the other. Indeed, what’s worst than the developer seeing the designs for the first time a month after the project has been launched and reconsidering every little choices?
Same goes with decisions being made by departments without consulting the others. What we aim for is co-operation and common decision making so that we can all agree from the beginning on what’s best for the project.
How we do it:
Design, Analysis, Servers setup and configuration, Backend setup, Frontend setup…
As a small company, we have 2 to 4 experts in each of these fields, so they first talk together before making decisions. They also discuss (a frontend + backend meeting for example) every important step to make sure the decisions make sense in the whole picture.
