I keep a lot of different plates spinning in my professional life. Sometimes it’s working as a developer contractor, sometimes as an architect/manager, sometimes on my own projects that I’m writing the code for and other times my own projects I’m hiring people to build.
Over the years I’ve tried pretty much every piece of project and code management software out there. Jira, Github, Bitbucket, Asana, Trello you name it I’ve probably attempted to run a project on it. In this article I’ll go over what I use now across all projects that I have a stake in and how it keeps me sane and (more importantly) my hired subcontractors honest.
Who this is for
This methodology is not for big teams and professional release cycles of stable apps. More sophistication is needed there certainly. But in most startups and smaller software projects, you’re usually collaborating with a team smaller than 10, and I’ve found the following process to really cut out a lot of the bloat more complicated release cycles come with while also making sure that the actual software still get’s built to spec.
The Tools: Trello and Github
How I Run Trello Boards for Developers
A lot of solutions for manager developers I feel have gotten overcomplicated. When it comes down to it, you need a way to communicate to developers exact functionality, a way to test that functionality, and a public means of tracking it’s status each step of the way. Enter trello
Here’s a project snapshot of the board. Cards Start in either the Inbox or the Backlog and get dragged from left to right until they are marked as complete. Pretty straightforward.
Some people accomplish this exact same process via Jira Kanban boards, or directly on github as well. For some reason I’ve never found myself or any of my developers working well with either of those interfaces. If you are all developers then I say sure go for a full Github solution for project management, but I’ve never seen a non-technical person succeed with keeping up with a project board + issues on github.
Once your are on Trello, there are two main methodologies you can use for creating cards. The ‘Story’ way, or the the ‘Explicit’ way. I like to use a combination of both.
Stories – This are beefier cards that contain details of a broader accomplishment. For example your card title could be ‘Implement User Sign On Functionality’, we want our users to be able to have an account and login etc.
Then inside the card you use a Checklist to breakdown what that means. For example:
- Users can register a new account with an email
- Users can sign in with password
- Users can reset passwords via email
Now you have one broad card to ‘track’ this function getting built into your application, while also specifying the exact actions that need to work for your development team. This will come in handy when developers say they’ve completed something that actually doesn’t work 🙂
Github
For a lot of non-technical founders or project managers Github is a blackhole where code is magically stored by your developers. Now by using trello how I mentioned above, you can 100% keep it that way if you must. But I would advise you to learn the basics of Pull requests and require your developers to use the following flow.
Forcing discipline on your developers makes life easier whether you can actually read the code yourself or not, so it’s worth doing.
There is a lot of good reading for Github beginners here
https://guides.github.com/introduction/flow/
But for the already initiated somewhat, I recommend doing the following for small/mid sized projects that won’t need a legitimate structured release cycle.
Create two branches, Development and Master. Master will only contain the code that is know and tested to be properly functioning. This is what you deploy out to the world to be live and visible.
The development branch contains the ‘in progress’ code and the new features. This is what gets tested/verified and then ultimately merged into the Master branch.
Feature Branches and Pull Requests
With that basic setup of two main branches, have your developers create ‘feature’ branches. A feature branch is meant to track one specific set of changes and is essentially a copy of your ‘Development’ branch. Feature branches should map directly to cards in your task management system (Jira card number, Trello card etc.) So going back to our example of a trello card titled ‘Implement User Sign On Functionality’, you can have your developers create a feature branch called ‘authentication-feature’ etc. to hold the code that will directly fulfill the Trello card’s requirements.
Pull Requests
Pull requests are a way on github to add your changes into the existing code. In our example above, when developers finish the code for ‘Implement User Sign On Functionality’ and it’s ready to be tested, I have them submit a pull request to merge their branch ‘authentication-feature’ into ‘Development’.
This accomplishes two important things. First, it gives me a really simple interface to review specific code changes (Github makes it easy to see what files have changed and where). Second, it forces the developers to keep the new code separate from the rest until it’s tested.
Oftentimes developers will get lazy and stack on a bunch of changes into the same release. This creates nightmares down the road while you’re testing because if some features work and others don’t, you will eventually lose track of the status across all of your cards. So I insist on pull requests per feature, and nothing gets merged until testing has verified the update to be functional and safe.
Test, Update Trello, Iterate
This is the part that trips people up most often. You MUST be relentless about testing new features, updating their status in Trello (whether they worked or didn’t) and facilitating the merging of good code back into the development branch.
When providing feedback, it’s important to be as explicit as possible. That means screenshots with parts circled, videos, the works. If a feature isn’t working you need to SHOW it on trello, otherwise there’s about a 75% chance your developer will respond with something along the lines of “well it works for me…”. In order to drive the revision cycle forward you need to prove something is wrong.
From there you just keep repeating the cycle on all cards, features branches. Once something is tested and works, get it merged and keep on moving. In future posts, will get into some more practical means of quickly deploying/testing applications (for non-technical founders) that have saved some of my clients a lot of time and headaches.
