In Part 3 of this series (here are Part 1 and Part 2), I would like to demonstrate how the development of a new feature for Barman would flow through the Kanban board.
The Scenario
Suppose, as a team leader in the Barman project, one day I suddenly have the brilliant idea of adding the “Super Feature” functionality to Barman.
After speaking with the development team I create a post-it for the whiteboard, accompanied by a ticket in Redmine containing all the details of the task. I write the task ticket ID in the upper left corner of the post-it and then place it in the development board Backlog.
During the morning stand-up meeting (an informal meeting that takes place in front of our Kanban board with all the team standing. This is done deliberately so that it does not take too much time from our day!) I share with the team that I would like to set priority to the “Super Feature” and then move the ticket to the Ready column on the board, writing the start date in the bottom left corner.
From this moment on, we have committed, as a team, to bring this task to the front of our priorities.
Giulio, lead developer of Barman, follows through with his commitment and decides to volunteer to begin analysis and moves the post-it into Analysis-WIP on the board. Since he requires more information, Giulio arranges a brainstorming meeting, involving the entire team, including Ops.
At the end of the technical meeting, we have a clearer idea of what this feature should do and we have also asked that:
- Francesco (PostgreSQL and Linux expert, with passion for QA and automated testing) writes integration tests for the “Super Feature”
- Alessandro begins working on the documentation and the user interface (configuration and command line).
Two post-its will be created for these two tasks, and a clear dependency will be reported in Redmine and on the “Super Feature” post-it.
The analysis phase is over and the “Super Feature” post-it is now placed in the Analysis-Done.
At this point, Giulio begins to develop the code and moves the post-it into Dev-WIP. Once Giulio has completed his efforts and written the code, comments, documentation (along with Alessandro’s ticket) and completed unit tests and integration tests (including those just added by Francesco), the development phase can be considered complete and he can then move the post-it into Dev-Done.
Once the post-it has been moved, the task is now waiting a reviewer, which will need to be a different team member from the person who has developed the functionality and integration tests.
Marco, anxious to participate in the development of the “Super Feature”, offers to test and review the work carried out by Giulio and moved the post-it to Test-WIP.
Marco’s methodical, yet scrupulous, work reveals a small bug, originally missed by Giulio. Marco now opens a new ticket for the bug and asks Giulio to resolve it, explaining the reasoning and details of his discovery. The “Super Feature” post-it is temporarily put on hold in the Test-Hold column, and a dependency is placed on the ticket of the bug, on the post-it and in Redmine.
Bug fixing proceeds independently as a unique task, and when it is completed, Marco is able to resume his activity on the “Super Feature”, making sure that all tests are passed and moves the post-it into Test-Done.
With extreme satisfaction, I know that functionality is ready for my final review and verification. I pull the post-it to UAT and while reviewing the “Super Feature”, I start to see that it really does what I expected!
This is no surprise to me. Thanks to Devops key principles such as shared responsibilities and peer review, the self-organising team is autonomous and able to produce code in small batches and with high built-in quality. I must say that in most cases, my task is limited to being informed, taking a look at the code, and trying out the functionality.
The “Super Feature” manages to put into practice the idea I had and, therefore, with great happiness, I move the post-it to Delivered and note the end date of the activity.
I would like to point out that anyone can propose a new idea for Barman. The spirit of initiative is fundamental to a team and everyone must be free to express their creativity!
For statistic fans out there, the number of days between the start date and the delivery date is our Lead Time measurement for activities. By monitoring this metrics over time, by board and by type of activity, you can find interesting information about the company’s production process.
What does it mean to release a new version of Barman?
Each time we introduce a new feature in Barman, or open a bug, we initiate a stream of activities much like the one just described, using the Kanban board as a tool for coordinating activities.
Generally, every 3-4 months, based on new features collected and developed over the period, as well as bugs, we release a new version of Barman.
Our continuous delivery pipeline allows us to automatically test Barman for various PostgreSQL versions and on several distributions. At release time, all we have to do is wrap up documentation and coordinate with 2ndQuadrant’s marketing department for announcements.
Conclusion
In this 3 part series of articles, I wanted to explain and demonstrate our daily working habits. In addition to Open Source and PostgreSQL, we would like to contribute to the promotion of values inherent in the Devops culture, lean and agile principles, and Kanban’s application not only in the IT field – but all sectors.
With extreme certainty, I can say that the above methodologies have changed our way of looking at and completing work, based on the concept of a group.
It’s often asked what the key recipe is for successfully applying these work methods.
I believe that everyone should find their way, reading, studying, listening, opening to others, making proposals, accepting proposals, reaching compromises through the contribution of all.
As our dear friend, Dragos Dumitriu, always says, when I ask him the same question: “In the end, it’s just about applying common sense” – even though, in my humble opinion, this consideration has the high risk of being very subjective.
Finally, I would like to leave you with a couple of analogies/metaphors between team sports, music and devops – you may then notice similarities in your own life as well.
Starting with sports, I have practiced and taught football (soccer – for those of you in the US 😉 ) for many years. Working in a team is like the team of our favorite sport (football, rugby, basketball, volleyball, cricket, hockey, etc.), where everyone carries their own psycho-physical characteristics and skills in their respective position that they can play best on the playing field, but they put them at the disposal of the whole team. Each putting the interests of the group in front of their personal interest, but all with the common goal of winning the game together as a team.
I also love playing guitar and I am currently learning blues music as a hobby (I’m a beginner). I play in a band and I also love to play in blues jam sessions with people I have never played with before (I am just starting to appreciate this). As a result, I see lots of similarities between playing in a band (either my regular band or an impromptu jam band) and being a member of a Devops team. Just to name a few: respect, shared goals (deliver “feelings” to the audience), listening capabilities, initiative and creativity (think of improvisation in blues), passion, and autonomy. Prior to that: experimentation and practice to develop technique. These are all common traits I see existing in both of the two worlds.