In Part 2 of this series, we will continue our journey within the developmental dynamics of the Barman open source project for PostgreSQL database backup and disaster recovery. After providing a small introduction to devops and Kanban in Part 1, let’s focus on the basic element of our daily management: The Boards.
Our Kanban boards
Our activities are managed on 3 different Kanban boards, one for the Dev group, one for the Ops group and one for marketing/sales/administration activities (Of course commercial, creative and other business areas use Kanban!).
Although there are software tools like Trello, Leankit, SwiftKanban and more that are capable of handling a Kanban board, we initially decided to adopt physical boards. This is also because, at the time, most of our team was in the same building and for those outside of Italy, we use the principle of the sticky buddy (a referent in the office is responsible for communicating the state of the board and moving post-it on behalf of the person working remotely).
The board is the fundamental element of Kanban.
Those who work as knowledge workers know very well how difficult it is to make visible what, by its very nature, is not. For example, developing a feature for a software, installing a PostgreSQL database, running a backup or recovery operation, verifying that the standby server has not accumulated too much delay, and so on. For Kanban, each activity is represented by a post-it, located on the board. The image below shows how we label our work item post-its. Ticket ID is an identifier that corresponds to an issue in Redmine, a great open source tool for collaborative development (which uses PostgreSQL as backend).
The number of post-its simultaneously on a whiteboard represents the amount of work currently being performed; referred to as Work In Progress or just WIP.
One of Kanban’s core principles and Lean systems’ is to limit the running work – in jargon “limit the WIP” – in order to speed up the delivery of the activities on the board, reducing Lead Time. We have decided to impose limits for each phase, and use a limited number of magnets to respect constraints.
Without wanting to go too far into “Kanban’s Utopia”, I would like to describe the boards currently used at 2ndQuadrant. I use the term “currently” because the boards and the ways in which we use them are constantly evolving.
Each of the 3 boards used at 2ndQuadrant consists of the following columns, identifying the various stages of the process. From left to right, following the direction of production flow of Dev/Ops boards:
- Backlog: Where the next activities/tasks to be worked on come together, with a specific priority
- Ready: Activities that become real commitments with the customer, both internal and external
- Analysis: Activities under analysis, design, planning, etc.
- Dev: Activities under development, installation, implementation, etc.
- Test: Verification, testing, review and quality control of an activity/task
- UAT: Final task verification by the customer, commonly referred to as Acceptance Testing
- Delivered: Activity/task is completed.
The analysis, development and testing columns are also divided into two additional columns:
- WIP: Activities currently being worked on
- Done: Completed activity waiting to be pulled forward through the stream
The “Done” column represents a queue (buffer) of activities ready to be pulled downstream through the production process.
I deliberately used the term “pulled” since Kanban is a pull-system in which the pace of work is determined by the availability of human resources in the next stages (and not pushed forward on the basis of a project manager’s orders).
So, let me give you an example: if Marco ended the analysis phase of a feature and put the post-it into “Analysis-Done”, the ticket is waiting for the first free developer. Let’s suppose Giulio completes his current activity and decides, once the priorities have been evaluated, to work on that activity from Marco: he will then take the post-it and move it to “Dev-WIP” and begin working on the task.
Independently and autonomously, without waiting for a manager’s direction (self-organisation is an important principle in Kanban).
Thanks to Kanban, we can quickly locate bottlenecks within the production process. How? Looking at post-it concentrations on the blackboard. Also, if there are too many post-it’s in the “WIP” phase, it means that that stage is too slow (and in itself, is a bottleneck). Alternatively, if they are in the “Done” phase, it means that the bottlenecks are downstream. By providing this information, a manager/leader can plan accordingly both in terms of training and staff recruiting activities.
What I find extraordinary, is that the entire process has been decided solely by the team. The team has decided the “rules” of the game, collectively – from the ‘bottom’, defining boards, columns, post-it information, post-it colors (depending on the type of activity), and so on. Nothing was imposed from above.
Conclusion
In the next article, the Part 3 of the series, we will follow Kanban’s role in developing a new feature of Barman, the “Super Feature”, and the release of a new open source version.