In our development team, we evaluate performance according to four main drivers – quality, productivity, efficiency, and teamwork. There’s no single trick to increase your team’s capabilities in these respects — rather, they’re all interconnected. An improvement to one metric, with proper safeguards, facilitates improvements in others. Here, we present eight best practices for software development that will generate a cascading effect for your entire team’s skills and capabilities.
Tip 1. Establish A Coding Standard
If there’s a starting place for improving a team’s performance, it’s maintaining and enforcing a coding standard. This is like establishing a Standard Operating Procedure as relates to coding best practices, style guides for the programming languages you use, guidance on what constitutes good enough code, and other recommended resources.
More time is spent reading code than writing it. A piece of software may last from 6 to 14 years. Software developers change jobs about every two years on average. Programming languages can rise and fall in popularity during this time. A coding standard ultimately makes it so everyone can read the code faster, understand it easier, and find bugs, deal with technical debt, and refactor more efficiently.
Tip 2. Daily Code Reviews
Serving to reinforce the coding standard, code reviews help in the onboarding of new developers, and help to find bugs. For best results, it’s advised to keep code reviews down to one hour. That’s deemed sufficient to cover 400 lines of code and detect 70-90% of defects. Code reviews are also useful for sharing knowledge across your team, a good training mechanism to reduce siloing.
For best results, try to have code reviews conducted very shortly after the code is written, so it’s fresh in the mind of the original developer who wrote it. Reducing time on code reviews increases the chances of letting bugs slip by which has all kinds of negative consequences above and beyond hurting productivity.
Tip 3. Regular Retrospectives
At the end of every sprint, conduct a review with all developers to determine what went well and what didn’t. Make an active effort to create a “safe environment” where everyone is encouraged to be upfront about their pain points. What can other team members do to make their job easier? What work processes need to be re-evaluated?
There are quite a few different methodologies for conducting retrospectives. Try a few to see what works best for your team. Many teams try to keep their retrospectives down to an hour, but some may take two. This is an investment. How many team members are actively contributing? How many sprints do you run each year? Multiply the two together and you’ve got a lot of ideas to improve your team’s performance.
Tip 4. Project Management Software Training
Whether you use JIRA or any other Project Management Software (PMS), make sure your team is trained a) on how to use it, and b) the standards for defining, assigning, and reporting on tasks. Well-defined tasks reduce chances for miscommunication and confusion. Enforcing PMS standards helps you to track your cycle time and better estimate work for each sprint. Startups are especially prone to starting with one PMS and shifting to another only to encounter the same problems. The issue probably is not the PMS, but how your team is (or is not) using it.
Tip 5. Select the Right GIt Branching Strategy
Perhaps a small point, but an important one for how you manage your team’s work processes. There are five main Git branching strategies, suffice that it’s recommended to a) start simple and add complexity only when needed, and b) match the branching strategy you use according to your team’s structure and project requirements.
- GitHub Flow and Trunk-Based Development – the simplest, perfect for startups and continuous integration/delivery projects.
- GitLab Flow is the most flexible strategy for projects that require supporting multiple environments.
- One Flow and GitFlow branching strategies are more complex, best suited for enterprise and release-based projects. GitFlow is cumbersome but may be required for teams with many junior developers. OneFlow is simpler in some ways, but is best for teams with more experienced developers.
Your choice will determine how much administrative overhead is needed, how easy it will be to read your project’s history, and likelihood for bottlenecks in your review processes.
Tip 6. Keep a Handle on Your Git Repository Size
Your git repository will grow relative to how many developers you have, how frequently they commit, and your file sizes. Over time it will take longer and longer for your developers to process their tasks. Not only will your developers spend more time waiting for tasks to be completed, you may incur additional service costs.
In a worst case scenario, if you can’t afford to upgrade your hosting account, development can be halted until you reduce the size of your repository. The main thing though is to be aware of the incremental increase of waiting periods as that scales according to the size of your team.
Tip 7. Use Automated Software Development Analytics
If you’re focused on improving your team’s capabilities, automated software development analytics is enormously helpful. Services like Gitential or WayDev can provide you a wealth of data to identify potential coding quality issues, process bottlenecks, developer burnout, and even assemble the optimal team for each software project. Besides being able to track development metrics at the company, project, team and individual level, you can track the impact of all of your team development efforts.
Tip 8. Experiment with Tools
New software and electronic devices are emerging daily providing new and more efficient ways to perform tasks. It’s always a net plus when you find a tool that can easily automate monotonous and routine tasks. AI may push the envelope further. So, encourage your team to keep their eyes open for software, resources, and devices that might make your team more productive.
Before just switching though, measure your existing process to see how much time, effort, and money it takes. This gives you something to compare against. Have one of your team members evaluate it to see if they would actually recommend it. And if so, try a few experiments to see whether it will save you time, money, or even just improve the quality of life for your team.
Of all of the drivers, Quality is in most respects the most important of all. A bug that gets through reviews and testing can have a huge negative impact – and require fixing at the expense of productivity. But, “perfect code” isn’t well-suited to a business environment. So, in practical business regards, productivity ends up being the most important driver for software development. So, though we can debate which driver is most important, we can also say that they’re all important and that an improvement in one makes it easier to make improvements in all software development efforts.