Improving Web Dev Quality

Recently I was reflecting on the early days of agency life when I was a developer. I remember how messy things were because there weren’t any quality standards or tools in place to help enforce quality.

Every project felt sloppy, take the following common occurrences:

  • Projects would be handed to the client full of bugs
  • Managers talking to clients didn’t know how products worked in detail, so often diverted the communication to developers
  • When a site launched…well everyone just hoped for the best because often, something would go wrong
  • Communication to clients was poor; clients often had to follow up managers to check they ‘got their email’
  • Internal communication was lacking, with workers often twiddling their thumbs waiting on further information

When I stepped into Project Management, I was driven to overcome these issues. I’m pleased to say things run a whole lot smoother these day, so I thought I’d share the strategy implemented.

A Culture of Accountability

We intentionally developed a culture of accountability, whereby if you’re working on something, you don’t hand it over unless you’d metaphorically ‘sign your name’ on it.

This was fairly easily achieved:

  • Communicate this standard numerous times
  • Encourage people to call out the ‘blame games’

Set Project Workflow

We worked on developing a workflow template that we could roll into every new project. A common workflow means there’s no surprises, nothing forgotten and we can finish each project with products of consistent quality.

Part of this workflow also introduced 2 levels of reviews — one internal review where a QA Tester reviews and the second being the client review.

QA Tester

We made the project manager the product owner. This means that the project manager is responsible and accountable for the product they deliver to the client. When we schedule work, we book 2–3hrs upon development completion with the project manager to test thoroughly.

  • Does the product look perfect?
  • Does it meet specs?
  • Does it make sense?
  • Does every button click to the right place?
  • etc.

The QA Tester is bound to find bits and peices that aren’t quite right, so they will document all requests in a Google Doc Internal Review template. The developer/s complete the requests, and the QA Tester reviews again. This process sometimes iterates numerous times until the product is right.

Perhaps when we expand to the next level, we’ll invest in a full time QA Engineer, however at the moment this model is serving us well.

Procedures Knowledge Base

We developed procedures, one-by-one for each common task. We started an internal blog-like tool so that everyone could contribute to procedures and overall build up a knowledge base.

For example we often had issues with website deployment, where something was forgotten and whether immediate or not, something went wrong. We created a ‘Go-Live Procedure’ which everyone is expected to follow — it contains everything from create hosting account to setup Google Analytics. It ensures everyone, even new staff can follow step by step and achieve the same result.

QA Checklists

The simple checklist is a great tool to:

  • Help people remember what they need to do
  • Monitor whether someone did something

In our project management tool, we built checklist templates so that we could apply a predefined set of checklist items to a task. When developers are working on a task, they can check off when/if they complete something. If they’ve ticked it — we have to assume they’ve done it.

Team Briefings

We implemented project team kick off meetings where the strategist briefs all team members involved, on the likes of the following:

  • Client background
  • Project goals
  • Product specification
  • Budgets
  • Ideal end result

This gets everyone on the same page from the beginning.

Prioritization and Scheduling

As a developer, believe it or not we would have to guess what we should be working on. We’d get a verbal brief at the start of the week on jobs, but there was no prioritization or central view to see who was working on what when.

I developed a tool which is still used today, which is the mix between a todo list and a calendar. Everyone has a personal view which they can view by day, week or month, and project managers can view the schedules of all staff from a single view. When a developer finishes a task, they check it off and project managers can see this in real time from their computer. When a client calls and says ‘when can you do xyz’ — we can view the current workload and book a job on the spot.

Communication standards

We developed communication expectations organisation wide. These were simply:

  • Respond to clients same day — even if it’s with just ‘I’ll review and get back to you tomorrow’
  • When you’ve finished a task, always send confirmation to the person who assigned it
  • If you see something, say something — eg. the developer codes a Facebook icon and we don’t have the client’s link yet — tell the project manager that we need it
  • We’re young and friendly — express communication in a tone that matches this (no need for big words and formal expressions)

If someone dropped the ball, remember the first point — we held them accountable.

Move KPIs onto quality

We previously focused on ‘get the job done as quick as you can’. The quicker, the better you are. This obviously resulted in people being rewarded for delivering early, but the product was unfinished and contained bugs.

Instead we switched frames of mind to reward when they delivered awesome products and when the QA manager didn’t have a long list of changes.


Originally published at www.mcnam.ee