This article could have been born about a year ago – that's when the PVS-Studio team decided to try agile. However, we wanted to experience it hands-on before we told the world about it. Aside from introducing agile, we decided to switch from Bitbucket to a new task tracker. We also wanted to upgrade many of our internal development processes. No time for an article!
By the way, there will be a part two about changing task trackers. So do look forward to that! But let's return to the subject. In this article I'll talk a bit about our company's history and explain why we decided to incorporate kanban. I'll elaborate on why we chose this management method and which technical and administrative difficulties we struggled with when implementing kanban. I hope the experience I share will help companies who are yet unsure whether they need kanban.
I'll touch briefly upon project management, but I do not want to delve into theory too deeply. This article is for one who knows the concept of kanban. If you just heard something about kanban but don't know its purpose, I recommend learning more about it online before continuing with this article. There are many informative resources that cover the kanban theory in-depth. Read them and come back here to see how it works in real world.
When reading what others write about project management, I feel respect. All these articles are cool. The authors skilfully use concepts, review practical cases, and successfully sell their ideas to others. Such articles inspire me and make me want to incorporate all these "best practices" into our workflow right then and there. But we all know about the gap between theory and practice. Theory often keeps you in the dark about practical difficulties related to integrating advanced technologies into existing workflows. This includes the lack of resources, unqualified leaders, an immature or inflexible team. So, our way towards agile was challenging, but exciting.
A Little History
The PVS-Studio has been on the market for over 10 years. All this time we've been developing the PVS-Studio static code analyzer. More details about this are available in the following article: "PVS-Studio project - 10 years of failures and successes". Thus, PVS-Studio is a one-project company. And this project is for developers. However, within the company, we have several components that are equal to development. We track the activities of marketing, sales, internal internet projects, administrative and IT office support. So, we have an intense flow of miscellaneous tasks that we need to manage somehow.
Before switching to the new tracker, we used Bitbucket. Our employees created the first task there on June 30th, 2014, and the last one – on February 5th, 2021. That's about the time we incorporated the new task tracking tool (you'll learn about it in part two of this article). Our team created 5 527 tasks in Bitbucket over that time period. Before Bitbucket we used another tool, but let's not dig this deep into the past. The new tasks approximated to 3.3 per one working day (assuming 250 business days per year and 24 business days per month). Let's round this number, while remembering that some tasks did not reach the "Resolved" state. In total, our calculations showed three new tasks per day, for about 30 employees (from 2014 till 2021 the company's staff doubled: we went from 20 to 40 employees). We can probably assume the team also closed approximately three tasks per day. I do not think this number's analysis means anything. This number cannot tell us anything about how many tasks each employee is working on at once. This is the value we could really use. However, to get this value, one needs to experiment and use a specific tool. I will talk about it further on in the article.
Just above, I mentioned our team's growth. The team growth intensifies task flow and complicates project management. Other factors, for example, project structure and variety (that also applies to us), technical complexity, leadership proficiency, employee skills, also have an effect on the task flow. However, with everything else being fairly equal, the team size is of critical importance. No, we haven't had to hire many employees at once. Neither had we opened a new department from scratch and hired an entire team for it. So, we could always take our time to get ready and plan everything in advance. However, it's the team growth that prompted us to analyze the current company structure and look for a better project management strategy.
The company's gradual growth slowly led to a typical problem other companies face: "It worked fine a year ago (as in, it was enough), and now it does not work anymore (as in, not enough)". This included everything: the office area size, the number of soda cans in the fridge, the maximum available processor threads on the build server and so on. Same with managing projects and people. Not so long ago we did not seem to need regular one-to-one meetings. To promote developers, we used the "looks like they code well enough" notion. Requests to return a task to the kanban backlog could have been regarded as inept trolling at best. I do not want to exaggerate the problem though – all that was a normal growth situation. Nevertheless, I think that in such cases, the team's and the company leadership's readiness for change may define the business's success.
So, the company grew, boosting the task flow. What issues did we face? The main problem was the strongly centralized development process. By the end of 2019 the chief technical officer controlled development at all levels. Teams operated without team leads. Tasks' life cycle was also unclear. Work efficiency was hard to monitor. The result was difficult to predict. At that time, PVS-Studio had about 34 employees: marketing, sales; C/C++, C#, and Java development teams; DevOps, administrative staff, leadership. About half of the staff was directly involved in development.
Historically (my favorite word), our development teams were self-organized. This worked for a while, but then the teams started growing. With no team leads, the company's leadership were getting an increasingly vague understanding of what the teams did. We could see a few informal tech leads and potential team leads, but we had no idea what to do with them.
Our developers wanted for transparency as well – barely anyone knew what the neighboring team did. Even developers within one team would get confused from time to time. That's when we saw we needed a new modern tool to manage work, development, and people.
How We Picked a Tool
Obviously, one new approach could not fix all the issues we had. That is why we simultaneously started to adopt other changes: we introduced a salary grade system and split up teams into sub-teams. Each sub-team is assigned a work scope. Then we rotate the sub-teams amid the scopes, from one release cycle to the other. We started to look for and identify strong leaders. We also pushed the leaders who questioned their own ability to lead. We also needed an efficient task tracker: the tool we used at the time (Bitbucket) could not handle our workflow anymore. We scheduled switching to a new tracker as a second step. First, we needed to choose and implement a new management method.
We intended to switch the active workflow to a new tool. So, we needed a friendly setup that satisfied the following criteria:
easy transition. We expected the team to show natural resistance, so we wanted to introduce new practices as painlessly as possible.
a short adjustment period, quick results. We wanted the process to be quick so that it didn't get too tedious for the staff;
easy-to-use, can be supported internally;
flexibility. Capacity to accommodate all our tasks, even those not related to development. Lots of wiggle room for the future;
transparency, viewable progress monitoring and task flow management. Years of working with flat lists proved their low efficiency. We wanted to have a visual tool that depicts how tasks are distributed among work areas and assignees. This allows to quickly identify problem areas;
a complete up-to-date workflow picture is available at any time. This feature would help us manage work, development, and people – and would take the company to a new level.
After some consideration, we accepted the kanban method as a general direction and philosophy. We were choosing between kanban and scrum. The idea of short sprints could not accommodate our workflow: we are developing only one project and we are used to working within one release cycle (two months). After the release cycle we look back and evaluate the results. We also have urgent tasks that need to be done right then and there.
Incorporating scrum would have required significant workflow changes. When integrating kanban, the first thing you do is describe the processes you have. You do not need to make any changes. This was kanban's advantage for us. Only then you start refining your processes. These principles make the integration smooth and help the team adapt quickly and painlessly.
In fact, we've used many agile principles before. We've held daily meetings, although not in all teams. Our teams were fairly self-sustained, and developers were responsible for the result. Developers also had some freedom when choosing tasks. For example, they could be writing an article and working on a development task simultaneously. They could plan their working hours as they like. Any employee of any level could create and assign a task to someone else (matrix structure). Finally, we had some semblance of sprints, tied to release cycles.
We were missing structure and rhythm when working with tasks. We also lacked strictly detailed rules and requirements. We needed them written out and accepted by every participant of the process. "Balance and communication" – this is technically our team's motto at the moment. It is obvious that kanban is best here.
Covert Kanban
Now that we've gone over the company's background, it's time to talk about our first kanban board. Let's think back to December 2019. At that time, we did not have a tool that could accommodate an electronic kanban board. So, we bought a white board and lots of color index cards. A material board has its own advantage: it allows to physically touch the workflow.
For a while we kept the board secret. We locked it in an office and only a narrow circle of leaders had access. The leaders intended to keep it that way until the kanban board layout and workflow were finalized. If you think (as we did at first) that establishing a kanban board is easy, then here is how the process went for us:
it took us a week to design the board's initial layout and the cards. We chose the classic board as the best option. The columns represented production stages, and the lines – specific assignees. A separate column contained backlog tasks. We also had a small "trashcan".
our first version of the board included the following columns: Backlog (a shared task pool), Assignee (a responsible employee), On hold (an employee's task backlog), Analyze (tasks being researched), In progress (tasks currently in progress), Check (finished tasks to be reviewed), Done (completed tasks);
the card's layout looked as follows:
we spent some time picking an adequate WIP (Work in progress) value for an assignee. It seemed logical that a person could not be doing more than two tasks simultaneously. To start with, we set the limit at three, because developers could also be doing tasks unrelated to development. For example, they could be writing an article and efficiently combine it with development. This approach is classic for kanban. First, the team evaluates their workflow and makes an estimate. Then the value is calibrated during the work process. The entire kanban system is always an experiment, whose goal is to minimize the WIP value. :) Spoiler: eventually we set the WIP value at 2;
after we lined the board and placed our cards there, we found out that markers do not do a good job lining the board. When we moved cards, we kept erasing lines accidentally. So, we had to take down all the cards and line the board again – but now with thin green tape.
we spent a couple more weeks finalizing the board's layout. We added a separate line for those Epic-level tasks that did not have an assignee. We reduced the "Done" column width and widened the backlog column. Between "Check" and "Done", we added the "Waiting" column. It accommodated tasks that were waiting for a client's reply, to be translated, or for something else. We decided to use different color cards for different task types: a task, a bugfix, epic, an article etc.
any changes to the board were discussed, and the discussions were often quite heated.
eventually we ran out of space on the board because we hired a few more developers. We resolved to purchase a two-sided board in the future, but only after we made it public.
the board required daily work. We spent approximately half an hour every day syncing the board with the task tracker.
After a little over a month (this included winter holidays), in January 2020, we announced the board. The photo below shows one side of the board, it does not include the C++ team.
Kanban to the Masses
Professional literature provides you with many ways to use kanban boards. Mature teams can use kanban boards and take (pull) tasks from the backlog unsupervised. The backlog contains tasks the leadership choses during meetings. Thus, the leadership members act as customers that request certain changes, while the developers are responsible for moving cards on the board. This approach is fully consistent with the kanban philosophy, where the emphasis is on self-organization and balance (unlike scrum, kanban does not require a scrum master).
Teams like ours, just starting out with kanban, are still advised to choose an employee who keeps the board up-to-date, organizes meetings and discussions at the board, and makes sure others follow the kanban rules. This approach also reduces possible negative effects a team may experience when switching to kanban. Additionally, we resolved to hold a big kanban meeting every release cycle (every two months). During that meeting, we would update the backlog and analyze the kanban board's efficiency.
Then we presented the board with up-to-date tasks to the employees and placed it in the conference room. Previously, we did have "daily" meetings, but those were sporadic and not always daily. Now we determined a schedule. Each of our four development teams (C/C++, C#, Java; DevOps) were to meet every day. Each meeting could not last over 15 minutes. We also had a marketing board. It was independent and differed from the main kanban board, but still fit into the kanban system.
As we expected, the team showed some resistance, but their problem was not the board, but the daily meetings. The main question we kept getting was: "Why do we need these meetings? We know who does what within the team. We have our daily discussions. It's just a waste of time. And then this board, too". Now that we've worked with kanban for over a year, we feel like we can answer these and other questions.
We quickly realized that the kanban board is a perfect place to meet. These meetings are intended primarily to help each developer. Team members talk about what they did, look at how they organized their work, and see what they missed or misunderstood. This helps them analyze their work and take responsibility. This information is also useful to other teammates and the team lead, but this use is secondary. The board shows the task flow for the entire company, not just a particular developer. This helps each developer understand whether the load is okay and what to do next (the buffer and backlog are available). The board also shows a stack of cards in the "Done" column, allowing developers see physical results of their work. Our experiments showed that this indeed does work.
We kept telling our developers that they were the ones who needed the meetings and the board. Of course, the board also helps the leaders make decisions. Identifying bottlenecks is the board's obvious benefit all experts write about. The team quickly eliminates problem areas and off-loads employees involved with too many tasks. A less obvious benefit is identifying low workload or a tendency to choose "convenient" tasks. This means, sometimes an employee would take too few tasks or choose interesting tasks in place of important ones. Such anomalies are easy to miss when analyzing a classic task list. They do not stand out in the company's workflow.
While we were using the board, I noticed our technical processes adapt to the kanban system. Right now, we can't imagine working without it.
Such Is the Way
Unfortunately, we worked with the physical kanban board for only two release cycles (four months). Then, in spring 2020, due to COVID, we sent our teams to work from home. Thus, our physical kanban board was unavailable and that negatively affected our daily meetings. When a tool is gone, and you start missing it – that's when you know it's useful.
It was around this time that we started contemplating the electronic kanban board. For a while, the situation with COVID was unclear, so we met online in Zoom. Each participant used the Bitbucket task list to report on the progress. This was inconvenient. It complicated our workflow that already was negatively affected by going online.
In the fall 2020, it became clear that the remote work is here to stay. We decided to act more radically. Instead of just employing a virtual kanban board, we decided to replace our task tracker entirely – with something that satisfied our requirements. At first, we, of course, looked at Jira. Switching to that system meant an easy transfer of all tasks from Bitbucket. We also looked at one more system – YouTrack. It appealed a lot to our C++ team lead (hey there, Phillip). Moreover, in summer, Phillip presented this system to our leadership.
As a result, we've made a choice by December 2020. We decided to switch to YouTrack. I'll talk more about how we switched to this tracker in the second article.
Conclusion
Over the last year, we gained better control over the task flow at all levels, got a better understanding of the tasks' lifecycle and employed convenient tools to track activity. We made the workflow more rhythmic and efficient. Kanban fully met our expectations. We achieved the goals we set at the beginning. We've done a lot, but still have a long way to go.
What would I like to say about agile and kanban from a first-hand perspective? Don't afraid to experiment! These systems are flexible, friendly, and forgive mistakes. They make change possible. They allow change to be painless, and even – in some cases – secret. If you fail, you don't lose much. If you, like us, decide to introduce a new management system from scratch – the benefits will surely outweigh the costs.
Thank you for reading and see you in Part 2.