Baking Boards – Episode 5: CLion & AppCode Kanban Board
In this episode of Baking Boards, two of our Quality Assurance Engineers show you how the CLion and AppCode teams use their agile boards to follow a Kanban-inspired methodology.
Preparation
1. Create your board.
Start with the Kanban board template.
2. Add your projects.
You can add multiple projects, but on these boards, each team only manages issues that are assigned to one project. The CLion and AppCode teams have separate projects, and each project has its own board.
For the Backlog option, choose Create new. You can set this up later.
Just click the Create Board button to continue with the setup.
3. Rename your sprint.
Our teams works in a continuous flow that is represented by a single, unscheduled sprint. To make this more obvious, they renamed the default sprint.
Follow these instructions:
- Open the sprint drop-down list.
- Click the Edit icon next to the First sprint.
- Rename the sprint. We changed the name to Current.
- Leave the sprint as unscheduled and apply your changes.
4. Set sprint options.
For a Kanban board, you would normally add all new issues to the board when they are submitted in the project. These teams use the backlog to prioritize issues and manually add the issues to the board.
However, they use the Automatically add new issues to Current sprints option in order to transfer the issues between the CLion and AppCode boards. When an issue moves between the CLion and AppCode projects (which happens quite often), unresolved issues are assigned to the current sprint in the new project automatically. This ensures that the issue appears in the same stage of development on the Kanban board for the new project.
5. Define columns.
Each team identifies columns with the values that are stored in the CIDR Kanban State field.
This field is attached to the CLion project and the AppCode project, so they use it to define the columns for both boards.
The values in this field represent the stages in their development process. They use the stages Analyse, Develop, Review, Ready to test, Test, Merge, and Done.
Merge is a special stage where a task is ready but not yet published in the release branch. When the task is merged to the release branch, it moves to the Done column.
6. Set WIP limits.
These teams limit the work in progress for every column except Done.
The WIP limits are tuned according to the number of team members who work on each stage and the number of tasks they are comfortable working on in parallel. When cards in a column exceed the WIP limit, this indicates that there is a bottleneck in this stage of development.
7. Define swimlanes.
Here, the teams also use a dedicated custom field, CIDR Kanban track, to separate tasks into different streams. This field stores two values: Priority and General.
Priority tasks go on the top, and should be taken first.
8. Configure cards.
The teams use the swimlanes to indicate which issues need the most attention, but they also use the values in the Severity field to highlight cards on the board. This helps us see if there are any issues in the General swimlane that need to be moved to the Priority track.
9. Pick a chart.
They don’t work with the chart on these agile boards – the WIP limits help them to identify bottlenecks. The default chart option for a Kanban board is Cumulative flow, so it’s already set up if you want to use it.
10. Build the backlog.
Each of these projects use a saved search that represents the incoming queue of issues.
Each saved search sorts issues in a custom order. They use the custom order in the issues list to prioritize the queue.
This search query simply shows any issue that is unresolved in either project.
Serving Suggestion
Prioritizing issues in the queue is an important part of the process for both teams. The teams organize the queue during planning sessions and revisit the priority on a regular basis. Planning sessions occur after every major release. The teams makes a preliminary agreement on the priority for each task and who will take it.
The queue is updated when new critical issues or regressions appear, or whenever the teams just feel that the order needs to change.
Developers also have their own lists of things to do. The queue is simply a guideline. When developers choose their next task, they either look into the backlog for an issue in the queue or check their personal list.
On any Kanban board, tasks eventually start to pile up in the Done column. When these teams publish an EAP or release version of their product, they remove all of the issues that are included in the release from the board. The fastest way to clean up the Done column is to search for all of the resolved issues that were included in the latest release, for example, in: CPP version: {CLion 2017.1.1} State: Fixed and update them with a command. For example, the command to remove issues from the CLion board is remove Board CLion Kanban.
Secret Sauce
The CLion and AppCode teams use several workflow rules that automatically update values in issues that are managed on the board. The following workflows are triggered by events on the board:
1. When a user moves an issue to the board, the card is assigned to the current user. This workflow also assigns a card to the QA Engineer who moves it to the Test column. The assignee is not updated when cards move between other columns — these assignments are set manually.
2. When an issue is added to the board, the value in the CIDR Kanban Track field is set to General (if the field was empty). This workflow fires when a developer adds an issue to the board with a command or by setting a value of the CIDR Kanban State field in the issue itself.
This ensures that the issue is added to the correct swimlane. If the value in the CIDR Kanban Track field is empty, the card appears in the swimlane for uncategorized cards, which is not where it belongs.
3. When a card is moved from one column to another, changes are synchronized with the value that is stored in the State field. The CIDR Kanban State field stores values as enumerated types, not states. If the value for the State field is not synchronized with changes on the board, the issues are never moved to a state that is considered to be resolved.
This workflow sets the value for the State when the following changes are applied to an issue:
- When a card moves to the Done column, the state is set to Fixed. The issue is then considered to be resolved. If the card is currently assigned to the Priority swimlane, it moves to General.
- When a card is added to the board (meaning the CIDR Kanban State field is set to any value other than Done), the state is set to In Progress.
- If an issue is removed from the board (meaning the CIDR Kanban State field is set to an empty value) and an issue has the In Progress state, the state is set to Open. In this case, the workflow also removes the issue from the current sprint and sets the CIDR Kanban Track field to an empty value.
4. When a card moves to the Test column, the no testing tag is removed from the issue.
The team uses the no testing tag to flag trivial fixes. The developer and reviewer can agree that an issue doesn’t require testing and add the tag. However, if QA disagrees and decides it should be tested, the tag is removed automatically. When QA agrees to pass the issue without testing, the tag remains as an indicator that the fix was not tested manually.
Here is the workflow code:
5. When an issue moves to the Done column, the user is prompted to set a value for the Fix versions field. This workflow ensures that only tasks that are ready for release are moved to the Done column.
Note that this change isn’t actually triggered when the value for the CIDR Kanban Field changes. Instead, it is triggered by the workflow that synchronizes changes in this field with the value for the State field. This behavior is managed by the third workflow in this list.
Cook’s Note
As you can see, these teams follow a hybrid agile methodology. They call it ‘Kanban-inspired’. However, it works well for them, which again proves the main concept of any agile methodology: there are no strict rules to follow. Being agile means being flexible and ready to continuously tune your process.
If you are new to agile, and want to try a Kanban approach, we recommend that you start with a traditional Kanban practice. You can follow the setup that is described in our Kanban tutorial and tune it as you move forward.
Good luck with your Kanban transformation!
Subscribe to YouTrack Blog updates
