На конференции AgileBaseCamp:Киев я выступал в формате Lightning talk с десятиминутным докладом-скороговоркой.
Я уже более пяти лет использую Скрам, наблюдаю и общаюсь с людьми его использующими, учу и помогаю запускать проекты по Скрам. Более пяти лет...
И все же, у меня до сих пор есть список непоняток, список недоразумений, список вопросов.
WTF?
Но я не просто расскажу о том, что мне непонятно. Это было неполезно аудитории. У меня время от времени возникают прозрения. И я хотел бы поделиться ими - своим сегодняшним видением разрешения того или иного WTF-ка.
И так, встречайте номер семь:
О чем это я?
Я вот о чем. Все знают, на ежедневной пятнадцатиминутной планерке (называемыой в народе standup-митингом, или просто стоячкой), каждый член команды отвечает на три вопроса.
Один из вопросов: "Что мне мешает успешно завершить планируемое на сегодня?". По-английски, звучит просто и красиво (как обычно): "What is holding me back?"
Список озвученных причин именуется в науке impediments (во избежание страшного слова "проблема"). Ну или obstacles (препятствия).
Как поется в песне:
Так вот. Этот список, как говорит теория Скрам, называется impediment backlog, и Скрам-мастер (заведующий всем) его разгребает.Проблеме я не люблю совсеме,
зачеме проблеме вообще зачеме.
Идея отличная: если у команды есть кто-то, кто устраняет препятствия на ее пути, команда становится супер-производительной. Поспорить сложно.
Но, что если проблема (ой, простите - препятствие) звучит как: "я не могу отладить вот уже второй день этот ... JavaScript" или "у нас падает билд-сервер".
По теории Скрам-мастер должен это взять на себя. На практике, это деструктивно для команды - Скрам-мастер становится Скрам-нянькой или Скрам-мамой (как вам больше нравится).
Но мне лично не нравится никак. Хотя в теории так и должно все быть.
WTF?!
Дилемма. Мое текущее понимае ситуации таково.
Во-первых:
Let the team eat its dog food. Что значит, пусть команда сама решит эти проблемы. На то она и команда. Скрам-команда.
Скрам-мастер должен стать хорошим футболистом. Он должен отфутболивать такие вещи назад. Но при этом помочь команде взять ответственность за решение.
Во-вторых:
Скрам-мастер - ответственнен за успех или неуспех использования Скрам в проекте. Поэтому его задачей является идентифицировать и устранять процессные препятствия.
Что это за вид препятствий и чем они отличаются от других? Процессные препятствия - это вещи, которые внедрение Скрама сделало видимыми, которые всплыли на поверхность, которые мешают команде стать более эффективной, а процессу более адаптивным.
Примеры:
- Стейкхолдеры ломают планы спринта, подкидывая более другие задачи.
Возможное решение: настроить процесс отправки ходоков к Ленину (читай ProductOwner-у).
- ProductOwner не умеет обращаться с требованиями так, чтоб они были записаны в легком формате, ложились в product backlog и были потом обсуждены вживую, а наоборот - тяготеет к письменному изложению.
Возможное решение: провести мини-тренинг по User Stories, User Story Map и прочим техникам.
- ProductOwner не появляется на sprint planning или sprint review.
Возможное решение: трубить в трубы эскалации.
- Команда не берет ответственность за план спринта (небезопасная среда).
Возможное решение: нужно устранить давление и перефразировать понятие ответственности из кровных обещаний в делать лучшее из возможного.
- Команда не владеет современными подходами разработки софта и встраивания качества (Unit Testing, Continuous Integration, Refactoring, Automated Regression Testing...).
Возможное решение: нужно привлечь внешнего консультанта или нанять специалиста в команду.
