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:
- Visualize the work process. Each process member should follow the tasks' progress on the Kanban board.
- Make agreements clear. Everyone should be aware of who is in charge of what, there should be no "no one's" tasks.
- Limit the amount of work done simultaneously. The rush slows down the process.
- Manage the task flow. Not people, but tasks on the board. Consider how to improve or simplify the process each time.
- Hold cadence meetings. The same meetings set the pace for work, allow you to collect feedback on time and solve problems.
- Evolve. Everything complex is an evolution of simplicity, so the process needs to be constantly improved.
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.
✔️ Management
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.
✔️ Requirements
This is a requirements board; analysts work on it: business, system, and product analysts; team leaders; architects; designers; copywriters; editors; and managers.
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.
✔️ Requirements
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.
✔️ Features
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.
✔️ Features
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:
- Urgent: bugs on released version, work delivered by CEO, etc.
- Tasks by the deadline: For instance, due to the publication of a new law by the Central Bank, some tasks must be completed by a specific date that cannot be changed.
- Standard Service: Tasks that are done on a first-come, first-served basis according to WIP limits and team bandwidth.
- 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.
Exhaustive checklists
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:
- DoR (Definition of Ready): the conditions under which the task can be taken into work;
- DoD (Definition of Done): the conditions under which the stage is considered completed.
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:
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.
[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:
- [Backend: Mobile] Replenishment of balance.
- [Frontend: Web] Main page.
- [Design: Mobile] "Card Account" screen.
This allows us to quickly find any task in any of the services.
How do we control quality
- We collect statistics on all tasks that are related to our internal testing. All bugs found by the tech lead or QA team are added to a specific task. We can track the dynamics of bugs for each task and performer.
- We do the same with customer acceptance. These are bugs that were leaked despite the technical lead and QA checks, we also track them. At each meeting with the customer (usually once a quarter) we look at the dynamics of the regression of internal testing and the dynamics of the bugs that the customer found.
- We track Lead Time — the time from the appearance of a task to its complete completion. We need to complete tasks not only with high quality but also quickly within the same resources. This is how we increase the efficiency of the hour and the return on investment in the team.
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:
What Imagaban gives us:
- We reduce the Time to market. The better the task is formalized, the faster the developer will write the code. The more detailed the checkboxes, the less likely we are to forget about some artifacts. The logic is this, and it works. The average Lead time has been reduced from 120–130 days to 80. We want to reduce it to 50.
- We make the process predictable. And predictability also benefits. Now we predict the timing based on statistics and not from scratch; more precisely, we determine the price for customers and go beyond the budget less often.
- We connect with projects faster. Previously, beginning a new project may have taken two months. Time went to signing documents, implementing regulations, and working rules. Now it goes twice as fast.
