Tell me… “what are you working on, really?”. This question is quite redundant for a team working on a project with an organized flow in kanban, everyone should know by now!
But after all…
What is Kanban?
It is a visual method in agile methodology used to manage and drive work. Its proper use can maximize efficiency, reduce time to deliverables, and give an overview of what is being done.
If you think this is new to software teams, you are wrong! Kanban is old for *, it was created in a Toyota factory in 1940 by Taiichi Ohno, an engineer and businessman in Japan. He drew inspiration for kanban’s agile methodology from the way supermarkets organized their shelves ( a story for another time).
The agile methodology is put into practice with scrum and kanban. The principles of these 2 models are the same, but the way they work is different:
- Kanban serves to visualize work, limit work in progress and maximize efficiency. It is a process for constant improvement in the flow and quality of work.
- Scrum is the practice of working at set intervals, also called “sprints”, with the aim of quickly gathering information and feedback and implementing it at work.
This Atlassian board clearly defines the differences in working methodologies between scrum and kanban:
Kanban in practice
Using kanban is easy (and a relief for perfectionist people like me!). As it is all visual, physical or digital boards are used. I recommend two Atlassian software, Jira or Trello. These frames have some main components:
- Columns or lists of states
- Task cards, bugs, improvements, features, epics, stories, …
- Responsible
- Deadline
One of the simplest and most common kanban (card states) workflows is: “To Do”, “Doing” and “Done”, and any additional lists depending on the complexity of the project. But here I will advise you to use two frameworks, one called Demands aimed at a view for product owners, stakeholders and customers (for macro deliverables) and another called Developers with a technical or executive view (for micro deliverables).
Demands
The purpose of this framework is to have an inflow of ideas (upstream) and an outflow of macro deliverables that are of interest to the customer. Understand each column:
- Pool/Queue: Concept brought from upstream kanban, this is a place to put any idea for the project or product and can be contributed by anyone (customer, PO, dev, user, etc). This is where the screening of ideas begins to be funneled into deliverables of value for the business or jobs to be done.
- Backlogs: Not always each card is ready to go into development by the team, there are backlogs with external teams, suppliers or the client itself. For this there is this column, and here there must be someone responsible for ensuring that there is no bottleneck and the flow happens in an agile manner, ensuring continuous deliveries. E.g.: Release access to the database, receive configuration data from the client, etc.
- To Do: Here is the prioritized backlog (in scrum this is done by the product owner), and this is where you can find what will go in faster as delivery. It’s what generates the most short-term gains for the customer and should be focused on immediately. This list is where the scrum master should look for tasks to assemble the sprints.
- Doing: The cards in this column are linked to those in the Developers board (this can be done via “Board Settings” in Jira, in the “Columns” menu), as this is actually where they are handled by the execution team. In other words, what is here is what is currently being done (current sprint).
- Done: When the task has been reviewed and approved, it is moved here! You can celebrate! Your team is rocking the completion of tasks. 🎉 Deliverables in this column are those reported to the customer in delivery meetings. After this report, they are put into a state of “Closed” and disappear from the views of the two boards.
Developers
Since the Demands board is responsible for the input and screening of demands (upstream), the Developers is responsible for the downstream or output of deliverables. But beware, the lack of balance in upstream and downstream capacities can be detrimental to the value chain as a whole, everything must be fluid for continuous delivery.
Some examples of Developers boards:
Reminder — The main purpose of the kanban method is to keep track of work in progress. This means that the team must only perform a few tasks at a time on a given project. By limiting the amount of work in progress, the entire team can easily identify which tasks need extra help or additional time to complete. Atlassian’s agile coach explains:
“The work-in-progress cap improves productivity and reduces the amount of ‘near-done’ work by forcing the team to focus on a smaller group of tasks. At a fundamental level, the work-in-progress cap encourages a culture of ‘ done.’ More than that, this limit makes obstacles and bottlenecks visible.”
Conclusion
The goal of the kanban methodology is for people and teams to work without overload… It’s difficult to distribute responsibilities in a balanced and transparent way if your team doesn’t have an overview of the entire process and is isolated in communication bubbles like emails and documents.
This article is a suggestion on how to work in an agile team in an organized way using Kanban, but as Scrum itself suggests, everything can (and should) be adapted to your environment in order to bring you the best benefit. If you’re looking for a new way to raise your team’s productivity levels, or if you simply want a better way to organize your personal projects, go for it, kanban is for you!
Sources
- https://blog.trello.com/br/metodo-kanban (accessed em 03/12/2020)
- https://medium.com/@raphaelbatagini/upstream-e-downstream-no-kanban-d0d02c56f6b6 (accessed em 03/12/2020)
