Words by David DarkeFebruary 8, 2018
Since Atomic Smash started in 2010 we have been evolving the way we plan and deliver projects. As the company has grown, so has the complexity of the work we deliver. This naturally requires more thorough planning, preparation and estimating. Sadly creating accurate estimations and work schedules can be difficult on a project running over 6+ months.
This is our planning process, 2018 edition.
Discovery workshops with key stakeholders are essential for scoping out work and distilling what the project needs to fulfil. Even though the client may already know some standard KPIs (Key performance indicators, e.g. increased sales) it’s great to also define what else might make the project a success.
An example of one of these softer KPIs may be to put in place automations to help the internal team save time and use their WordPress site as more of a business platform (rather than a flat digital brochure).
Workshops should be proactive and as ‘physical’ as possible. NO to computers, phones and tablets. YES to pens, post-it notes and large sheets of paper.
One lesson from these sessions is also to have a developer working on the project as soon as possible. They can sense check a lot of the possible requirements and answer the more technical question right there and then without delaying the workshop.
At Atomic Smash we have set a new rule for development resourcing on projects. All work is now split into frontend and backend tasks and a minimum of two devs will work on a project simultaneously. As Frontend HTML is being built/styled, the backend data structure that populates the HTML is being constructed. Yet before any code is written, the development tasks need to be documented. This is where GitLab (our version control hosting tool) really comes into play.
First, we describe every backend and frontend task and create appropriate tickets inside GitLab:
This is usually possible at this stage due to all the requirements gathering and exploration that occurred during the UX and design phases of the project.
On a ticket by ticket basis, we’ll estimate the amount of time we think we’ll need to complete that single task.
This then gives us a very clear picture of how long the project will take in total and at a very granular level.
Tagging issues help categorise tasks, but GitLab also uses these tags in a very interesting way (more below).
Lastly, using the time estimation and knowledge around ticket priority for the project in hand, tickets can be grouped into weekly sprints.
All these steps can happen at the start of the development phase of a project but’s it’s important to review and revise deadlines and tasks in a structured method. The best way we have found to accomplish this is run a quick project stand up to see if everyone is on schedule and to make sure no one is being blocked from continuing their work. We usually set weekly deadlines so it also makes sense to have at least one standup a week.
The GitLab issues system has another fantastic feature called ‘boards’. This is a visual representation of the tags assigned to issues (Step 3 above). As long as you have coordinated the creation of the tags, you can easily create a Kanban style progress board. We are currently using these four tags for progress lists:
These are represented visually inside GitLab like this:
This board is then used in the stand-ups to quickly work out weekly progress and assess any potential blockers. As project development progresses cards slowly move their way from the left-hand column to the right:
Once everything is inside the right-hand column, you have a complete project ready for UAT (user acceptance testing) 🙂
With a shift from one, to at least two developers working on a project, one common blocker might be the backend developer needs front-end code that hasn’t yet been completed. To reduce conflicts we solely build frontend HTML using TWIG and the Timber plugin by Upstatment. This MVC(ish) approach to building sites separates logic (Php and WordPress queries) from the frontend HTML. Backend and Frontend code can then be built in isolation and quickly slotted together when appropriate.
Slack is also a crucial part of our workflow. When even anything happens on the project, all project members get alerted. This includes issue creation and commenting, right down to code being committed to the repository.
The other important note is that this process is evolving and iterates/improves after every project completion. There are many new avenues that we are currently exploring. One area of interest is the auto production and population of UAT environments for disposable testing. Also researching into using GitLab to help with continuous integration and delivery for WordPress. Yet it has been said:
So we are expecting this to be a significant investment in time. Maybe one for the next version of our development workflow 😉