Гибкий суррогат
Словом «Scrum» называются, как минимум, две сущности: философия и фреймворк.
Философия, или подход к работе, описан в книге Джеффа Сазерленда.
Фреймворк, т.е. алгоритм действий, описан в документе под названием Scrum Guide.
Философия превратилась в фреймворк, потому что авторы философии хотели заработать на ней денег (по их собственным словам).
Фреймворк сильно упрощен, по сравнению с философией. Главное — упрощена, а точнее выкинута, цель.
Цель философии: ускорение достижения результата. Причем, в разы. В книге есть примеры ускорения в 8 раз.
Цель фреймворка: чтобы у вас был Scrum. Там так и написано: делаете по инструкции — у вас Scrum, нарушаете инструкцию — у вас не Scrum.
Фреймворк не предполагает ускорения достижения результата, вообще.
Люди, преподающие или внедряющие Scrum, работают с фреймворком. Рассказывают и внедряют алгоритм, не приводящий ни к каким результатам, кроме «у нас теперь Scrum».
Суть понятна. Философию продавать очень сложно. Фреймворк — проще.
Фреймворк — это продукт. Он, как положено, прошел «упаковку». Он прост, понятен, есть поддержка и много специалистов. Ничего не напоминает?
Всё хорошо, кроме результата — его нет.
Если заказчик не знаком с философией Scrum, то внедрение фреймворка его вполне устроит.
Если заказчик знаком с философией Scrum, то от внедрения фреймворка его ждет разочарование — никакого ускорения достижения результата не будет.
Будет прикольно, модно, современно, но никакие бизнес-цели достигнуты не будут (кроме освоения бюджета на «чего-нибудь новенькое»).
Как быть? Изучать философию Scrum. Она основана на японской философии управления качеством, суть которой: измерения и бесконечные улучшения.
К сожалению, там надо много думать, экспериментировать, наблюдать и, увы, работать. Если вам это не подходит — берите фреймворк.
habr.com/ru/post/345540
Изменяемая среда
Для того, чтобы повысить эффективность команды программистов, нужна изменяемая среда. Какая-то среда в команде уже есть — надо сделать ее изменяемой.
Изменяемая среда — это отсутствие формальных, утвержденных алгоритмов работы.
Программисты любят работать по алгоритму, потому что сами занимаются созданием алгоритмов.
Изменяемая среда — это типа отладки, только отлаживается не алгоритм программы, а работа команды.
Просто договариваетесь с командой, что началась эпоха перемен. Сегодня одни правила, завтра — другие. Не потому, что вожжа под хвост попала, а потому, что надо отладить работу команды.
Отладка — это запуск алгоритма, отслеживание его работы, и внесение корректировок, если что-то идет не так, как задумано или как хотелось бы.
Большинство проектов изменений проваливаются из-за отсутствия изменяемой среды. Страшно вносить изменения по кускам, страшно каждый день вводить новые правила. Намного проще, ничего не меняя, разработать Большой Документ, в котором Всё Прописано, и отдать его на исполнение.
Это, грубо говоря, как писать программный код сразу набело, без единого запуска. Не, иногда так можно поразвлекаться, но на приличных задачах такой подход не работает — слишком умным надо быть. Намного проще делать отладку в изменяемой среде.
habr.com/ru/post/345830
Скрам-мастер
Чистый скрам, описанный в книге, при правильном применении, повышает эффективность команды в 2 раза. Это проверено на практике.
Но чужая практика показывает, что никакого ускорения не случается вообще. Потому что методику, изложенную в книге, упростили для продажи. Именно она и используется — упрощенная.
Книжный скрам предполагает три уровня:
- Состояние Сю («соблюдать») – первая ступень, тренируетесь, повторяете, не отклоняясь от правил;
- Состояние Ха («прорываться») – начинаем менять правила, импровизировать;
- Состояние Ри («отделяться») – освобождаемся от правил и начинаем созидать.
Продается, как правило, первый уровень — инструкция, и внедрение ее исполнения. Чтобы получить реальный прирост эффективности, надо выходить на второй и третий уровень. Думать своей головой, искать пути оптимизации, внедрять их и следить за результатом.
Заниматься ускорением должен скрам-мастер — это его обязанность. Так написано в книге, цитирую: Основная забота скрам-мастера – вести команду к непрерывному совершенствованию и регулярно искать ответ на вопрос «Как нам делать еще лучше то, что мы уже делаем хорошо?».
Но это — второй и третий уровень. А продается и внедряется, напомню, первый.
На первом уровне у скрам-мастера совсем другие обязанности. Проверьте в интернете, список будет примерно таким:
О
- рганизует и проводит митинги;
- Следит за соблюдением принципов скрама;
- Создает атмосферу сотрудничества;
- Разрешает конфликты и защищает команду.
Ни слова про повышение эффективности. Просто соблюдение инструкции.
Если мыслить логически, то как вообще может повыситься эффективность, если команда постоянно работает по одним и тем же правилам? Чтобы что-то изменилось, надо что-то изменить. А этого делать нельзя — по инструкции не положено. Поэтому эффективность на первом уровне и не растет.
Скрам-мастером должен быть человек, которому интересно повышать эффективность. Этой работе нельзя научиться, если она не интересна. Надо много думать, ставить эксперименты, проверять гипотезы, постоянно ошибаться и набивать шишки.
Намного проще выдать инструкцию и следить за ее выполнением. Ну и фасилитировать иногда (что бы это не значило).
Я пробовал ставить скрам-мастерами разных людей, но мало кто заинтересовался. Это нормально.
Если знакомы с тестом Белбина, то лучше всего подойдут «Генератор идей», «Аналитик» и «Дипломат» (resource investigator).
Роль скрам-мастера очень похожа на роль программиста, оптимизирующего быстродействие приложения. Только тут система живая, из людей.
habr.com/ru/post/346158
Системное подчинение
Итог большинства организационных изменений: не получилось.
Побочный итог: методика — фуфло.
Та методика, которая лежала в основе изменений. В частности, Scrum.
Причина очень проста: системное неподчинение.
Ну и выход очень простой: системное подчинение.
Не систематическое, а системное. Подчинение, как система, как принцип.
В нашей стране неподчинение возведено в культ — спасибо многовековой истории нашего государства.
Системное неподчинение приводит к странной обратной связи: новые правила и законы создаются с учетом того, что их никто выполнять не будет.
Особенно это характерно для организационных изменений. Их автор даже не рассматривает вариант, что люди будут работать по предложенным правилам. Поэтому не заморачивается об исполнимости и адекватности правил.
Однако, есть примеры успешно внедренных изменений. Возьмите те же камеры видеофиксации на перекрестках.
Формально, штраф за выезд на перекресток, на котором выстроилась пробка, существовал давно. Но это правило практически не соблюдалось.
Сейчас же прекрасно соблюдается, на отдельных перекрестках. На тех, где установлены камеры видеофиксации.
Камеры как раз и обеспечили системное подчинение. Как только люди стали подчиняться правилу, стало понятно, что само правило — вполне себе рабочее. То самое правило, которое раньше дружно считалось какой-то хренью.
Так же любое другое правило, изменение, алгоритм, методика или кейс. Любая методика полезна.
Если вы считаете иначе, если вы утверждаете, что «Scrum не работает», или «ТОС не приносит результата», или «Lean — фуфло», то вы — отличный человек. Просто вы эту методику не внедрили, потому что не обеспечили системного подчинения. А свою неспособность его обеспечить свалили на неработоспособность методики.
Обеспечить системное подчинение очень просто. Надо начать с себя. Это будет системное самоподчинение.
Внедряете Scrum в своей команде? Выполняйте все объявленные правила, без исключений. Каждый день, без пропусков.
Сразу увидите и достоинства, и недостатки методики — и этой, и любой другой.
Если будет успех, то причиной будете вы. Если будет провал, то причиной будете вы.
habr.com/ru/post/346712
