I did some micro blogging on twitter about Kanban and SCRUM
I had a discussion about Scrum and Kanban. I prefer kanban as the problem with half finished tickets does not occur. For small teams it’s easier to manage. With daily, grooming sessions and retrospective.
— Christian Liesch (@ia97lies) April 27, 2021
I wonder what #gamedevs are using? #gamedev #indiedev #Scrum #kanban
It’s actually a fun topic and executed well can bring a team together to work on a project. It involves the whole team and can not just be dictated that is a very important part. And this involvement also increases the team spirit as everybody gets a voice to improve the process.
Kanban over SCRUM
I prefer Kanban over pure SCRUM because it solves the problem of half-finished tickets. SCRUM usually plans a set of tickets for a sprint and developers tend to try to finish all tickets within a sprint at all costs because it was promised to the customer. The problem with that is that either you skip unit tests to get stuff done in time or you do only 80% of the task which leads to follow-up tickets. It’s a lot of work to keep an overview and needs in my opinion a fully committed SCRUM master.
Kanban, on the other hand, does not plan a specific amount of tickets for the next sprint but over time you get an understanding of how long on average a ticket needs until it is done. This gives the team more freedom, leads to better quality, and reduces the stress on developers to finish tickets on an estimated time. Often the estimation is not even done by the developer who takes the ticket! And a ticket is done if it’s done 100% including testing. And Kanban has less overhead compared to SCRUM and fewer rules.
SCRUM Particles
But I like the idea of dailies, planning, and grooming from SCRUM. And always take care that a meeting has an outcome and is as short as possible. I don’t like meetings in general as usually it’s just chatting and complaining but not outcome-oriented. It needs a person which moderates a meeting and keeps the meeting on the topic at hand. It’s for example totally pointless to waste time talking about your code problems in a daily meeting, just state you have a problem with your code and then figure out who could help you. All the meetings have a specific purpose and the moderator should take care that all participants stick to that purpose and stop discussions that have to take place elsewhere.
Daily Chat
A daily should consist of the three statements
- What did I work on before this daily
- What do I work on after this daily
- State the blockers I have
The first two points are to make sure everybody in the team knows what topic you are working on and the last point is about your problems and defines who can help you to eliminate them. The meeting should be quick and concise. Nothing is more boring than following a discussion you are not interested in. Imagine you also might have your game designer in your daily among some developers. If developers start to explain in detail their problem they waste the time of the game designer. I was in so many meetings where two people started to discuss a topic only they did understand and where I just thought ok I would like to go back and work now. And I’m sure I’m not the only one.
Planning the Sprint
I like the idea of sprints, but in the Kanban world, this can be more dynamic than in the SCRUM world. This means the stakeholders can influence the backlog stack by sorting it and the todo column of the Kanban board as well. This gives them a huge benefit in short-term decisions. The stakeholder can not influence tickets that are already taken by a developer except having serious reasons.
To make that work the developers must work the Kanban board from right to left and from top to bottom. Cherry picking is not allowed. This as well does have a huge benefit as the unwanted uncool tasks are evenly distributed on the team. It’s also very self organizing if all developer follow that rule.
The time a ticket needs from left to right on the Kanban board is at the beginning not clear. After 4 – 8 weeks it becomes more clear how long a ticket needs in average till it is done and then you also can calculate how many tickets you can do in one sprint of lets say 3 weeks and the stakeholders can see on the board what is in the next release for sure and what might be in the next release. Of course there will always be the case where a certain ticket just takes much longer than the average but will be less likely the longer you do Kanban.
Grooming the Backyard
This is the most valuable meeting in my opinion. It is important that all developers participate. The ultimate goal is to make sure that in the end, everybody understands the scope of the tickets you groom in the backlog. The moderator of the grooming meeting documents all the findings, howtos, and input them into the description of the ticket. As we always play planning poker on those tickets and you do not estimate the time but the complexity. There might be a ticket with a complexity of 0 or 1 but will take 2 weeks because it is a lot of work. You still can split such tickets if you know it might be a lot of work.
Hearts, Diamonds, Spades, or Clover
The planning poker can be played with physical cards or online like this one https://scrumpoker.online/. We used usually the schema Fibonacci series 0, 1, 2, 3, 5, 8, 13, 20, ?, or coffee. After a while it was clear to us that tickets which have complexity of 8 or more needs to be break up, but I think this is highly related on how a team understands those numbers. For us this became clear over the course of 3 plannings. We used the retrospective meetings for this kind of fine tuning. But it reflects the understanding in the team. If somebody put a high number which was higher than the rest he/she did explain his concerns as he/she might found something the rest of the team did not think of.
Retrospective
The retrospective meetings were mainly to improve the process i.e. how to work on the Kanban board when to do a review of a ticket, or if we need an additional column on the Kanban board among many more.
Usually, every member of the development team did prepare a set of positive points on what went well and a set of negative points on what went not so well. For the negative points, he also prepared a possible suggestion on how to improve it.
Kanban Board
The Kanban board should have at least a Todo, On Hold, In Progress, On Review, Verify, and Done slot. Every slot should be limited, we used the retrospective to figure out the best limits. The Todo should always have enough work till the next grooming session. The On Hold slot is for every ticket where people are blocked and need feedback or input. All tickets where somebody was working on are in the In Progress slot. If you pushed your stuff to your source repo you also moved the ticket into the Review slot. In case the reviewer did find issues you had to put back the ticket into In Progress. And if you finally managed to solve the ticket you had to put it into the Verify slot. The Verify slot stands for you have to install the product, game, plugin, whatever it is, and try out if it works or not. And it’s important that not the same person who worked on a ticket did the verification. The verification was a very good instrument to distribute the know-how in the team.
As I said in the previous chapter already, you work from right to left and from top to bottom on your Kanban board. So whenever I finished a task or came to work in the morning, I went on the board and had a look if there are tickets to verify. If yes I took one ticket after another and verified them until there was no work left for me. If everybody does it, it’s unlikely that I have to verify a lot of tickets in one go. Usually one or max two tickets. Then I go to the next slot and review all tickets in that slot. And if I was done with that I took my ticket from yesterday in the in-progress slot. If there is no ticket in the progress slot I took a look at my on-hold tickets. And if even there everything was done I mechanically took the topmost ticket from the todo slot and put that in progress. I do not even look what ticket this is, I just take it and deal with it.
Meetings
Keep them short.
