Agile ≠ Scrum¶

Это очень важный момент.

Многие менеджеры считают:

Agile = Scrum

Но исторически это вообще не так.

Agile — это философия¶

Основа: - адаптивность;
- короткая обратная связь;
- взаимодействие;
- реакция на изменения;
- итеративность;
- работающий продукт.

Agile-манифест вообще очень короткий.

Там почти нет: - ролей;
- церемоний;
- story points;
- velocity;
- scrum master;
- poker planning.

Scrum — это уже конкретная методология¶

Со своими:
- ритуалами;
- ролями;
- процессами;
- ограничениями.

И вот тут начинаются конфликты.

Почему технические люди часто ненавидят Scrum¶

Причин обычно несколько.

1. Scrum плохо работает в инженерной неопределенности¶

Это ключевая проблема.

Scrum вырос в:
- business software;
- веб-разработке;
- продуктовых UI-командах.

Но embedded/firmware/hardware — совсем другой мир.

Пример¶

В вебе:

сделать кнопку
→ понятно сколько времени

В embedded:

почему I2C ломается после выхода из sleep mode

Это может быть:
- 20 минут;
- 3 недели;
- silicon errata;
- EMI;
- race condition;
- проблема драйвера ядра;
- ошибка в datasheet.

Scrum требует предсказуемости¶

А инженерная реальность часто:

fundamentally unpredictable.

И инженер начинает чувствовать:

«меня заставляют врать в оценках».

2. Story Points раздражают инженеров¶

Очень часто.

Потому что:
- они субъективны;
- плохо измеримы;
- быстро превращаются в pseudo-hours.

Инженер думает:

«либо это часы, либо это шаманизм».

3. Scrum создает много ритуалов¶

Вот это вызывает сильное раздражение у технических людей.

Типичная боль¶

daily;
grooming;
retro;
sprint planning;
refinement;
review;
poker planning.

И инженер смотрит:

я 30% времени не работаю,
а обсуждаю работу

Особенно в маленьких командах.

4. Scrum плохо переносит research work¶

А у вас его будет очень много.

Например:
- OTA;
- PLC runtime;
- Modbus optimization;
- embedded Linux;
- MQTT reliability;
- hardware debugging;
- power management;
- RTOS issues.

Это:

exploration work.

Scrum же любит:

predictable deliverables.

5. Scrum часто вырождается в микроменеджмент¶

Вот тут обычно самая сильная ненависть.

Появляется:
- velocity pressure;
- sprint commitment;
- burndown policing;
- «почему не закрыли story»;
- KPI через points.

И инженер чувствует:

«меня превратили в фабрику тасок».

6. Scrum ломает flow-state¶

Для сложной инженерии это критично.

Firmware/architecture/debugging требуют:
- глубокого погружения;
- длинной концентрации.

А Scrum:
- встречи;
- interruptions;
- status updates.

И мозг начинает ненавидеть систему.

7. Scrum плохо работает с interdependent systems¶

Это особенно важно у вас.

У тебя:
- hardware;
- firmware;
- backend;
- mobile;
- cloud;
- OTA;
- MQTT;
- integrations.

А Scrum предполагает:

относительно автономные задачи.

Но в реальности:

backend blocked by firmware
firmware blocked by hardware
hardware blocked by procurement

И sprint начинает рассыпаться.

Почему Agile при этом нравится¶

Потому что Agile в инженерной среде обычно понимается как:

короткие циклы;
гибкость;
итерации;
обратная связь;
возможность менять направление;
постоянная интеграция;
работающий результат;
DevOps;
автоматизация.

То есть:

инженерная адаптивность.

А не:

культ Scrum.

Что обычно любят такие инженеры вместо Scrum¶

Вот это уже интересно.

1. Kanban¶

Очень часто.

Потому что:
- меньше ритуалов;
- continuous flow;
- меньше artificial deadlines;
- проще handling research work.

Для DevOps/embedded это почти стандарт.

2. Scrumban¶

Очень популярно у сильных команд.

То есть:
- минимум Scrum;
- максимум flow.

Например:
- есть planning;
- есть review;
- но нет религиозного соблюдения Scrum Guide.

3. Shape Up¶

Подход от 37signals / Basecamp

Инженеры часто любят его больше Scrum.

Потому что:
- больше автономии;
- меньше микроменеджмента;
- меньше meetings;
- больше ownership.

4. DevOps-flow¶

Очень часто зрелые инфраструктурные команды приходят к:
- Kanban;
- CI/CD;
- release trains;
- trunk-based development;
- automation-first.

Без строгого Scrum.

Что, вероятно, раздражает именно вашего консультанта¶

Судя по описанию:

он видит «уши Scrum».

То есть он замечает:
- искусственные процессы;
- избыточные ритуалы;
- попытку запихнуть инженерную работу в менеджерскую модель.

И боится, что:

реальная инженерия  
↓  
утонет в процессах

Для embedded-команд это очень частый страх.

И тут есть неудобная правда¶

Очень много Scrum-внедрений действительно:
- ухудшают производительность;
- увеличивают бюрократию;
- демотивируют инженеров.

Особенно в:
- R&D;
- embedded;
- infrastructure;
- deep-tech.

Что обычно работает лучше у таких команд¶

Для вашей области я чаще вижу успешную схему:

Kanban  
+  
lightweight planning  
+  
iterations/releases  
+  
CI/CD  
+  
automation  
+  
architecture ownership

А не:

strict Scrum religion

И вот почему OneDev может неожиданно хорошо лечь¶

Потому что он:
- workflow-oriented;
- engineering-oriented;
- менее «ритуальный»;
- ближе к Kanban+DevOps.

Там меньше ощущения:

«корпоративного Agile-театра».

И для embedded/industrial разработки это часто оказывается здоровее.