When all development is complete on a web project and the site goes live, there are often new ideas that come up that were never even considered at the outset of the project. That’s OK! One of the great things about a website compared to a piece of physical media is that it can usually be changed on the fly. At Webspec Design, our clients are always coming up with new features and enhancements to their products, sometimes weeks or months after their site has launched. At the beginning of 2013, we found ourselves with such a deluge of these new additions that we started to face a real problem: How could we keep up with all our current clients’ new ideas while taking on new projects at the same time?
Adding new programs and version control
Our previous strategy for handling new features for completed projects was to have the original developer handle these requests whenever they had time to do so. While this did ensure that everyone had a high level of familiarity with the existing code base for each project, it limited our ability to respond quickly to incoming requests. We needed a way to spread tasks out among our development staff so that these enhancement items wouldn’t take a backseat to the individual developer’s full-scale projects.
We quickly realized that in order to separate work from the original author, we’d need some sort of version control for our code. Version control takes a snapshot of your source code as each new feature is added, and makes it possible to restore your code to previous versions if need be. We chose Git, a popular version control system in the open-source community that is decentralized and supports flexible branching workflows. It took a few months for everyone to get comfortable with Git, but the benefits have been remarkable. Git gives us context as we sit down to work on enhancements to code we’ve never touched before. We can scroll through the history of the project, seeing who has worked on it and what has already been added. We immediately know who to ask if questions come up, and we can track changes to any file within the project back to the very beginning. That way, if someone new worked on it or some feature was broken, we knew who to ask and what needed to be fixed more clearly than before.
Organizing our workflow with Kanban
We now had a way to decouple the original developer from future work on the project, but we still needed a way to organize these incoming requests. I had been reading about a system being used in manufacturing called Kanban, which was originally developed at Toyota as a way to limit the amount of work in progress (auto parts being produced) and focus on keeping a steady stream of product moving through production. In software development, Kanban is usually represented visually as a large whiteboard divided into columns representing the stages of the development process. For example, you might have “To Do”, “Doing”, “Review” and “Done” columns. You then write each task down on a sticky note and place it in the first column. As work moves through the development steps, you move the corresponding sticky across the board to indicate its current state. By visualizing your workflow, Kanban allows you to make informed decisions about resolving bottlenecks in your process and coming up with ways to improve it.
Asana: The final piece in the workflow puzzle
But before we could introduce Kanban to our workflow, we needed one final piece. Sticky notes are great for having a movable representation of work, but many of the tasks we get need a more detailed explanation than the stickies allow for. There might also be images or other files that need to accompany the task. We decided to use a web application called Asana to assist us in keeping track of these task assets. As a task management system, Asana allows us to easily create, edit, assign, and comment on tasks in real time with the rest of our team. It also supports task creation by email, which has proved very convenient for newcomers to the system.
The Webspec workflow in 2014
With all these pieces in place, we decided to kick off the new workflow changes by having a brief 15-minute stand-up meeting each day where we would interact with our Kanban board and talk about the work we’ve accomplished, as well as work planned for the day and any impediments. This has helped get our whole team in sync, while providing a jumping-off point for further discussions about issues we might be having. In the past five months of using this new workflow, we’ve noticed a dramatic increase in the rate and speed of enhancements we can make to our existing projects. Because any developer can work on these items and because we have a highly visible representation of the work that we interact with regularly, we are better able to keep these tasks from slipping through the cracks or being pushed onto the back burner.
While we’re happy with the changes we’ve made so far, we also know there’s room for improvement in any process. In the coming months, we’ll be applying what we’ve learned here to more of our new projects, and we will be looking at the data we’ve collected so far to make decisions about how to refine our process further. One thing’s for sure—having a well-defined, organized workflow is key to identifying bottlenecks and making positive changes in the way you get things done and we’re excited to be taking our first steps along this path.
