5 Ways to Optimise Team Performance Without Going Full Agile

Fnelly
Fnelly
Nov 3 · 2 min read

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.

Fnelly

Written by

Fnelly

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade