The post has been translated automatically. Original language: Russian
One of the first questions a new project manager faces is: what methodology should I use? The answer "Scrum, because everyone does it" is the most common and most expensive mistake. A methodology is a tool for a specific task, not a universal standard. This article contains the selection criteria and an analysis of when something really works.
Why is the choice of methodology important at all
An incorrectly chosen methodology does not kill the project instantly, but creates constant friction: the team spends time on rituals that are not useful, the manager reports on metrics that do not reflect reality, and stakeholders do not understand when to expect results.
Three questions to ask before choosing:
- How predictable is the task flow?
- How often do priorities change?
- Is there a need for a fixed supply rhythm, or is continuous flow more important?
Scrum: when work goes in iterations
Scrum is built around sprints — fixed time periods (usually 1-2 weeks), at the end of which the team shows the finished product increment.
It is well suited when:
- The product is being developed from scratch, and there is a clear backlog of features.
- Stakeholders want regular demos and feedback points.
- The team is stable in composition and can keep a constant rhythm.
- Priorities do not change more often than once per sprint
It doesn't fit well when:
- There are a lot of unpredictable tasks from the outside (bugs, urgent requests from other departments) — they break the sprint
- The team is engaged in product support, not the development of new features.
- Priorities change daily, so planning for 2 weeks becomes meaningless.
The key metric of Scrum is velocity (the team's speed in story points per sprint). It is useful for predicting deadlines, but it is dangerous if it turns into KPIs: the team begins to overestimate estimates so that velocity looks steadily growing.
Kanban: When continuous flow is important
Kanban does not divide work into iterations. Instead, there is a board with columns (To Do → In Progress → Review → Done) and a limit on the number of tasks in operation at the same time (WIP limit).
It is well suited when:
- The team handles support, bugfixes, and operational tasks
- Tasks come unpredictably, and you need to respond quickly to them.
- The speed of completing a single task (lead time) is more important than the predictability of delivery in batches.
- The team is unstable or the tasks require different specialists at different times.
It doesn't fit well when:
- We need regular demos for stakeholders with a fixed rhythm.
- The project requires detailed planning for several weeks ahead
- The team is just forming and it needs a ritual structure to develop the habit of working together.
The key metrics of Kanban are lead time (how long a task takes from start to completion) and cycle time (time in active work). The WIP limit is not a bureaucracy, but a way to expose bottlenecks: if the limit constantly rests on the review, then the problem lies in the review process, not in the developers.
Hybrid: Scrumban and adapted approaches
In practice, most teams use something in between. A typical hybrid is Scrumban: the rhythm of sprints is preserved for planning and retrospectives, but the board and WIP limits are taken from Kanban to control the flow within the sprint.
An example of how this works: a product team that simultaneously develops new features (requires rhythm and predictability) and supports production (requires flexibility for urgent bugs). The solution is to allocate a percentage of the team's capacity (for example, 20%) for unpredictable tasks right in the sprint planning, instead of breaking the sprint with every incident.
Another frequent hybrid is Scrum rituals (daily, retro, planning) without hard sprints, with a continuous stream of tasks like in Kanban. This is suitable for mature teams that know how to prioritize themselves, but stakeholders still need a predictable synchronization rhythm.
How to make a decision in practice
A simple checklist to choose from:
| Criteria | Closer to Scrum | Closer to Kanban |
| Type of work | New development | Support, bugs |
| Predictability of tasks | High | Low |
| We need a fixed demo rhythm | Yes | No |
| Priorities are changing | Every 1-2 weeks | Daily |
| Maturity of the team | Being formed | Stable, self-organized |
If the answers are mixed on most points, this is a normal signal in favor of a hybrid, and not a reason to painfully choose one thing.
A common mistake: changing methodology as a solution to all problems
When something goes wrong in a team - deadlines are falling short, motivation is falling, technical debt is growing — the temptation to change the methodology is great: "maybe if you switch to Kanban, it will become easier." In most cases, the problem is not with the framework, but with how it is applied: there is no real prioritization of the backlog, retrospectives are formal, and WIP limits are not met.
Before changing the methodology, it is worth honestly assessing whether the current tools have been used as intended.
Conclusion
Methodology is a way to make the flow of work visible and manageable, not ritual for ritual's sake. Scrum provides predictability and structure where work is broken down into understandable iterations. Kanban provides flexibility where the flow of tasks is unpredictable. Hybrid approaches are often closer to the reality of most IT teams than the pure forms of any of the frameworks.
Один из первых вопросов, с которым сталкивается менеджер нового проекта: какую методологию использовать? Ответ «Scrum, потому что все так делают» — самая частая и самая дорогая ошибка. Методология — это инструмент под конкретную задачу, а не универсальный стандарт. В этой статье — критерии выбора и разбор, когда что действительно работает.
Почему выбор методологии вообще важен
Неправильно подобранная методология не убивает проект мгновенно, но создаёт постоянное трение: команда тратит время на ритуалы, которые не приносят пользы, менеджер отчитывается по метрикам, которые не отражают реальность, а стейкхолдеры не понимают, когда ждать результат.
Три вопроса, которые стоит задать перед выбором:
- Насколько предсказуем поток задач?
- Насколько часто меняются приоритеты?
- Нужен ли фиксированный ритм поставки или важнее непрерывный поток?
Scrum: когда работа идёт итерациями
Scrum строится вокруг спринтов — фиксированных отрезков времени (обычно 1-2 недели), в конце которых команда показывает готовый инкремент продукта.
Хорошо подходит, когда:
- Продукт разрабатывается с нуля, и есть чёткий бэклог фич
- Стейкхолдеры хотят регулярные демо и точки для обратной связи
- Команда стабильна по составу и может держать постоянный ритм
- Приоритеты меняются не чаще, чем раз в спринт
Плохо подходит, когда:
- Много непредсказуемых задач извне (баги, срочные запросы от других отделов) — они ломают спринт
- Команда занимается поддержкой продукта, а не разработкой новых фич
- Приоритеты меняются ежедневно — тогда планирование на 2 недели теряет смысл
Ключевая метрика Scrum — velocity (скорость команды в story points за спринт). Она полезна для прогнозирования сроков, но опасна, если превращается в KPI: команда начинает завышать оценки, чтобы velocity выглядела стабильно растущей.
Kanban: когда важен непрерывный поток
Kanban не делит работу на итерации. Вместо этого — доска с колонками (To Do → In Progress → Review → Done) и ограничение на количество задач в работе одновременно (WIP-лимит).
Хорошо подходит, когда:
- Команда занимается поддержкой, багфиксами, операционными задачами
- Задачи приходят непредсказуемо, и нужно быстро на них реагировать
- Важнее скорость прохождения одной задачи (lead time), чем предсказуемость поставки пачками
- Состав команды нестабилен или задачи требуют разных специалистов в разное время
Плохо подходит, когда:
- Нужны регулярные демо для стейкхолдеров с фиксированным ритмом
- Проект требует детального планирования на несколько недель вперёд
- Команда только формируется и ей нужна структура ритуалов, чтобы выработать привычку работать вместе
Ключевая метрика Kanban — lead time (сколько времени задача проходит от старта до завершения) и cycle time(время в активной работе). WIP-лимит — это не бюрократия, а способ вскрыть узкие места: если лимит постоянно упирается в ревью, значит, проблема в процессе ревью, а не в разработчиках.
Гибрид: Scrumban и адаптированные подходы
На практике большинство команд использует что-то среднее. Типичный гибрид — Scrumban: ритм спринтов сохраняется для планирования и ретроспектив, но доска и WIP-лимиты берутся из Kanban для управления потоком внутри спринта.
Пример, когда это работает: продуктовая команда, которая одновременно разрабатывает новые фичи (нужен ритм и предсказуемость) и поддерживает продакшн (нужна гибкость под срочные баги). Решение — выделить процент капасити команды (например, 20%) под непредсказуемые задачи прямо в планировании спринта, вместо того чтобы ломать спринт каждым инцидентом.
Другой частый гибрид — Scrum-ритуалы (дейли, ретро, планирование) без жёстких спринтов, с непрерывным потоком задач как в Kanban. Это подходит зрелым командам, которые умеют сами приоритизировать, но стейкхолдерам всё ещё нужен предсказуемый ритм синхронизаций.
Как принять решение на практике
Простой чек-лист для выбора:
| Критерий | Ближе к Scrum | Ближе к Kanban |
| Тип работы | Новая разработка | Поддержка, баги |
| Предсказуемость задач | Высокая | Низкая |
| Нужен фиксированный ритм демо | Да | Нет |
| Приоритеты меняются | Раз в 1-2 недели | Ежедневно |
| Зрелость команды | Формируется | Стабильная, самоорганизованная |
Если по большинству пунктов ответы смешанные — это нормальный сигнал в пользу гибрида, а не повод мучительно выбирать что-то одно.
Частая ошибка: смена методологии как решение всех проблем
Когда в команде что-то идёт не так — срываются сроки, падает мотивация, растёт технический долг — соблазн сменить методологию велик: «может, если перейти на Kanban, станет легче». В большинстве случаев проблема не в фреймворке, а в том, как он применяется: нет реальной приоритизации бэклога, ретроспективы проходят формально, WIP-лимиты не соблюдаются.
Прежде чем менять методологию, стоит честно оценить, использовались ли текущие инструменты так, как задумано.
Вывод
Методология — это способ сделать поток работы видимым и управляемым, а не ритуал ради ритуала. Scrum даёт предсказуемость и структуру там, где работа разбивается на понятные итерации. Kanban даёт гибкость там, где поток задач непредсказуем. Гибридные подходы чаще всего ближе к реальности большинства IT-команд, чем чистые формы любого из фреймворков.
Share
