Sold the IT company REG.RU and “retired” to Samara University, taking flexible methodologies and Kaiten with him
My name is Valery Studennikov, I am a programmer, and the pinnacle of my IT career was the company REG.RU, where I was a co-founder, technical director and development manager.
Over 10 years, REG.RU became No. 1 in Russia in terms of the number of registered domain names, and then entered the top three in web hosting and VPS. In 2021, my partner and I sold the company, I “retired” and since then I have been teaching at Samara University, teaching students various IT subjects.
It was at REG.RU that I began to actively use flexible methodologies and first encountered Kaiten, and it so happened that I took both with me and now use them in my teaching activities. Actually, that's what I want to talk about.
Company growth and “agileization” of REG.RU: from a bug tracker to Kanban
Since the foundation of REG.RU, we needed some tool for organizing tasks. The budgets were small at first, so we didn’t want to spend them on paid tools like Jira. Then I decided to take an original path — to use the free bug tracker Mantis (mantisbt.org), written in PHP.
Although this tool was not originally intended for task management, we managed to somehow customize it and adapt it for this purpose. Its main advantages were:
lightness,
fast working speed,
intuitive interface.
Moreover, my partner and CEO of REG.RU was so fascinated by Mantis at that time that he decided to use it in his other business, the CETIS web studio. They even assigned a separate developer to rework Mantis to suit their goals and objectives, and eventually built their entire workflow around this tool.
We seriously tweaked Mantis to suit our needs: added support for parent/child tasks, “formulas” for prioritizing tasks based on some “objective” criteria, not someone's subjective opinion. We even started making a visual board as a third-party web application, in which tasks from Mantis would be visualized as cards.
However, time passed, REG.RU grew, and with it the volume of tasks, the number of programmers and departments in the company. At some point, the development began to stall, not keeping up with the new wishes of internal customers and the rapidly changing business.
In particular, there were difficulties with prioritizing tasks. Since there were clearly more tasks at the input than the development department could “digest”, it was necessary to use various crutches:
ubiquitous deadlines. And naturally, priority in setting deadlines was given to those departments and managers who had more “administrative resources”;
“Schindler's List” — that's what we called the priority pool of tasks, which was periodically approved by the top management. It is clear that all internal customers wanted to get into it, but not all of them could. And outside this “white list”, the start of task execution could be expected for a very long time.
It was 2017 and we needed to change something in our work.. After several managers went to Agile Days (before that, only I had been there), it became clear to everyone that we needed to “agileize”. We also decided to establish full-fledged work with the product. So we got a product department and several product managers for different sub-products: domains, hosting, internal support tools, etc.
It was decided to implement Agile development processes. At that time, the Scrum fashion was beginning (and for some, it was already continuing), and companies like ScrumTrek began to work actively, helping companies implement this development methodology.
We also launched several Scrum teams with the help of external consultants: “New Personal Account”, “New Workplace for Technical Support Employees”, and then, after some time, other teams: “Cloud VPS” and “Cloud GPU”.
However, Scrum is still more suitable for new products, when “everything is new and nothing is clear.” The majority of development teams were already doing mature functionality, and Scrum was not well suited for this.
For the majority of teams (and subsequently also for all departments of the company, including HR, PR and marketing, admins, etc.), we decided to use the Kanban process (although, strictly speaking, Kanban is not a process, but a “process improvement method”).
Kanban is universal, suitable for almost any team and activity (not just software development) and allows you to optimize almost any process. At the same time, what is important is that Kanban can be implemented step by step and evolutionarily, unlike Scrum, the implementation of which is always a “revolution”.
This is where we needed a tool for online Kanban boards. At that time, several of our teams were already working on Scrum, and a whole “zoo” of task managers began to grow in the company, including a redesigned Mantis, Jira, and other tools.
We reviewed a number of popular options, but they did not fully meet our requirements – they did not support Kanban well. Jira at that time was very overloaded in terms of UI, quite expensive and very far from Kanban. Or, for example, SwiftKanban is, formally, a tool for Kanban, but, to quote one of the employees: “it was extremely poor, it looked worse than Mantis” (at that time, perhaps now everything has become better).
Fortunately, at one of the conferences in 2017 we heard about a relatively new domestic tool – Kaiten. It hadn't been launched for long, but it seemed promising to us. And most importantly, we had established contact with the developers of this tool, and they were ready to adapt Kaiten to our needs as potential large clients. And they also offered us a good discount.
As a result, Kaiten cost us an order of magnitude less than competing products, despite the fact that its functionality for Kanban was head and shoulders above (in particular, a large number of useful graphs and statistics).
And so the large-scale move to Kaiten began.
At that point, we became the largest users of this online tool, several times larger than the largest clients they had in terms of users, boards, and tasks.
Of course, it was not easy at first, the tool slowed down a lot under our load, considering that almost ALL departments (except perhaps accounting) switched to this online platform.
However, after several months of very close interaction with the Kaiten developers, all the “childhood diseases” were cured, and we finally learned how to use this tool effectively.
In parallel, large-scale organizational work on “agileization” was carried out. An entire department of flexible methodologies was created within the company, which helped implement Agile approaches. A lot of internal trainings and seminars were held, and the guys from this department periodically mentored other teams that needed help with transformation.
In the end, everything worked out and REG.RU got hooked on flexible methodologies in general and Kanban and Kaiten in particular. The work of all departments, including development, was significantly streamlined, all products, both internal and external, now had product managers, clear prioritized task lists and transparent criteria for taking initiatives into work.
Happy ending. And then the second episode.
Active pension and Samara University
In the fall of 2021, my partner Alexey Korolyuk and I sold the company to new owners. Alexey Korolyuk took on several new projects and wrote a couple of books.
I decided to take a temporary break from development and implement a “social mission” in the field of education in my native country. Samara Universitywhere I graduated in 2001. At that time, the level of programming education there was low, and I promised myself that I would return there as a teacher someday to improve this situation.
I created several original courses for the university before 2021. And after selling the company, I decided to dive into teaching more deeply. In 2022, I was offered to create a course on software development management. I agreed. The motivation was, among other things, to better understand this subject myself, summing up my experience in managing development at REG.RU. To further improve, I took a couple of specialized courses: Kanban from Neogenda and team management from Stratoplan.
I consider myself a practitioner, not a theorist. It is best to learn any business in real conditions – a relatively small amount of theory and a maximum of experience with real projects. This is how I decided to build my course “Software Development Management”.
As part of the course, students must split into teams, choose any IT project based on any technology that interests them, and work as a team on this product during the semester, using various development methodologies and practices: Scrum and Kanban. The course also includes a large block of theory and practice on “Product Management”, including several team assignments related to product development: research, CJM, product metrics, unit economics, Lean Canvas, etc.
Judging by anonymous surveys after each stream, the course is well received by students, some write that “it was the most useful subject ever”. Based on this course, we also created a digital department “IT Project Management” so that all interested students could take the course, not just IT students. As a result, several hundred people have already completed it in 3 years.
What is especially pleasing is that upon completion of this course, students receive a fairly significant line in their future resume. Their training on real projects can be almost equated to working in a company for six months, and this gives quite a lot of “experience points”.
What does Kaiten have to do with it?
And Kaiten plays one of the first violins in the training within this course. Since it is perfectly suited for both Scrum and Kanban, and almost all students use this board in the process of work:
Students first work through the Scrum process, and Kaiten has all the features needed for this, including a Velocity Chart and Burndown Chart.
Then they switch to the Kanban process, where they need the maximum number of Kanban metrics and charts to find bottlenecks based on this information and optimize the team's work process. And all of them are also in Kaiten: cumulative flow chart, control chart, spectrum chart, blockage resolution time, flow throughput, cycle time, etc. With their help, you can easily find bottlenecks that slow down the team's work.
Although I don't limit students in any way in tools and they can use any other online boards, every semester the same thing happens: after switching processes from Scrum to Kanban, one of the teams that does NOT use Kaiten writes: “Oh, but we can't conduct a service review, perform such-and-such tasks, our tool does not have the necessary graphs and analytics.”
All that's left is to throw up your hands every time and write: “I told you that Kaiten is better suited for Kanban, you should first check that your tool has the necessary functionality”… )))
Call to action
They say that any good article, except purely analytical ones, should have a “Call to action”. So here it is: “Use Kaiten!” 😉
First, it works great with both Scrum and Kanban.
Secondly, in terms of the completeness of the toolkit within Kanban, it has virtually no equal. Almost all the online boards we know were created either as a “Prioritized Task List” or as a Scrum board, where Kanban features were later added. Kaiten was initially created as a powerful tool for working with Kanban. This is especially true for the availability of various charts and board analytics, which is very important for optimizing your Kanban process.
Thirdly, it is a domestic product, protected from any sanctions, with technical support in Russian and the ability to easily pay from Russia.
And, no less importantly, Kaiten's management is flexible enough (as are agile methodologies), open to dialogue and ready to meet its clients halfway, implementing their wishes.
So use Kaiten for both commercial and educational purposes.
