Hello! My name is Vitaliy Doshchenko, I am New Business Director at Imaga. In this article I will tell you about our small but cool invention — Imagaban. We avoided a lot of headaches thanks to this development management system.
- We have been making websites, apps, and ERP systems for large businesses for 16 years. We are often connected to projects not from scratch. Sometimes we do only part of the work, sometimes we work in cooperation with other teams, and sometimes we develop entire products for the customer on our own. And in this case, it is us who connect contractors.
- Working in this style is challenging since every new project's procedures are constructed uniquely, and sometimes there is no system in place. Therefore, for several years, we carefully documented, changed, tested, and implemented all of our processes on new projects. We eventually came to the realization that it appeared practical. This is how Imagaban was born.
I'm exaggerating when I say that we invented it. Its foundation is the well-known Kanban method, which we customized for the demands of custom development. Because of this, discussing Imagaban will be ineffective if we do not remember the main points of the Kanban approach.
And when we remember, I’ll tell you what we added and what benefits it brought to us and our customers.
- Spoiler: Features are now delivered to production much faster, and the processes are now much clearer. Therefore, if you manage an agency, you’re welcome to copy some of our ideas.
Recall the Kanban practices
If you are an expert in Kanban, you may just skip this section. I'll provide a general introduction right now to explain how we came to Imagaban.
The Internet is full with lists of the Kanban method's characteristics, but it's crucial that we review its fundamental principles here. There are six of them:
Let me dwell on the last point in more detail. It holds the key to understanding Imagaban. Let's look at an example:
- Company X has many customers. Each project has its own manager. And in each case, this is a separate process with its own regulations, rules, and rituals. This process is evolving and becoming more convenient for everyone. And then, bam. The project is over, and a new one has begun. All processes have to be built from scratch. Evolution has been set to zero. This, we determined, was not for us.
We have implemented a system where the process evolution is not reset on every new project. It was given the name Imagaban, where ban is short for Kanban and Imaga for us, because such processes are convenient for us.
In fact, we've "kanbanized" the whole production process. Moreover, Imagaban is the most effective when used to build products that take a lot of time to develop. For example, the pet care app. This is a service that can be constantly improved.
What is Imagaban made of?
I'm going to use my trump cards. Three distinct Kanban services with boards are the key feature. We examined every task we had and found that it was safe to divide them into three groups: Management, Requirements, and Features.
Project managers and stakeholders often work on this board. This service powers the other two. It increases development efficiency and is responsible for the very evolution I mentioned before.
The guidelines for starting new projects, client service meetings held quarterly, and team retrospectives are where tasks are brought to this board. Tasks like "sign an additional agreement", "agree on PR", "find another designer", etc. may be found here.
The Management service focuses project managers on solving infrastructure problems so that they do not become a blocker for the rest of the team.
This is a requirements board; analysts work on it: business, system, and product analysts; team leaders; architects; designers; copywriters; editors; and managers.
This board's very existence is significant since task formalization cards follow their own cycle and arrive at the development board fully prepared. Development does not stop because some requirements need to be clarified.
When the requirement is ready, it goes into the Ready for Coding column, and the specialist puts the date of its implementation in production. At this stage, it is very important to carry out architectural supervision, improve an already-released feature's quality, and compare it to the requirements, design layout, and technical specifications.
Developers, testers, team leads, and everyone who is responsible for specific features work on this board. There are only technical tasks that are completely formalized and specified.
They are divided into three priority groups:
- We occasionally hear the belief that a developer would complete a task more quickly if he begins it sooner. Experience has proven the opposite: if a developer takes on a raw task, he has questioned every now and then. It may be challenging to respond to them. Everyone has already forgotten where the task came from, what its importance is, and why the deadline is so important. The essence of the three boards is that each task was validated, described in detail, thought over, and only then put into production.
The so-called Commitment Point happens when a task is moved to the To Do status on the development board. This means that the company undertakes to complete and hand over the task as quickly as possible. The task's completion deadline begins to run from this point, not when the manager discusses it with the client.
Yet another crucial element. All the tasks from different teams flock to the boards of department managers according to their types. For instance, the head of the analytics department sees all analytics tasks on his board. This allows him to optimize the production process.
Regulation and documentation of the process from and to is Imagaban's second crucial component. We have almost no processes left that we have not thought through and described. And all the regulations are divided into checklists that do not let us forget about anything.
There are two types of checklists:
You can attach the following lists to each task in our task tracker:
You can attach the following lists to each task in our task tracker:
It's a checklist on the requirements board, attached to some of the designer's tasks. The task will not be considered finished until all the checkboxes on this list are checked.
- For instance, whereas before we frequently forgot to draw error pages, this is now impossible. The task will not be considered done, and it will not be possible to pass it further along the cycle. Another example: the task after formalization must be validated by the customer and the team leader. We will not tick the box if the team leader feels that the details of the task are not enough. This means that the task will not go into development. These checklists cover almost all tasks.
All checklists are carefully kept in our knowledge base. A project manager or line manager can quickly validate any task by simply going through the list in the wiki or task tracker. If something is missing, we will immediately notice it thanks to the checklist.
Here is an example of a checklist for creating a design concept.
We regularly modify or supplement checklists if anything is missing or not functioning properly. Retrospectives, other regular meetings, and metrics help with this. We analyze the process all the time to understand how to improve it. This is one of the Kanban method's practices.
How we work with boards
Each column on the board in any of the services represents a separate stage in the accumulation of knowledge about the task. The more right the ticket, the more knowledge has been accumulated on it. Tasks can only be moved from left to right.
A task cannot fly back, even when a tester returns it for modification. Instead, it stays in the same column, therefore we construct a Fix type subtask for it. This is a crucial requirement of the Kanban method: the task has passed through the board and accumulated information, and we cannot reset this process. Exceptions to this rule are rare and only if a mistake has been made in the process.
The main markers and marks that we use are shown on the scheme:
We name tasks on the board in a certain way:
[practice/function: component] + feature name.
A practice/function is most often the artifact we are working on: API, technical specifications, layout, etc.
A component is an element of architecture: iOS, Mobile, Web, etc.
Our tasks on any board look something like this:
This allows us to quickly find any task in any of the services.
How do we control quality
For example, we are developing a large pet care service integrated with various systems. On the client side, there is no one from the technical team, only product managers are on their side. They interact with us like a black box; they do not fit into the code itself. And we justify the quality of our work with numbers. This is how we increased the Lead Time.
The graph shows that in the vast majority of cases we solved all the tasks that fell into the "to do" list of the client within 14 days. Most tasks are solved faster, but in 85% of cases, all tasks fall into this window. This suggests that we can subscribe to such an SLA for delivery. The system's real performance, not our illusions, is to blame.
Why we love Imagaban
The simplest response is that we created it. However, everything is actually far more fascinating.
What Imagaban gives us: