How to Scale Engineers on a project – Zircon’s Top 5

In my previous blog I examined how, like Cloud computing, working with Zircon allows for scalability.  Now, as promised, here is our Top 5 on the subject.

Our retrospectives (regular team feedback sessions) have a section specially designed to answer this question:

“How would we improve the information and resources available to the project such that a new team member would be able to hit the ground running?” 

While this is continually evolving for our teams, we’ve learned key lessons. Here are the current top 5.

1. How to build the environment for this project. This is a link to a space in Confluence that has step by step induction documentation to build the environment.

Depending on the complexity of the project, building an environment for someone arriving to the team can take half a day to half a week – and that is with all the information in place of how to do it. Without the documentation, the time it takes can grow to a couple of weeks. For team scalability, this is one for the larger bottlenecks. A documented induction process allows new developers to hit the ground running. Support is then only requested when it’s beyond the scope of what is already available. In turn, the missing information is added to the documentation to assist the next team members. Adding a new team member does cause a spike of reduced production. The shorter that spike can become, the better the utilisation of team resources.

2. Where is the location of the source control? + How to create a branch using this project’s naming convention.

Knowing the location of the source control is a relatively quick time saver – but the naming convention and how git flow applies to the project is something that is easy to get wrong to start with. If a developer has the confidence that they are starting on the project in the expected manner it can remove a barrier to project entry and strengthen the resolve to start making a positive difference. It helps a new developer put their best foot forwards.

3. What is the technical background information for the project, including requirements and design?

Documentation is vital to help new starters learn fast. Many of our customer’s projects suffer from technical debt, from documentation not being up to date, be it through requirements, designs, test coverage, code comments etc. The more an engineer can learn what is available to use as a resource and what is missing, the sooner they know where they can start adding value. If it’s a project Zircon developed from the start, all of the documents will be available in the expected locations. If this project is supportive in nature, in that Zircon are bug fixing, feature developing or maintaining existing software, then there will be details and links to what is available for use.

4. Read the coding standard – daily code reviews.

A major value in our development philosophy is to teach and learn and to test code early and often. Ensuring that code is up to the coding standard creates easy to engage with maintainable code. The long term benefits of code on a project all being written with the same standards is an issue for quality. When engineers come to the code later on to amend it, when it reads the same style as other code in the system, then the project is easier to maintain in the long run and any engineer who understands the standard can participate on the project. Zircon has built our own tool for daily code reviews that makes it easier to perform the task and all engineers have as their responsibility to ensure their code is tested daily. Often engineers code review across projects, so knowing where to find the coding standard assists with daily code reviews.

5. How to set up the test environment and key test concepts.

Zircon projects utilise Test Driven Development because it saves our client’s time and money and it ensures code is testable upon creation. Beyond the TDD process Zircon engineers also perform performance tests, integration tests, component testing, soak testing and more. Understanding how to interact with the test environment, and knowing what technologies are available in order to meet testing needs for a particular project, improves the speed at which a new member can generate results. As well as being able to perform tests, an engineer can benefit from knowing that the end to end development cycle for the project at hand exists and that they can slot into the workflow wherever needed.

If you’ve found this useful or have other recommendations to help improve project personnel scale up, get in touch.