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.
2. Have a ticket template
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:
- Context: a brief description of what the feature or problem is. Telling how it worked before and how is supposed to work is a good thing. Also, include any reference material that is required for understanding the whole picture. It is not necessary to copy the whole scoping document here (if you have one), but also just linking to the scoping document without explaining anything is not a good practice. Ideally the ticket is self contained and the reference material is just for further clarification.
- To Do: a list of items to be done in the ticket. Keep them small and self contained. If you have more than 4 items to be done in the same ticket it is a strong signal it must be broken down into smaller tasks.
- Not To Do: an optional section to make clear what should not be done in the ticket. Maybe because it is reserved for future work, like predicted in a new ticket, or because it was not agreed with the stakeholders yet. Not to do is a section that has the purpose to limit the timebox for a ticket delivery so we can be really agile in delivering changes, making sure we don’t merge future work in current work by accident, like: “oh, I was in the mood and decided to do everything in one go”… then suddenly you have a mega PR to review that will take a lot of effort from your team. Please use this section wisely.
- Acceptance Criteria: also known as Definition of Done, ideally they would be a list that follow closely the To Do list above, to make sure every required was implemented correctly. It is not so useful to explain here how to test, but it is really important to tell what to test. Both happy and sad paths. Ideally anyone from the team should be able to test it, even non developers like the Product Manager. At ThoughtWorks both the Product Manager or Business Analyst would hold a acceptance meeting for every story that was in Acceptance, being driven by a developer following the acceptance instructions. You don’t need to go that far to have an official ceremony for acceptance, but please make sure the criteria are well written and reproducible by anyone with minimal knowledge.
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
3. Break down tickets into smaller ones whenever needed
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.
4. Pair on scoping and refinement sessions
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.
5. Have a playbook/runbook for common tasks
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.
Conclusions
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.