Slidelog минидоклада "SCRUM.WTF - вступление в личную коллекцию WTF-ов"



На конференции 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...).

    Возможное решение: нужно привлечь внешнего консультанта или нанять специалиста в команду.
Бежать и отлаживать JavaScript или поднимать билд-сервер - это вовсе не решение процессных препятствий. Если это проблемы частые, ищите процессные проблемы, которые стоят за ними, они достойны того, чтоб вы - Скрам-мастер с ним разобрались.