.png?width=714&height=129&name=Social%20Icon%20(2).png)
Establishing a Solid Foundation to Ensure Success
Stock image from Canva
Development teams often are composed of highly diverse members. Each member will have different coding standards and processes that they would prefer. It is complicated enough getting a co-located team to agree on these matters but for distributed teams, where does one even begin? This post is for all the teams out there looking for a way to either get started on building up or improve their current practices.
Plan Purposefully
Having sticky notes on task boards in an office used to be the norm (and in some organizations, this is the best solution), but even co-located teams are leveraging the power of centralized issue tracking applications like Jira, GitHub Issues, and Gitlab Issue Tracker, to name a few. These applications provide ways for work items to be prioritized, assigned, and can provide stats on how long certain features and bugs take to complete. Understanding the workload and being able to prioritize will permit your team to focus on the immediate goals and work towards them more efficiently. It will certainly beat a To-Do list in a shared doc or chat!
Start your planning meetings with the user experience. Consider who is the intended audience, how the product or feature impacts them, and how they will use it. As developers, we tend to try to solutionize everything immediately. During your team’s planning meetings, take time to think of the big picture and customer experience first before drilling into the minutiae of features and tasks. Nothing good will come from rushing the process, especially if it ends up forcing your team to pivot after months of development.
Quality Coding
Review the code. When your teammates post a pull request, actually take the time to review the contents of the review. Is it tied to a user story or a ticket? Reference that ticket or issue number in the review. Do this to add more context to what is being submitted. Make sure you hold each other accountable for coding standards set by the team and politely advise fixes for potential bugs, naming corrections, and coding best practices. None of us like rework, but no one likes reworking someone else’s ticket, especially if the issues could have been corrected in a code review.
Everyone on the team should test. Do not wait to test until the branch has been merged into your main/master branch. Testing code only after the feature is integrated into the master branch is, quite frankly, irresponsible. The time to test is at the beginning and iteratively throughout your implementation. Once your code compiles, run the unit tests and fix what’s broken. Test-driven development dictates you write your unit tests first and incrementally write your code to fix the failing tests. If your team follows this, then you will always be gradually testing. Good for you. For those dealing with tickets that impact users directly, you should include incremental testing (both manual and automatic) and UX reviews for user-facing features. Do not leave all the testing to your QA members. Your QA should be your last line of defense before your users get a hold of a new product or feature. Bugs can become expensive, let’s keep them out of production.
Leveraging Pipelines
Some companies may allow features and updates to be committed directly to the master branch and make release branches for production, others may rely on master/main as the source of truth for production and enforce the use of having feature branches and then merging these branches into master/main. Whatever the case, find what works for your team. Perhaps moving bug fixes and features on branches may help, perhaps it won’t. For my past teams, using feature branches did make it easier to spike new concepts without making a mess of the master/main branch. I’ve been in companies that use the master branch or “trunk” as the source of truth and it works well until it doesn’t. It really depends on your release cadence and team size.
There are plenty of continuous integration and deployment (CI/CD) frameworks and tools that teams can leverage. For open-source teams, TravisCI, GitLab CI/CD, and CircleCI are free! Think of all the time your team will save by not having to merge branches and run unit and integration tests manually! The deployment can also be automated if the team sets it up which will come in handy when streamlining the development and testing cycles. More often than not, teams will release every couple of months for larger systems but the rate at which your team releases features and bug fixes is, well, up to your team. Having this defined early on will save time and confusion down the road.
Build Solid Teams
Some teams hold code review meetings, some hold design meetings, and maybe your team does both! All teams, however, should hold team review meetings. In Scrum teams, we call these retrospectives. Why is this important? It is the one safe place and time where team members can openly talk about what went well, what didn’t, and what needs to improve for the team to move forward. Successful teams always seek for ways to improve and work together to address problem areas.
My teams in the past have used different tools to track our progress; the top two that come to mind are GoReflect and FunRetro. These two products provide a hosted way to keep track of what went well, what didn’t go so well, and what action items the team has agreed to take to improve.
Bear in mind that not all processes will work out. Every team is different after all. That’s what these review meetings are for, to address the processes that did and did not work. Expect to fail several times but always keep pushing your team forward. The recipe for success is not always clear, but it is out there nonetheless. Try and fail until you finally succeed.
Final Words
Every team is different. Your team needs to find what works for them. If it hasn’t found its rhythm yet, that is ok. It is not too late to start that conversation and get a plan rolling. It’ll take time to change habits and adopt what everyone feels would work best, but it will all be worth it when you see your team performing like the all-star crew that it is!
