Periodically, others will ask how I manage to organize the various tasks, assets, resources, and related things throughout a project. First, I’ve decided to keep Pressware small (and this is for some reasons), so it allows me to run it differently than if it were, of course, larger.
Secondly, I typically use a very scaled down version of a kanban board. For those who aren’t familiar, kanban is defined like this:
a Japanese manufacturing system in which the supply of components is regulated through the use of an instruction card sent along the production line.
To that end, I thought I’d share a brief overview of how I typically setup each column and each card as well as the tools I use to handle each task.
Kanban in WordPress Development
Generally speaking, every board that I set up – and I’ll talk about the tools I use for these momentarily – include four columns each of which are defined as follows:
- TODO. This is essentially the backlog of tasks that need to be done to complete the project. It’s a listing of all of the requirements that are usually outlined in the statement of work but broken down into tasks that can move through each column to see progress being made.
- Doing. When a card is in this column, it means the team, someone else, or I, am working on it. Sometimes a card will contain multiple subtasks (which are usually identified as check boxes), and we keep them updated with the status of the task. I try to keep each card related to a commit in source code so that if we have to roll something back, then we move a card back into a column. Alternatively, once we commit a change, then we can move the card to the next column.
- Review / Staged. This column means that work has been done and it’s ready to be reviewed by the user on the staging environment of the site. Typically, I give customers access to the board, so they can do just that. That is, they can see when something is ready for review, have access to the staging site, and can verify that the requirements listed int he statement of work and on the card are ready to go.
- Done. Once the customer has verified that the work that’s completed is done to their satisfaction, the card moves into the done column, the code is merged into the master branch, and then the cycle repeats. If, however, the task is not done, then the card goes back to Doing and moves back through the pipeline until it’s ready for release.
Now when it comes to working on projects, there’s one other aspect that must be considered: Assets.
A Single Source of Truth
Specifically, I’m talking about anything that ranges from:
- fonts,
- designs,
- credentials for third-party APIs,
- third-party tools,
- or generally any other assets that may be needed from the project outset or from when the project developers.
There are a couple of ways to handle this and I try to let the nature of assets dictate where I place things. For example, design assets are often kept in a shared Dropbox folder or perhaps a card, if they are small (but they usually aren’t). Even then, I still may create a Resources column and list cards with links to the Dropbox folder, for example.
If it’s crendentials for an API, I may place it in a card under the Resources column but if it’s something sensitive then I may use a private Droplr note and then link it from within the project management tool of my choice.
You get get the idea, though: The nature of the asset determines where it’s stored, but the kanban board always references it someway. This is what helps it remain a single source of truth for you and all parties involved.
And For Tools?
I think many of us love to try to the new shiny thing. For some, it’s almost a habit:
A new project management tool is released? Let’s try it. For others, there’s if there’s a tried-and-true method that’s working, then why not stick with it?
Regardless of where you fall, I think it’s important to find what what works best for you and your team and then use them consistently and in a prescriptive way that can be applied across projects.
For me, I tend to use the following tools:
- Trello or GitHub Projects. This largely depends on the customer.
- Dropbox for sharing assets.
- Droplr for securing credentials.
- Google Docs for Statements of Work and Terms and Conditions
- Google Docs for Expense Reports
- Invoicely for invoices.
- Eversign for eSignatures on the above documents.
I know that for a few of the software above, some may be concerned about security especially as it releates to financial or secure information.
I don’t take this lightly. The rule of thumb I try to follow is that if it’s something I think needs to be kept completely secure, then I will use an appropriate system to use it; otherwise, if it’s something that I truly don’t mind if someone was to access, then it’s okay with me.
And I think that’s an important consideration we need to make as prople providing a service to others. In fact, it’s probably content for another post if not an entire other blog. But that’s not this post, nor this blog – at least not right now.
My Point?
Ultimately, make sure you have the following:
- a way for you and your client to track the progress of a project through the development life cycle,
- a way for them to see how things are going that aren’t overtly tecnical like source control,
- a way to share and access as needed,
- the ability to communicate and ask questions as needed.
I’m sure there are other things worth noting but these are key to the content of this post. So using kanban in WordPress development is not difficult, but it’s also undergirded by a few additional things that can make the process easier.
Keep a single source of truth supported by third-party services that make it easy to collaborate.