The previous sections all highlighted crucial workflow elements. You may not be able to hold to every crucial standard for every project, but you’ll know that if you’re making an exception (e.g. using a client’s version control system instead of your standard), you’re adding risk to the project, which means you should also add time and budget.
The following list is a grab-bag of important attributes it might make sense for your team to have standards for:
Accessibility is not only the right thing to do, it’s also the law in the United States and much of the rest of the world. If the work you produce isn’t accessible, you are exposing yourself and your clients to embarrassment, legal action, and more. Fortunately, there are a ton of great tools and resources out there to help you ensure that the work you produce is accessible, including WAVE, the A11Y Project and many others.
It’s 2016; all websites should use HTTPS at all times. We recommend going all encrypted, all the time: don’t mix modes. LetsEncrypt is a good free solution for certificates, and Content Delivery Networks like CloudFlare make enabling HTTPS easy.
Having a standard set of specialties can help boost overall team efficiency. Choose a CMS or two and get good at them. You don't want to bounce to a new technology on every project—you'll have a hard time being efficient—but depending on the project, you could be more lenient and seize opportunities to work outside your comfort zone. Plus, if your team has multiple CMS specialties, you can cross-pollinate for a more well-rounded skillset across the team.
How you push from testing to live is standardized automatically on Pantheon, but you may have different procedures depending on the client and environment.
Sometimes clients will have a set of requirements that effectively require you to build special processes and/or tooling for their project. This might be as simple as having to write deployment scripts to push code to their Dev/Test/Live environments. Alternatively, it might involve building and managing whole new servers in order to comply with their requirements. This work has the potential to turn into a time sink and profitability killer. Figure out what you’re willing to do as a part of your normal scope of work and make sure you have clear boundaries that allow you to bill for anything additional.
It’s good to standardize local development to cut down on debugging time and minimize the potential for lost work. But it’s also important that your devs can work in a manner most comfortable to them, within limits.
Command Line Interface
Unite your workflow and save valuable dev hours by automating what you can. Here are a few of our favorite tools for automation:
Ansible: Infrastructure automation tool.
Behat: Behavior-driven development framework.
Wraith: Helps make sure that there are no unexpected changes to the visual layout of a site while you work on it.
Composer: A PHP dependency manager.
Plugins & Modules
Having a standard recommendation for each use case will make you more of an expert and will also makes any ongoing maintenance easier. But it’s also good to stay flexible if the client wants to use another.
3 Standardization Time-Sucks to Avoid
These three things can be standardized, but the time spent standardizing and enforcing the standard can be much better spent elsewhere:
Text Editor/IDE: What editor your devs use doesn’t change the end outcome, and most devs are religiously devoted to their preference. Let them use what they prefer, but maintain standards for certain aspects, such as having a code sniffer running that makes sure files conform to your standards, tabs instead of spaces, etc.
Working Hours: Everyone has different hours when they’re most effective. Standardize regular checkins and standup meetings, but let output be the goal, not clocked-in time.
Client Requests: Sometimes you have to compromise for clients. Stand fast on your core principles, but don’t let a standard procedure get in the way of a satisfied client.