
My last job in Brazil before moving to the UK was at ThoughtWorks. While I didn’t agree with everything that they did there (OMG… Java, please no! ^_^’’’) there is one thing about ThoughtWorks that is incontestable: they are very good with processes.
Processes is something that I’ve grown very passionate about. By optimising processes you can not only make the life of your developers easier, but you can also scale up your productivity. That’s how you get the multiplier effect.
If you are going full Agile though, maybe starting from a waterfall-like process, that may be a long long road. It is useful to introduce changes little by little and measure their impact. Full Agile may also not be for everyone, so testing the grounds is very important.
1. Have a board to organise your work
As a prerequisite to the rest of this article you must use some kind of board type of tool to organise your work. There are plenty of options out there, with the most famous being Jira, Youtrack, Trello and GitHub Projects.
The usual columns you would like to have are To Do, Doing, Acceptance, Release and Done, but those would vary a lot depending on what kind of process do you have in place.
To Do: work that has to be done, but hasn’t yet startedDoing: work someone has already started development and is working on currentlyAcceptance: work that has been done but must be reviewed by someone elseRelease: work that has been accepted in the review process but hasn’t been deployed yet.Done: work that has been deployed and is already working in production
Usually the team would have the autonomy to tag themselves in the tickets at any point in time. A single glimpse of the board should be enough to know where everyone is working at.
One common mistake that I see is that teams often valuate too much the Development stage and forget to flag themselves when they are doing Acceptance or Release work. We need discipline there, as this is also important work. Being an engineer is not only about writing code!
Also, when passing a ticket from one stage to another, it’s important to remove yourself from the ticket so everyone know that they can pick them up to work on them. It is also ok to rollback a ticket to an earlier stage if it is not ready, e.g., from Acceptance to To Do. It is better to do that than to release a faulty product and raise bug tickets afterwards.
The whole process should be thought in a way that the tickets are independent from the person that wrote them or have worked on that particular task in the past. That’s where comes our next hint.
