Software Engineer at GoCardless
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.
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.
Having a proper ticket template is something that some teams struggle to have, but my experience shows that they are very useful.
Even for simple tasks, following a standard gives us the comfort of repeat-ability. If I know every ticket has the very same format, I spend less time trying to figure out what the ticket is trying to tell me and what kind of work must be done.
The main elements a ticket must have are:
This whole ticket template thing also have a fancy name: definition of ready. That means that the story is ready to be worked on once it has all those characteristics well documented.
Having all clearly stated will also have an idea of the amount of work to be done and if the ticket needs to be broken down in smaller pieces, as we will see in the next session.
Here is a small gist with the latest version of my ticket template: https://gist.github.com/danicat/854de24dd88d57c34281df7a9cc1b215
Whenever you notice that your ticket is too big, please take the extra effort to break it down. It usually pays off.
For instance, let’s say you need to setup a new service on GCP, like a Cloud Function. One of the steps may be getting the permissions right (maybe manually or automating with Terraform), other is to write the code and so on.
Those would fit nicely in a To Do list on the ticket template, but if you list everything you need to do in a single ticket you will have a bloated ticket that will take forever to finish.
It is also hard to track the speed of your work, which would delay that small gratification we all have when a piece of work is delivered. Lastly, you can make really hard for your team to review the work after is done.
So whether you use a score point system or just look at your To Do section and it has too many items, make sure you can split them into smaller tickets as soon as possible. It’s ok to have tickets with only one To Do, those will be one-pointers and probably you and your team will be able to deliver them in parallel instead of serialising all the work.
If it was not you that has written that ticket, it may be useful to call for a refinement meeting (15 to 30 minutes) with the key stakeholders or developers to see what kind of work can be broken down into smaller pieces.
That investment time will pay off with faster review and delivery times.
At GoCardless we still adhere to some scoping documents as it helps the predictability of our work. Our stakeholders need to know what kind of work will be done over the next few quarters.
Writing a scoping document places a huge responsibility over someone’s shoulder. We have been experimenting with that and we’ve discovered that pairing during that process not only makes it less stressful but also produces better results.
One of the outputs of the scoping phase are the initial tickets, that can still be a bit rough and bloated (like, a lot of 5-pointers with a lot of To Dos) and hence come the importance of having refining sessions afterwards, usually during the kickstart of a new project or even the proper ticket.
Pairing during refinement is also a very good thing, as having different views over the same problem often help seeing where the line can be drawn in a safe way.
It is also common to leave the scoping phase with several questions. For those, Spike tickets (as opposite to Story tickets) should be created. Spike tickets are the ones that hold one or more questions to be answered (ideally one). Most of them are questions about technical implementation (e.g. different alternatives), but some spike tickets may be related to some business uncertainty.
From my experience, spike tickets should be time constrained (usually 2 days of work) and shall produce answers to the proposed questions followed up by story tickets to implement the correct path.
Sometimes the conclusion of a spike ticket is that something must not be done, and that is ok as well. Please beware: a spike ticket without a question is not a spike ticket! The ticket should accommodate all the questions that must be answered and the acceptance criteria should be adapted accordingly.
As spike tickets are closely tied with uncertainty, we should account for that uncertainty when planning our sprints / quarters considering that at least one 3-pointer ticket may be created for each spike ticket.
Finally, resist the temptation of implementing the spike ticket during the spike process. Separating spike from story tickets has many benefits in terms of tracking the work later on. Of course, for very small changes exceptions may apply, but I prefer to be purist on that one.
After organising your tickets, you will probably start to see common themes appearing over and over. They may be a sign that you need a runbook/playbook to optimise then.
A runbook is a manual with the instructions step by step to solve a given situation. For some teams this is more important than others, but all teams can benefit from this.
From the Google’s SRE book, Chapter 1, page 10: “thinking through and recording the best practices ahead of time in a ‘playbook’ produces roughly a 3x improvement in MTTR”. MTTR is the Mean Time to Recovery (from failure), which means the average time your team takes to take your system from an unhealthy state to a healthy state again.
It is also important to observe the number of tickets that indicate manual tasks (toil) that can be added to a runbook because they later on may be used as a sign for stuff that needs to be fixed or automated.
Even if you don’t have a SRE dedicated to your team, having the clear view of those issues should help prioritising work during investment work as opposite of project work.
Every team should aim to achieve a healthy balance between investment and project work, as this is what makes team throughput scale over time beyond adding new developers.
Those were a few insights I got based on my experience working at Globo.com, ThoughtWorks and now GoCardless. All of them used the Agile framework at some level.
From those experiences, my learnings show that those hints above were the ones that were easier to implement and had the most immediate benefits. Hopefully they will be beneficial for your company as well.
I by no means am an expert in Agile transformation, but if you have any questions please leave them in the comments section below and I’ll do my best to answer them.
Create your free account to unlock your custom reading experience.