I must have tried at least a dozen project management tools and workflow strategies since my first commercial project way back in 2005.
A development workflow that consistently delivers is without a doubt one of the biggest recurring pain points in a software developer's life. Even with regular fine tuning, what works one month might not work at all the next.
The reasons for workflows frequently breaking down are varied, but some common reasons include scope changes, personnel changes, unanticipated events or non-work life events.
There are two abundantly clear dilemmas to solve for any software development team:
Touch wood, at Coding Labs, I think we have answered both of these questions for the foreseeable future, leaning heavily on the inspired thinking and products created by dozens of others.
It goes without saying that no system is perfect and what works for us won't necessarily work for others.
But before I dive into the 2019 strategy, here is a summary of some of the strategies i've tried.
Often a great place to start is the good old pen 'n paper. In fact I still use this method regularly during meetings or when I am well and truly stuck on a complex task.
On the downside, it does not scale to other people (especially if your handwriting is as illegible as mine), it is extremely messy, environmentally wasteful, and you can't access it remotely.
Following the "scratch your own itch" wisdom, and with the added benefit of documentation that could survive an overzealous desktop cleaning effort, in the late 2000s I developed my own internal project management software that kept my to-dos organised, supported client log-in, and even had a rudimentary password vault*!
Like a lot of my DIY experiments over the years, this project also fell in the basket of don't be a tightass, stop wasting time and find a fully featured product for ~$10 a month to do this thing.
To my great joy, I recently discovered that my original Basecamp account from way back still existed, and even better still, had the same original UI!
Basecamp was pretty good for me in some ways (certainly much better than my DIY efforts), but nagged at me in other ways as I learned more and more about agile workflows and sprint development.
It felt geared to marketing types whilst my interest was pivoting strongly towards application development with more complex needs.
Enter the King, the enormous monstrosity that is Jira*.
The project management tool that literally does everything you can think of.
In many organisations Jira has a specially trained staff person just to circumnavigate the settings, let alone utilise it to its full potential.
I had a good 2 year run with Jira, the integrations, analytics and reporting are fantastic, and when used properly can do powerful things.
* In fairness, Atlassian appear to have recently made substantial progress on lowering the barrier to entry for Jira
One of the frustrations in a lot of project management solutions, is that they do some things well but omit other features because some other SaaS product does it better.
For example, how good is a plain old word processor to formulate a written plan, or even just used as a bit of a dumping ground for ideas that are not quite development-ready, but still worth noteworthy.
I briefly flirted with Google Docs as a pseudo project management solution, and yes, it lasted about a month before it fell apart at the seams.
With the inevitable breakdown of Google Docs as a viable task manager, I was back on the hunt. On a recommendation, I gave Clubhouse a try.
Like Jira - with an unmistakable focus on software developers - but without the kitchen sink; Clubhouse looks and works great right out of the box.
Again with solid reporting features and probably the best milestone, epic and to-do list functionality i've ever come across (bulk to-do editing ftw ?), Clubhouse held its own for about 18 months.
But there were still some nagging questions:
History repeats, and for me that meant returning to Basecamp at the beginning of 2019 after almost a decade long hiatus.
In the interim, a lot of things have changed at Coding Labs:
Basecamp is currently solving all of the above issues (and more) for us.
I have spoke at length about the tools I have used, but not much about the overarching strategy that guides how we estimate, budget and allocate time.
The truth is, I have tried just about as many workflow strategies as I have project management tools. To list a few:
Perhaps my scrum master gospel just ain't up to scratch, but what I always find is that sooner or later, a project reaches a stage of decision-paralysis, with so many good, worthwhile ideas; but for various reasons, the work that gets ultimately shipped does not come from the great ideas basket, but rather the this-is-more-urgent basket.
On the estimating front, an estimate for a task bigger than about 10 hours is not worth the paper it is written on.
At the start of 2019, I decided to strip our processes right back to barebones, and re-think our workflow from the ground up. The things I have figured out over the last 14 years are:
Borrowing heavily from Basecamp's inspired workflow, at Coding Labs we settled on a 2-month workflow cycle.
Part of the carry-over benefits of moving back to Basecamp, is that there is no room for ambiguity about "where things go". If it relates to project management, it is in Basecamp.
For the most part, ideas start in a per-client document called the Scrapbook. This is a semi-organised collection of pre-pitch ideas and incidental backlog items that are not ready to be actioned, but still worth remembering.
In the first week of a cycle, we start harvesting Scrapbooks for ideas and liaising with clients about what they prefer us to tackle next.
There are no hard and fast rules here, the chosen work just needs to be big enough to be worthwhile, but small enough to be achievable within the timeframe.
The winning ideas proceed to a dedicated project in Basecamp, each with its own guiding Pitch. The Pitch details in broad strokes the who, what and why of the project.
Each Pitch is very much a living document and subject to change during Pitch Week as the underlying tangible result emerges from the rough.
The Build follows on from the Pitch in roughly two halves.
The first half is all about further refining and assigning the actionable tasks that have emerged from The Pitch. As time passes, we establish a strong grip on exactly what will be built through prototyping and validating ideas.
The second half is all downhill. We know exactly what we are doing and we go about getting the job done. We test, review and try and break things. Time permitting, we look for opportunities to add a final coat of polish.
At both the individual project level and as a company, we take a look at how we performed, tie up loose ends, celebrate victories, and look for ways we can do even better the next time around.