Now Hiring: Are you a driven and motivated Mid/Senior .Net Developer?

Scrum больше мёртв, чем жив?

Business

Scrum больше мёртв, чем жив?

Поговорим об утомлённых Agile’ом

Сегодня Scrum везде: разработка ПО, архитектура, бухгалтерия, медицинские услуги и даже продажи. Однако, вместе с этим растёт и количество людей “утомлённых Agile’ом” с мнением, что “Scrum больше мёртв, чем жив”.

❓Scrum, чтобы что

Подобный вопрос – основа внедрения любых изменений, без него получаются улучшения ради улучшений. Нужно помнить, что успешность запуска любой активности на 50-70% определяется предстартовой подготовкой.

Если вы руководствуетесь мотивами: “Так модно”, “Все так делают, давайте и мы?”, – то такой неконтролируемый процесс приведёт к каким-то результатам, возможно, даже положительным. Только будут ли они именно теми, что вы хотели перед стартом?

💼 Кейс

На встрече отдела разработки все пришли к выводу, что текущие процессы всё сильнее запутываются, количество ошибок растёт и надо что-то менять. Решили внедрить Scrum, ведь так даже Valve делает.
Сделали всё, как по учебнику: выделили команды, подбили им бэклоги, организовали регулярные события…

И что же происходит дальше? 
А дальше разработчики видят, что они всё также пишут код, только ещё добавились какие-то встречи, на которые нужно ходить, тратить своё драгоценное время, за которое они могли бы больше кода написать. #ещёбольшекода
Руководство же наблюдает отсутствие сверхпроизводительности, какие-то собрания в переговорках, опять же трата времени, а на вопрос о сроках ответ: “Мы взяли в спринт, всё будет готово к его концу. Но это не точно.”

❗В результате

Команда не может отслеживать прогресс, хотя о чём тут говорить, если даже цель не была сформирована. Её отсутствие демотивирует сотрудников, они хотят код писать, а не вот это вот всё. У руководства не появляется ясности, что же происходит внутри и что изменилось.

Такая ситуация может существовать достаточно долго, т.к. что-то всё-таки меняется. Однако, стоит учитывать, что при отсутствии постановки желаемого конечного результата, с вероятностью близкой к 100%, разработчики сначала будут решать проблемы своего удобства и благоустройства, затем внутренние проблемы отдела, т.е. использовать встроенные в Scrum механизмы обратной связи и адаптации как инструмент изменения внешней среды.

Как лечить? 
Ответ от Капитана: “Выработать цели или критичные направления для инспекции и адаптации” и планомерно двигаться к разрешению используя встроенные петли обратной связи.

А у вас в практике были неудачные примеры внедрения Scrum? Замечали ли их в компаниях и что делали для исправления ситуации?