The Definitive Guide
to Agency Optimization
Increase Efficiency, Streamline Workflows,
and Take On Bigger Projects
The Definitive Guide to Agency Optimization
You landed a project. Great! What now?
You wowed the client with an amazing proposal. They signed on the dotted line. You dazzled
them during your kickoff meeting. High-fives and handshakes all around.
You’re about to embark on a brand new project, a blank slate your talented team can transform
into a beautiful web presence. It’s time to get to work.
What’s the first thing you do?
Worst Case: Build the Plane on the Way Down
Your team is stoked to start a new project. They all have mad skills, great attitudes and great
intentions. That ought to be enough to see you through, right? Plans, workflows, and project
management would only stifle the team’s creativity.
So you encourage everyone to grab their pieces of the airplane and head for the tallest cliff.
The looming deadline will just help everyone pull together and get the job done, right?
Right?
Best Case: Telepathic Coordination Activated
Your team is more than just a well-oiled machine. You’re more like the synchronized swimming
champs of the tech world. Everyone on the project knows the process for getting started on a
new assignment, as well as how project management and communication will work throughout.
Your whole team will move with robotic precision, writing clean and brutally efficient code,
never stepping on each other’s commits. Everyone’s efforts are so well coordinated it’s like they
share a brain. Your team will deliver on time and under budget, yet again.
Right?
Let’s Get Real: A Little Order, a Little Chaos
Your agency is most likely somewhere between the best and worst case scenarios. Most
agencies have some standards in place. But many haven’t taken time to determine which
standards must move consistently from project to project—and which shouldn’t—to maximize
efficiency and minimize overhead.
A well-developed, consistent approach is the key to efficiency. It’s the best way to deliver for
your clients while also equipping your team to take on more and/or more complex projects.
2
The Definitive Guide to Agency Optimization
What’s more, a solid standards-based process is something you can market and sell as you
grow your agency’s business—it can help you land more serious gigs, as well as increase the
strategic value of the service you provide to clients.
Your team may not be frantically assembling an airplane in free-fall. But unless you have
a neural-linked hivemind situation going on, odds are you could stand to improve your
processes. This guide will help you increase efficiency and set standard workflows that will
serve your agency for years to come.
Ready to turn your agency into a machine of web dev awesome? Read on.
Workflow Checklist
1. Project Management
2. Communication
3. Project Setup & Sysadmin
4. Version Control
5. Workflow
6. Code & QA Review
7. Feature Branching
8. Working Online
9. Continuous Integration, Delivery, & Deployment
10.Performance & Scalability
11. Additional Considerations
3
The Definitive Guide to Agency Optimization
Don’t Go Chasing
Waterfalls: Project
Management Standards
There are many different approaches to project management, and it can be hard to know
which is right for your team. Whichever approach you choose to take, it’s important that
everyone understands and is committed to the methodology.
Waterfall: Works Great until Something Changes
For years, the state of the art in project management was the Waterfall. In a Waterfall project,
the scope of the entire project is laid out in advance. Charts show what pieces are contingent
on other pieces, to show the order in which tasks must be completed. The focus is on a
predictable process with little to no room for change in goals or timeline.
If you have perfect planning and set-in-stone scope, Waterfall might work for you. More often
than not, though, Waterfall projects tend to deliver what the customer thought they wanted six
months ago. Which very, very rarely is what they actually need.
Agile: Zen and the Art of Web Development
In contrast to Waterfall’s strict pre-planning, Agile methodologies take a more Zen view of
things. It recognizes that projects change, and that change can be positive. These changes
can be driven by evolving market dynamics, new client requests, and the agency technical
discoveries. Most importantly it recognizes that the implementation process is a learning
process—build, measure, learn.
Instead of seeking to eliminate change, Agile emphasizes being able to react quickly to
changes in parameters or scope. Teams work in periods of concentrated effort (usually called
“sprints”) to deliver a minimum viable product.
At the end of each sprint, the team should have a complete product to show the client. Then
the client can make suggestions to iterate on the product for the next sprint.
4
Project Management Standards
For example, at the end of your first sprint you might deliver a bare-bones version of the client
site. It’s fully functional, but missing features. Then you can work together with the client to plan
what will be implemented in the next sprint. This creates a climate of constant feedback and
adaptation.
Ken Rickard, Director of Professional Services, Palantir
Our most successful projects are the ones where our clients are involved throughout the design
and development process, working alongside our team as true collaborative partners. That’s why
we use Agile project methodologies whenever possible. The Agile process focuses on delivering
maximum value over the course of a project’s lifecycle, and prioritizes engagement, collaboration,
and transparency in service to that goal.
Often, agencies will feel frustrated that the client is changing their mind all the time. And
it’s true, sometimes clients can be fickle (the customer is always right) but what’s more often
the case is that the client, or you, the agency, learned something important in the process of
implementation. Rather than having this blow up your waterfall timeline, why not embrace this
reality and make the most of these learning opportunities?
Angela Smith, Support Project Manager, Message Agency
At Message Agency, we provide support for the sites that we build for a period of time post-launch.
We also have a dedicated support team for clients that wish to purchase continued support for their
sites, whether built by us or not. Process is key—it’s what enables us to consistently create solutions
that address a client’s organizational and user needs.
We’ve found the Agile approach to development to be particularly effective during our support
cycle. Agile workflows are also well-suited for clients with whom we have firmly established
relationships. The short turnaround times and clearly defined goals afforded by the Agile approach
help us respond to client needs quickly and deliver new features that satisfy their needs in a timely
manner. Agile workflows also keep our solutions lean and targeted, avoiding feature-bloated
solutions that the client doesn’t need or want.
5
5
Project Management Standards
The Yin and Yang of Agile
There are two dominant schools of thought for Agile. They’re similar, but with some key
differences.
• Scrum is a more controlled working environment. Each team member has a role (product owner,
scrum master, etc.) and works in short sprints, usually two weeks. Work is prioritized and determined
by what will fit within the sprint. This approach is best for scheduled delivery of promised work.
• Kanban is less structured, giving the team more ability to focus on single tasks. A product owner
maintains and prioritizes a backlog, undisruptive to what the team is currently working on (WIP).
When an item is completed, the team moves on to the next project in the backlog. This approach is
best for non time-sensitive iterative improvements.
SCRUM
Cadence
Release methodology
Roles
Key metrics
Regular fixed length sprints
(ie, 2 weeks)
KANBAN
Continuous flow
At the end of each sprint if approved
Continuous delivery or at the team's
by the product owner
discretion
Product owner, scrum
No existing roles. Some teams enlist
master, development team
the help of an agile coach.
Velocity
Cycle time
Teams should strive to not
Change philosophy
make changes to the sprint
forecast during the sprint.
Change can happen at any time
Doing so compromises
learnings around estimation.
Source: Atlassian
6
Project Management Standards
Tools
There are many tools to help your team follow a standard project management methodology.
Drupal dev agency Four Kitchens uses the following:
Harvest for time tracking
HUBPlanner for people time planning
(resource planning)
JIRA for task definition and tracking
Google Docs for spreadsheets,
documents, sharing of documents.
Periscope for amalgamation of Harvest,
HubPlanner and Budget data in a
database.
Carly Strelzik, Director of Project Management, Modern Tribe
Our approach to project management allows us to progress through our projects in a disciplined
way, keeping our internal teams efficient, and our clients confident that we can successfully deliver
their projects. The goal is ‘No Surprises’ and we have shaped our workflows around accountability
and transparency. We have three teams and need to create consistency of workflow so that people
and projects can move gracefully throughout the company.
Our methodology is an ever evolving process. We started with no methodology, applied classic
waterfall after the owners took PMI courses, and gradually evolved to a flexible, “wagile”
methodology. Our process was defined as we tried various strategies, noted what worked and what
didn’t, and tried to improve our efficiency and work product. Today, we tend toward a mostly Agile
process when we can, but modify our process to best work with our client’s needs and their internal
teams. And we’re still learning and evolving our processes.
Start with a process with which you feel comfortable, and figure out how to measure its success.
Measure overhead/non-billable hours, time in meetings, time it takes to complete tasks. Ask the
non-PM teams, like your designers and developers, and even your clients, how you can help them be
more efficient and happier. Then continue to work, track success metrics, get feedback, and modify
so it works for you and your clients. Your outcomes are predicated by your daily habits.
7
The Definitive Guide to Agency Optimization
Call Me, Maybe?:
Communication Standards
As with any relationship, communication plays a huge role in project management. Projects can
succeed or fail based on how well your team communicates internally and externally.
It’s not unusual for agencies to have different levels of communication with different clients.
Some clients may be hard to get ahold of. Some might be actively hostile to regular check-ins.
But more often than not, these clients will end up unhappy with the end product.
It’s important to be clear, organized, and upfront with all parties as to how communication will
work. Make sure you have standards for communication that apply across your entire client roster.
Here are the different aspects of communication for which your agency should
have standards in place:
• Client Kickoff: This is the time to set expectations. Here you will cover design, information
architecture, UI, and content production, but be sure to go beyond just working out a list of
must-have and nice-to-have features. Talk about security, reliability, performance, hosting, and
infrastructure. Make sure the client knows what they can expect from you, but also what you expect
from them.
Kurt Voelker, VP of Solutions, Forum One
The kickoff is obviously critical because it sets the tone for the project, and the team’s relationship
with the client. Because of this, we make sure that we’re getting the client excited about ideas and
possibilities for what we’re going to build together really early in the project. This can be tough
because there are also a lot of boring logistics and project operations that need to get taken care
of while the project is kicking off as well—things like timelines, communication channels, reporting
procedures, risk mitigation plans, etc. So, we’ll have a small ‘project logistics’ kickoff with the
client Project Manager and Sponsor, but our first real ‘kickoff’ is with a broader group of client
stakeholders where we really dig into goals, vision, and possibility.
8
Communication Standards
• Internal Status Meetings: A quick check-in meeting for updates and next steps works wonders to
keep a complex project moving. Take a few minutes everyday to connect, avoiding the temptation
to turn it into an hour-long chat. Short internal check-ins save a lot of time and stress throughout the
project.
Chris Devidal, Project Manager, Four Kitchens
Don’t be afraid of mistakes. We have a culture where blaming is not allowed, so when something
happens we try to learn from it rather than point the finger. Retrospectives are a core element
of learning how to do better next time. Caring communication about mess ups always leads to
productive outcomes.
• Client Status Meetings: Brief touch-base meetings with the client can keep them posted on your
progress and remind them of upcoming deadlines. A regularly updated dashboard or report can help
the client feel better about progress, but is no substitute for actual, real-time communication. Consider
bringing clients into daily standups as your projects get close to critical milestones.
Suzy Bates, Director of Project Management, Four Kitchens
Always engage in open, honest, and regular communication. Talking with the clients every day
helps them hear all the bumps in the road and they end up feeling more like team members than
customers.
Find new ways to communicate with clients. A “Meeting” isn’t the only way to get information from
them. Slack, chat, video calls, email, even good ol’ fashioned phone calls.
9
Communication Standards
• Emergency Meetings: Reach out to the client proactively when something goes wrong or is about
to go wrong. Talk it out before they miss a deadline, if you have a major question, or if a request is
out of scope.
Chris Devidal, Project Manager, Four Kitchens
Don’t sit on bad news. Seriously, tell them early, tell them now. Clients are mad if they find out they
could have known earlier.
• PM Software: Services like Asana, Basecamp, and Wrike all make it easier to see what’s due next
and who owns what, as well as serving as a repository for resources and assets. Ideally, your agency
should have one preferred method of project management that clients must agree to use.
10
The Definitive Guide to Agency Optimization
To Cloud or Not to Cloud?
Project Setup and System
Administration
So you’ve got your project management methodology and you’ve had a kickoff, now it’s
time for the team to get to work. What does a developer do on their first day of a new client
project?
Decisions made here will affect how your team collaborates, how you get feedback from
your client, do QA, and eventually launch the site. You’ll need to determine the development
infrastructure for the project, which can be simple or complex. You can have a generic LAMP
server for every project or project-specific environments that perfectly mirror the production
site. Similarly, your controls over who is able access those environments can be rough or
fine-grained. And, with any of these combinations, you’ll need to decide on who is ultimately
responsible for making sure that things work now and in the future. Finally, you’ll need to have
a way to securely manage sensitive information related to your work, such as access credentials
and API keys.
Environment Management
There are a few common patterns we see in terms of how agencies handle managing their
environments:
• Laissez Faire: You’ve already agreed what CMS to use, the stack of contributed code, and what
frontend framework to use for the theme; what else is there to do? Everybody already has their
own favorite tools, and at this point the client has no idea where the site is launching, so let’s just
everybody get to work already. This is the default for most newer agencies, which often form as a
small group of people who’ve all developed their own best practices from their career to date. Some
will be running Linux on their desktop (or maybe MAMP), others will have a cloud server or two they
use for development purposes. It’s great to have everyone bring their own expertise to the table,
and this approach avoids early overhead, but it often creates downstream chaos if multiple team
members need to collaborate. This approach is only good if projects can be handled by a single
team member, and client input along the way is minimal. Otherwise this can quickly turn into a Wild
West stampede to Cowboy Coding, and just isn’t sustainable.
11
Project Setup & Sysadmin
• Shared Development Server(s): Agencies will often create a shared/canonical development
environment for a project. This has the benefit of living online, which is key for collaboration and
coordination, and for sharing work in progress with a client. With an online shared development
environment comes responsibility for upkeep and maintenance. Someone’s going to have to start
playing sysadmin, which has a cost in terms of time for project setup and can pull senior technical
resources off client projects. Additionally, developers might find themselves getting “blocked” by
missing features or the stability of the shared development infrastructure—which often suffers from
“the cobbler’s children have no shoes” problem—or running into hangups or bugs if they are running
their own local development and trying to synchronize with the shared online resources.
• Local and Cloud Virtual Servers: It’s possible to use consistent virtual machine images for both
local development, and in the cloud using tools like Docker, VirtualBox and VMWare. Agencies will
often use another layer of tooling, like Vagrant, along with a modern configuration management
system like Chef, Ansible, or Puppet. The goal here is to get each developer their own environment
and avoid the “works on my machine” problems common in the Laissez Faire approach. That goal
is much easier to meet when a dedicated and experienced sysadmin (or team of them) can maintain
the virtual machines and scripts for everyone. Local and Cloud virtualization can fail when developers
expert in web languages find themselves in over their heads on server config and have to debug a
machine inside a machine. Or even a container suite inside a VM inside their native machine in the
case of some setups.
• Platform as a Service (PaaS): A Platform as a Service solution provides the same benefits of VMbased development but without the internal cost of maintenance and management. PaaS solutions
also provide greater clarity and peace-of-mind around responsibilities. Well-established vendors
in this category will have a single instance, multi-tenant platform controlled by software instead of
individual sysadmins configuring different environments for each customer. As an added bonus,
you can usually launch the production site on your PaaS as well, which means there’s no need to
stress about transitioning to client infrastructure, or worry about the higher-risk sysadmin burden of
maintaining and defending servers that run live websites.
Andrew Mallis, Co-Founder, Kalamuna
Standardized development workflows across our client projects allows us to provide more value
to more clients—by significant orders of magnitude. Hours otherwise wasted solving the same
infrastructure problems in unique ways can be better spent on quality code and design to support
the important missions our client partners are undertaking.
12
Project Setup & Sysadmin
Access Control
Once you have chosen your infrastructure you’ll need to control access to the code, files
and data for each of those projects. These systems can range from simple scripts to deep
integrations with a GUI management layer. In addition to securing the necessary resources it’s
wise to also consider how much time and effort it takes to grant access.
Chris Teitzel, Founder & CEO, Cellar Door Media & Lockr
Every project is a microcosm within our company, and just like any community there are a wide
variety of individuals inside, each with their distinct roles and functions. Clients have key personnel
which need to be involved in the site management and content, developers need to be able to
have the freedom to work in isolation without the fear of disrupting a production site, and project
leads sit as gatekeepers when features and updates are ready to roll out. And like any community,
things can get complicated in a hurry and even the smallest of details can get out of hand in no time
without the right controls and processes in place. What keeps us all working together and driving
the project to our goals are clear roles, responsibilities and, most importantly, access controls that
prevent someone from causing issues, intentionally or not.
13
Project Setup & Sysadmin
Technologies to consider include:
• Single Sign On (SSO): When people have to manage dozens of usernames and passwords, the
passwords tend to get simpler and more repetitive. SSO replaces the mess with a single set of
credentials for multiple systems. Solutions like SAML, OAuth, Kerberos and OneLogin are a good
place to start for SSO.
• Two Factor Authentication (TFA): TFA adds an extra layer of security beyond passwords. It adds
knowledge (something they know); possession (something they have), and/or inherence (something
they are). For example, TFA allows you to use services such as Google Authenticator or OneLogin,
where the possession of a mobile device registered to you is required to login.
Security Policies
You and your clients both expect to have secure websites. There are many layers to security.
• Start by choosing a rock-solid host to deploy your projects.
• Have procedures to rapidly deploy CMS security updates.
• Use security-enhancing Drupal modules and WordPress plugins as part of your regular build.
• Use HTTPS and SFTP for all your projects.
• Learn the OWASP 10 and how to write secure code for WordPress and Drupal.
Every project will deal with at least some sensitive information. You’ll need a policy to store
and manage sensitive information such as access credentials and API keys. For password
management, KeePass, LastPass, and 1Password are all great options. For API keys, a key
management service like Lockr is a good idea.
14
The Definitive Guide to Agency Optimization
Git a Grip: Version Control
Version control is absolutely required for collaboration, troubleshooting, and following an
iterative development process. Think of it as the code version of “Track Changes” in a word
processor: It establishes a history of the development work on the project.
With proper version control, any developer can go back and see what changed from iteration
to iteration. Most importantly, multiple developers can work independently and merge their
changes together without creating a nightmare of tangled code.
Without version control there’s no good way to collaborate across multiple instances of an
application. You’d be limited to one developer working at a time, while the rest line up and
wait for their turn. It’s either stunningly inefficient or a logistical nightmare.
Cristina D’Anni, Director, Development & Design, Targeted Victory
The importance of version control comes down to three words: collaboration, accountability, and
security.
Without using version control, the risk of inadvertently destroying another developer’s hard work
is real and rolling back changes can be extremely cumbersome and difficult. And that’s assuming
you can figure out exactly what caused an issue without commit messages to refer to. With version
control in place, our team can focus on different parts of client sites without the risk of damaging
another’s work.
For Targeted Victory, having the security and accountability in place is extremely important. We
manage well over 100 active websites with multiple developers working on multiple projects
at any one given time. Version control allows us to maintain standards without stepping on one
another’s toes.
15
Version Control
Version Control Software
It’s clear your team needs version control to realize its full potential. There are a few options
out there for version control tools, but the one you’re most likely to use is Git.
Git is open-source, fast, stable, and has a huge ecosystem of tools and utilities. It is also a
distributed system (vs older “centralized” models), which makes it more collaboration-friendly.
There are several popular hosts of Git repositories to choose from with customized features,
including Bitbucket, GitHub, and GitLab.
Some agencies might use Subversion (SVN), which is used for WordPress core development.
SVN is a centralized system so the version control server is the canonical source of code. It uses
an older “centralized” model sometimes preferred by enterprise, government, etc. entities
seeking more control over the code. You may encounter it working with clients, but it’s not
likely to be a go-to choice for a new implementation.
There’s always the chance your client might have their own proprietary system. In that case, it’s
best to move the code out to your system for development, then put it back after QA.
A team needs to get really good at working together, and switching up version control systems
and patterns between projects will make that a constant hassle. In general, unless you have
a legacy investment in another platform, some implementation of Git will suit your needs.
It’s faster, technically superior in terms of merging and other features, and has a much larger
ecosystem of tools, utilities, examples, and experts.
Ken Rickard, Director of Professional Services, Palantir
Version control helps team collaborate. It captures the history of everyone’s work and let’s the
team review changes together. If you aren’t using version control, you risk missing mistakes before
they hit the live site. Conversely, version control makes it easy to rollback to trusted code when
errors do occur. We use a pull-request workflow—no new code gets deployed to a client site until
it has been reviewed by at least one other person.
If the client is dictating the version control system and it’s not your agency’s standard,
it’s important to build that into the project as a risk factor. Either you’re managing some
translation, or you’re having your development team work with unfamiliar tools. Both are a
pain, and you need to increase the timeline and the budget accordingly.
16
The Definitive Guide to Agency Optimization
>_
Work the Workflow:
Dev/Test/Live
Version control is the start of a good development workflow. The next step is to create a
development ecosystem that includes three separate environments:
• Dev, for developing code.
• Test, to test, review and QA a running website before taking new code live.
Sometimes this is also called Staging.
• Live, where only tested and functional code is allowed.
Sometimes called Prod or Production.
First standardize on this concept, then make it happen. You need all three, don’t make
exceptions. This standard is older than the web: it is the standard model of “Application
Lifecycle Management.”
Doing development in the live environment is like riding a bike with no helmet. You can look
cool for a while, but when you hit a tree, it’s all over. The same goes for pushing code from Dev
straight to Live. The best case scenario is you have inefficient review processes, and the worst
case is the site falls down live for your client and their customers.
Note: If you find yourself in a situation that requires an urgent update to the live site, follow a best practice hotfix
workflow to mitigate risk. To save yourself headache, you and your team should determine what warrants a hotfix
prior to facing an emergency situation or urgent ticket.
17
>_
Workflow
Katy Pool, Developer, Kalamuna
The Dev/Test/Live workflow is essential to our development team. We use the Dev environment
to merge in features and code changes from various team members, and then once those changes
are ready to be QA’d by our clients, we’re able to demonstrate new functionality with an exact
copy of their live site content with just a push of a button. We also make use of Pantheon’s added
Multidev functionality, which makes developing multiple features concurrently extremely easy,
flexible, and timely.
At the very least, I will usually explain the Test environment to the client so they can test new
features without fear of altering their Live environment. Usually their main question is ‘Can we
continue to use our site and update it with new content while we are testing a feature?’ And
thanks to Pantheon’s Dev/Test/Live workflow, the answer to that is almost always yes. Depending
on the project and the familiarity of our clients already have with the development process, I will
sometimes explain a little more about how we utilize Multidev environments and push up code.
Beyond the three environments, you need a controlled way for changes to move around. You
need a workflow. And because websites are full of content, content has to be part of the
equation.
The best workflow for website development is one where code is pushed “up” from Dev to
Test to Live, while content is cloned “down,” always treating the live website as the canonical
content source.
DEV
CODE
>_
TEST
LIVE
CONTENT
Ideally you also have a way to make sure these environments are consistent in terms of their
configuration and performance. Otherwise you may have some unpleasant surprises when you
deploy. Features or designs that “worked on my machine” could break, or worse, you could
see a performance bottleneck or unexpected regression when the code goes live.
18
>_
Workflow
With environment configuration in place, you can continue to build out a best practice
workflow by managing configuration in code. This is most beneficial when moving from one
environment to another (Dev>Test>Live), and provides visibility into what configuration has
changed, who changed it, and when it was changed. Keeping these changes in version control
allows you to quickly revert configuration changes if necessary. Wouldn’t it be nice to deploy a
new feature and not have to click through its configuration in the site admin?
Learn more about managing configuration in code:
• What is site config & why manage it in code?
• Managing configuration in code: WordPress
• Managing configuration in code: Drupal 8
It’s important to be an advocate for Dev/Test/Live with your clients. Try to standardize as
much as possible, even if the client won’t allow for all three environments to be on the same
platform.
Aaron Bauman, Senior Software Engineer, Message Agency
As anyone in web design will tell you, there are a number of moving pieces in every project.
The consistency of a three-environment setup is a crucial facet of our development process.
A combination of Pantheon’s Multidev and isolated Dev/Test/Live environments gives us the
flexibility necessary to coordinate feature releases, client acceptance testing, and content staging.
As a result we manage all of our project workflows through Pantheon, even if the site may
ultimately be launched on another platform.
We don’t believe in holding clients hostage when it comes to hosting. Many firms prefer to
resell hosting because of the efficiency and consistency it gives them in the support cycle. We
advocate that clients own their hosting accounts, whether on Pantheon or with another vendor,
and recommend they use Pantheon. Developing on Pantheon provides the consistency we need
to streamline our processes, giving us the ability to deploy the solution on the platform of the
customer’s choice with ease.
19
The Definitive Guide to Agency Optimization
Two Thumbs Up: Code &
QA Review Processes
Review processes are a vital part of a streamlined workflow. They keep the project moving and
improving. They make sure you deliver what you promised to deliver. And, thankfully, they
allow you to reach the end of the project that satisfies everyone involved (Whew!).
Reviews should happen proactively—throughout the project’s lifecycle—and should include
a synchronized process for shipping code, a streamlined method for testing the code, and
client participation to nip any issues in the bud sooner rather than later. It’s also important to
note that you can’t do reliable review and QA unless you have a reliable workflow. The most
important foundation of QA is that you have a “known state”, which means that everyone is
clear about what exactly it is that you are reviewing. Otherwise, you are investing time and
resources to giving feedback to a snowflake right before it melts and disappears forever.
There are four stages to a solid review process:
1. Automated Testing: Generally, code review happens only after automated testing. It’s not efficient
for a human to review code that is not yet up to the robots’ standards. QA can be automated with
tools and services like automated testing, visual regression, code level tests, automated browser
testing, etc. But don’t miss out on simple, quick wins like automated syntax checking and code
linting. These take only minutes to configure in most modern code editors, and can cumulatively
save many developer hours over a month. Make the robots do the work!
2. Code Review: Standardizing on a set process for internal code review is the best way to maintain
your agency’s code standards and prevent problematic or difficult to maintain code from being
deployed. Setting a standard process that is replicated from project to project allows your team to
work together more efficiently and cross-pollinate, avoiding roadblocks along the way. If another
developer has to work on the project in the future, they’ll know what’s going on. Don’t reinvent the
wheel, ensure quality code.
It is common practice for teams to use pull requests into a repository as an opportunity for peer
and/or robot review. Many teams establish norms whereby no pull request can be merged without
first getting a plus one (perhaps in the form of an emoji) from one of their team members. Teams
also enforce these norms in different ways. You might choose to block members from pushing
20
Code & QA Review
directly into master or limit who can merge to master. The important thing is that someone other
than the person who wrote the code has an opportunity to ask questions, share their insights or
learn something themselves. Taking it to the next level, you might choose to get robots involved.
Leveraging a CI tool (such as CircleCI, Travis, or Jenkins), code complexity, syntax reviews, and basic
linting can give feedback that is onerous for a human looking at the code to provide.
Matt Johnson, CTO, Alley Interactive
Our peer code review follows a sort of honor code. If you don’t know x language very well,
you don’t review that code. This ensures that our process is efficient, since the team member
reviewing your code is well versed in how it should look and act. It also fits our company culture—
we don’t have a hierarchy. Partners get code reviewed just the same as any other team member.
The code review is not an adversarial thing, but rather a learning experience for both the reviewer
and the reviewee.
Learn more about Alley’s peer code review.
3. Internal QA: After the code review, bring your team members together to make sure everything
works. The purpose of QA is to ensure that you have delivered code that meets the requirements.
It’s pedantic but helpful to avoid the word “test” in this context. Use “checking” instead. To this end,
you need to check that your code meets the parameters of the project. That might mean you use a
tool to check for accessibility, for site speed, for behavior, and/or for its visibility on specific browsers
or devices. This is not the same as testing. It’s making sure you are delivering what you said you
would deliver.
4. Client Review: Make sure you do code review and internal QA first, and after YOU think you’re
done, share with client and ask for feedback. Give a deadline and set expectations. It is important
that the client understands and accepts their responsibility to test the code. You, as a developer, will
deliver a feature that meets the client’s requirements. It is the client’s responsibility to ensure that
they have specified the requirements fully.
Sometimes developers misinterpret requirements, but it often happens that seeing something
“alive” is a learning experience for the client, which may lead to a revision of the requirements.
This is why having an Agile process is a huge help. Rather than a red-marker style activity of clicking
through a site and comparing it to a set of static comps, this can be a great time for collaboration.
21
Code & QA Review
Depending on your process, you may have a few rounds of review, but be clear on what kind of
feedback you’re looking for. If you keep it open-ended, don’t be surprised if they ask for a full virtual
reality implementation, or to have all the images replaced with rotating cat .gifs.
Mike Bal, Associate Director of Client Delivery, 10up
It’s important to step back from projects as a whole and take a magnified view of different parts
along the way. Being able to see and evaluate how all of the individual pieces of a project work
together is a vital part of finishing the entire project successfully.
Code reviews provide an extra level of quality assurance from an engineering perspective, while
helping to keep the team on the same page. An additional benefit of these reviews is giving less
experienced engineers an opportunity to review more senior level code, coupled with direct
coaching and feedback on the approach.
Client review ensures that we haven’t misunderstood or overlooked anything during the
requirements gathering process. It also gives clients an opportunity to experience our
interpretation of their initial request and make sure both parties understand what is being built.
Testing gives us an additional interaction to fine-tune how best to meet the clients’ needs.
22
The Definitive Guide to Agency Optimization
You Do You:
Feature Branching
There’s huge risk of conflict when two developers are working on different features in the same
code. Imagine you are creating a new page template. Another developer is updating the
header site-wide.
If you both work and push code to the master branch, there is a potential for conflict. Even
worse, imagine the page template is approved but the header changes are not. Reverting to a
previous version can be a pain.
Feature branching allows developers to work on pieces of the project separately, so they
don’t step on each other’s toes.
Picture this: We have the master branch with the current code state and both you, creating a
new page template, and your co-worker, making updates to the site header, each do so on a
separate branch. Additionally, you do a code review for one another. That workflow would look
like this:
BRANCH
DISCUSS
MERGE
Develop features
on a branch and
create a pull
request to get
changes
Discuss and
approve code
changes related
to the pull
request.
Merge the branch
with the click of a
button.
Source: Atlassian
Approved branches get merged and deleted. If a branch isn’t approved it can be further
iterated on or discarded without affecting the master branch.
Branching works great internally, but what happens when a stakeholder needs to check out a
branch? You could bring them on-site to look at it, but they would likely prefer a URL to view
remotely.
The best way to handle this situation is to set up a dedicated environment, with its own
resources and URL, for each feature branch. This way anyone can view the code in the feature
branch or visit the site at the dedicated URL. If the branch environment matches the live
environment, there won’t be any surprises when you deploy.
23
Feature Branching
Tauno Hogue, CTO, ThinkShout
Regardless of if your development team consists of a single developer or more than a dozen,
working with feature branches will save your sanity. By containing work related to a single feature
in its own branch, you protect against several key problems: deploying incomplete work, not
deploying completed work because it’s mixed with incomplete work and conflicts between
developers. If you do all development on a single branch then all work on that branch must be
complete at the same time in order to deploy safely. How often do internal QA, client approvals,
and a lull in ongoing development coincide? Rarely. When using feature branches, you review
and test work on the feature branch before merging it back into the release branch. The release
branch is then always ready to deploy. A particularly important use case is security updates or
other critical hotfixes. If in-progress work is confined to feature branches, a critical fix can be
deployed on top of the stable release branch without having to deploy a feature the is incomplete.
Not deploying a security update because a developer hasn’t finished an unrelated feature on the
same branch is just as troubling as deploying an incomplete and untested feature because it’s on
the same branch as the security update.
For most of our projects we have two primary branches: master for production releases and
develop for our ongoing development work. When working on a feature we branch off of develop.
After completing and testing the feature we merge back into develop. To deploy a release we
merge develop into master and our Continuous Integration systems deploy the code to the dev
environment on Pantheon. If a hotfix/security update is needed we can branch off of master, make
the fix, and merge back into master (and later develop). By using a develop branch in addition
to master we have a stable release branch and an in-progress branch of all the combined feature
work. This branching methodology is a mix of Git Flow and GitHub flow. An added benefit of
using feature branches when working with Pantheon is that each branch can easily be demo’d and
QA’d on a Pantheon Multidev.
Pantheon’s Branching
It can take a team of dedicated DevOps specialists to do branching right. Pantheon makes this
really easy with our Multidev cloud environments. Environments can be created right from the
dashboard with Terminus (our command line tool), or from an existing Git branch.
Each Multidev environment runs on the same infrastructure as the live environment, has dedicated
resources, and it’s own URL. You can even pull the latest database from the live site, add HTTP Auth
to protect some super-secret new feature, and more.
24
The Definitive Guide to Agency Optimization
Sharing Is Caring:
Working Online
While it can be overkill to try and force every developer to use the same text editor, you
should have some general standards for development environments if only from an internal
supportability standpoint. The amount of time lost to broken development environments that
are special snowflakes only understood by one or two team members is painful. You also need
a standard way to put your work online, and collaborate between multiple parties.
Web development is a team sport. Being able to “show your work” to clients early and often
is crucial, as is being able to problem solve with colleagues without having to literally share a
computer.
There are a number of key areas of site development—performance tuning, cross browser
compatibility, integration with other cloud services—that simply can’t be done effectively
without an online development environment.
So while local development has its benefits—working offline, seeing changes immediately,
avoiding lag on data-intensive operations—you have to control the chaos and have a unified
way to get work off someone’s laptop and onto the web for real.
Stephanie Canon, Managing Partner, Chapter Three
It’s always best to show a web project’s progress to your clients on regular intervals. It’s also a best
practice to make sure this process is easy for both your development team and your clients. At
Chapter Three we use web-native tools to showcase our work with our clients. Our development
team can easily push up the latest code and pull down the latest content into a staging
environment that we share with our clients. This is a fast, nimble process that works well for our
team and helps reassure our clients that they are in lock-step with the progress of the project.
25
The Definitive Guide to Agency Optimization
Every Day I’m Shufflin’:
Continuous Integration,
Delivery, and Deployment
Continuous Integration, Continuous Delivery, and Continuous Deployment progressively build
on one another. Continuous integration (CI) is the process of automatically turning the commits
you make in your codebase into a useable build (website). Continuous Integration also requires
some level of testing to verify that the build process succeeded. With CI you define how your
code is transformed into a working site; often living in a sandbox environment.
Continuous Delivery introduces the concept of a “deployment pipeline.” Continuous delivery
forces you to define in detail how your deployment pipeline takes changes from that sandbox
and gets them the production environment. Sites on Pantheon use a deployment pipeline that
goes through our Dev, Test and Live environments. Doing Continuous Delivery requires adding
on to the automated tests created to fulfill Continuous Integration. When your changes move
through the deployment pipeline, your Continuous Delivery process should validate that the
site works in each environment.
Continuous Deployment is a business decision to send all changes straight through the
deployment pipeline once tests have passed on those changes. With a strong deployment
pipeline created in Continuous Delivery, Continuous Deployment is a simple business question.
Ask your stakeholders “Do you want each change sent through the deployment pipeline to
live as soon as the change is approved/merged? Or do you want changes held so that they are
deployed in bunches at the end of each sprint (or other schedule)?” For many web agencies
and their clients it is preferable to stick with scheduled releases.
26
Continuous Integration & Continuous Delivery
Dave Ross, Associate Director of Engineering, 10up
Continuous Integration puts our work in front of clients and teammates early on, so we can
address poor user experiences and malfunctioning code while an engineer is focused on the
project. CI also helps merge together independently written code as soon as possible. This way,
conflicts can be identified and remedied (or opportunities to share code can be exploited to the
benefit of the project). Our engineers can find issues on staging and fix them before they result in
QA showstoppers or costly production issues.
I used to work in environments with weekly deployments. A change finished on Wednesday went
out on the following Tuesday, alongside newer changes that just passed Monday night’s QA
process. If something is ready now, there’s no sense making 10up’s clients or their customers wait
for it. Additionally, in the rare event something goes wrong during deployment, we only need to
roll back a small changeset rather than a big bundle of features.
Abandoning the weekly “deploy day” doesn’t mean adopting undisciplined “cowboy coding.” CI
and CD depend on standards and rigor. Code reviews, automated testing, and formal QA help
ensure that the work we push live meets 10up’s standards for performance and security (while still
delivering the functionality our clients need).
Before you start chasing the holy grail of Continuous Deployment, ask your team what is
currently standing in the way of a solid CI process or deployment pipeline.
4 Questions for Getting Started with CI
1. What manual steps we are doing repeatedly in our workflow?
2. How do we know when our site is working or broken? How can we answer that question
with a script?
3. Is everyone on the team team compiling their changes (to Sass, CoffeeScript or
Composer) in exactly the same way?
4. What is the unit of work on which we want to perform builds: Pull requests, each
commit, or specially named branches?
27
Continuous Integration & Continuous Delivery
Teams often create long wish lists of all the steps they want to automate. It is important to
remember that all of the automation you do should add value for your client and your team.
With each task you want to automate, think about the value that automation will bring. Here
are some of advantages you can get from each step you script:
• Trust: You can trust your co-workers more when they say a new feature worked on their machine. The
development process is less opaque, so non-dev stakeholders have more confidence in the project.
• Speed: Setting up a CI process can be time-consuming at first. But over time it pays huge dividends,
as your team no longer spends time resolving merge conflicts.
• Lower mental overhead: With an automated CI process, developers don’t have to remember and
manually execute a complex series of steps, freeing up their mental RAM for more important tasks.
• Clarity: CI canonizes your preferred approach to adding and updating modules and plugins. With
the process codified into a script, it’s clear to everyone what the best practices are.
• Lower risk of regression: Teams doing continuous integration are less likely to discover the task
they thought was done is no longer done.
Tools
Here are some popular tools for CI/CD:
Jenkins
Travis CI
Circle CI
Bamboo (Atlassian)
28
Continuous Integration & Continuous Delivery
Weston Ruter, CTO, XWP
We have developed a workflow whereby when a pull request is merged into master on GitHub,
Travis CI runs automated code quality checks and tests using our wp-dev-lib, and if these pass
then Travis pushes the code to the repo mirror on Pantheon. This works great because we can be
assured that only code which meets our standards will ever get deployed to any environment.
Any agency that deals with new clients on a regular basis, and any agency that hopes to scale up,
should have in place workflows that take the guesswork out of getting new client projects set up
and ready for delivery.
5 Essential Tasks for Implementing Continuous Integration & Continuous
Deployment:
1. Automate the build: “Continousness” really happens when developers don’t need to do extra work.
CI/CD systems will kick off a build—including a testing pass—with every commit without needing any
intervention. This ensures that builds happen every time, and feedback comes quickly.
2. Fix broken builds immediately: Respect the sanctity of the build and fix issues right away. This is
vastly preferable to having the last mile of a sprint or project turn into a surprise death march. This
saves time and helps create a culture of quality.
3. Make it transparent: Build status should be readily available to the whole team, and easy to
investigate. The CI/CD system should be a shared set of facts, not a specialized area of secret
DevOps arcania. Taking the time to make your build process clearly visible and accessible is key to
making it a standard part of your practice.
4. Test in a clone of the production environment: Nobody likes surprises when going live. Testing
isn’t about preventing mistakes, it’s about creating confidence and velocity. Make sure your test
environment matches production as closely as possilbe, and that you are testing with a current
snapshot of production data.
5. Automate deployment: You don’t need to be robotically deploying after every build to see huge
benefits from a scripted deployment process. Even if you’re waiting for final human acceptance from
a stakeholder or QA team before a release, setting up that acceptance testing environment should
be automagic. Likewise the final “greenlight” should be a single click or command, nothing more.
This keeps you moving fast and prevents human error from taking you down at the last minute.
29
The Definitive Guide to Agency Optimization
You’re the Best Around:
Performance & Scalability
Standards
Goals for individual projects may vary, but your agency ought to have some standard practices
for measuring the performance of the websites you deliver, and making sure they can scale to
handle the traffic they’ll receive.
Mason James, CEO, Valet
There is perhaps no greater threat to the open web than the lack of clear performance standards
and accountability. Every agency bears the burden of developing best practices and holding
themselves responsible for building high-performing web experiences.
Today’s website owners expect a site to be performant, as they well should. This is not an
impossible task. Setting a client up for success involves recording baseline metrics and measuring
change as iterative development takes place. Create opportunities to review the bench why
they’re valuable. Create context for these metrics by looking at the history of the site as well as
any competitors.
At Valet, we create context and performance standards by answering the most basic client
question—am I better than I was yesterday? And am I better than my competition? Measuring
and reporting based on standard best practices, puts our best foot forward as developers and
technologists, and allows us to be partners in our clients’ success.
A provable commitment to performance and scalability will set your agency apart from the
crowd, leading to more clients and justifying higher rates. Establish benchmarks and hold
yourself to them in these areas:
30
Performance & Scalability
• Performance: Measure your page load speeds. There are a lot of great tools out there like
yslow, sitespeed.io, Google’s PageSpeed, Pingdom’s Speed Test and more. On the backend,
look for bottlenecks with New Relic, Blackfire or XHProf. Use a CDN to help with geographical
considerations.
Choose which ones your team will use and build them into your regular process; automate their
reports and include them as part of your code reviews, sprint milestones and other check-ins.
Exposing performance metrics will go a long way towards making your sites faster. Sell this additional
value to your clients by sharing how performance increases conversions, helps search engine
rankings, and more.
• Scale: As with performance testing, build scalability into your projects. Make sure your clients can
survive success with load-testing tools like Apache Bench, JMeter or Blazemeter.
Establish regular load testing and concurrency guidelines and automate tests as part of your regular
reviews and checkins. Your peace of mind will transfer directly to the client’s sense of well-being.
Elastic hosting is a key feature on Pantheon. It assures that sites have the resources they need, as
they are needed—no need to estimate capacity in advance or make frantic phone calls during a
traffic spike.
31
The Definitive Guide to Agency Optimization
You Make the Call:
Important Considerations
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: 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.
• HTTPS: 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.
• CMS Specialty: 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 C
MS specialties, you can cross-pollinate for a more well-rounded skillset across the team.
• Deployment workflow: How you push from testing to live is standardized automatically on
Pantheon, but you may have different procedures depending on the client and environment.
• Infrastructure work: 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
32
Important Considerations
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.
• Local development: 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: CLI is incredibly helpful. Not everyone may be comfortable using it. For
those who are, use WP-CLI, Drush, Drupal Console, and Terminus to speed up your work and allow
automation of repetitive tasks.
• Automation: 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.
• Grunt, Gulp, & Robo: JavaScript task managers.
• 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 four things can be standardized, but the time spent standardizing and enforcing the standard
can be much better spent elsewhere:
1. 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.
2. 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.
3. 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.
33
The Definitive Guide to Agency Optimization
Build better websites, faster
with a streamlined workflow
If your team has mastered the art of constant perfection, you don’t need to worry about
standards. The rest of us absolutely need to build our practice around consistent, highly
optimized processes. It starts with solid project management and a plan for constant
communication, and continues through every aspect of your development process.
Cristina D’Anni, Director, Design & Development, Targeted Victory
Having a defined set of standards is critical in agency work. It allows for new team members to more
quickly acclimate if all code follows the same set of standards. It makes maintaining multiple sites
considerably easier. If you don’t have to approach every site as if it is a unique snowflake on the
backend, updates and improvements are relatively pain free, allowing more time for developing new
features to bring online.
The right standardization, automation, and best practices can help your agency:
• Take on bigger projects
• Build better websites faster
• Deliver extra value to clients
At Pantheon, we want to help agencies maximize their potential. So we built optimization and
automation into our platform. Pantheon makes it easy to follow these best practices without
sacrificing the individuality that makes your agency awesome.
See how Pantheon can be a partner on your agency’s
quest for world domination. Check out Pantheon for
Agencies today.
34