Build your roadmap

The first step is to get the team together to create a roadmap. Roadmapping is a key deliverable of the ‘Think’ phase in our services framework. The roadmap clearly defines each feature that will be developed and what ‘use cases’ need to be met in order for them to be considered complete. It’s important that everyone gets involved here because different people bring unique perspectives. Doing this surfaces a lot of questions that are often discovered later in the delivery process. Roadmapping gives us a clearer mental picture of what we are about to build and helps us to estimate as accurately as possible.

Break it down into tasks

Once we’ve got a completed feature roadmap we break it down into manageable chunks. These serve as a list of ‘jobs to do’ and we display them as cards on a kanban-style board. Each card has a description of what is required, acceptance criteria, and an estimate. We refer to this as our development backlog and we store it in ClickUp. ClickUp allows us to identify what each member of the team is working on, empowering project managers to track progress.

Cards in the backlog are prioritised. When a developer picks up a new card they’ll read through the detail on the card and find another team member to discuss it with before writing any code. This discussion of card details helps the development team to align on exactly what’s needed to deliver the feature. More often than not, this uncovers further details and saves us from having to jump unexpected hurdles later.

Lock down your source

Source control (or version control) is arguably the most indispensable tool in software development. Not only is it where we keep our code, but it is also a log of who made what changes when and why. It allows us to work collaboratively and provide feedback on each other’s work before it is approved and deployed. We use the git version control system and store our code in the cloud using GitHub.

Don’t get sloppy, always be shipping

As we push code to GitHub it’s not only reviewed by team members, it also goes through a process known as Continuous Integration (CI). A CI server automatically pulls down the code, builds it, and runs tests against it before finally reporting back if there were any problems we introduced.

There are many CI tools out there and currently we’re working with Codeship. This is another crucial piece in the development puzzle of being able to ship code confidently.

The other half of a product like Codeship is its Continuous Deployment (CD) capabilities. CD is taking our code as it lands in the cloud and automatically deploying it to an environment of our choosing so that we can see it in action.

At the very least, our projects will have a staging environment and a production environment. The staging environment houses the latest features that have been developed and merged to the master branch. The production environment is the polished, customer-facing product. Having multiple environments allows us to ‘play around’ with the product before we push it live without any fear of breaking anything.

Another tool we like to use is Tettra, a wiki to capture knowledge for future reference. We’ve found it to be a great way to onboard new team members as well as the general sharing of knowledge between the team.

That’s the short of it. If you’re interested to hear more then get in touch!