«Масштабированный скрам. Как организовать гибкую разработку в крупной компании», Крэг Ларман, Бас Водде

Одна из моих текущих задач — выстраивание процесса разработки на несколько команд в одном продукте с последующим масштабированием этих практик на все остальные продукты, разработкой которых я управляю. В прошлый раз при решении этой задачи я умудрился переизобрести LeSS (Large-Scale Scrum). В этот раз я не стал мудрить и решил использовать те практики, которые уже хорошо себя зарекомендовали.

Книгу я взял, чтобы вспомнить, из чего вообще строится LeSS и как его аккуратно внедрить, когда команда уже в разгаре разработки. Но ответа на второй вопрос я не нашёл. Вместо алгоритма внедрения получил россыпь моделей, практик и теорий.

⭐️ О чём книга

Книга посвящена тому, как внедрить LeSS в большой организации. Авторы фокусируются на моделях мышления, которые нужны для успешного внедрения подхода, и дают кучу идей и практик, которые читателю рекомендуется попробовать. Много внимания в книге уделяется инструментам мышления и анализа, которые позволяют эффективно управлять работами.

⭐️ Три идеи, которые я забрал себе

🟡При масштабировании делить нужно работу, а не продукт. LeSS предполагает, что все команды работают в едином продуктовом бэклоге и едином ритме, а с требованиями помогает справиться единый владелец бэклога. Такой подход помогает не превратить команды в отдельные «мини-продукты со своим миром». Меня эта идея зацепила тем, что при масштабировании очень легко неосознанно размножить локальные бэклоги и получить несколько правильных приоритетов одновременно. Общий бэклог заставляет выбирать, что важнее для продукта целиком.

🟡В LeSS менеджер становится не просто «передастом» работы, а учителем. Задача менеджера — распространять правильные паттерны мышления и по сути выращивать культуру организации. Поэтому от менеджеров в LeSS ожидается, что они будут целенаправленно уделять время обучению и коучингу своих людей. Это та работа, которая (по моим личным ощущениям) даёт огромный профит с точки зрения человеческих ресурсов: сотрудники получают положительное внимание и растут.

🟡Задача команды — поставить фичу клиенту. Фича — это единица ценной функциональности. Здесь речь уже о границе ответственности. В функционально разделённых организациях я многократно встречал ситуацию: бэкенд закончил свою часть, передал работу дальше и формально всё сделал правильно, только клиент ценности не получил. При этом за фичу целиком уже никто не отвечает.

⭐️ Мои впечатления

Недавно в комментариях была просьба написать пост о книгах, на которые было зря потрачено время. Пожалуй, этой книгой можно открыть список.

В книге смешались в кучу кони, люди, Дао Тойота, ТОС, теория массового обслуживания и ещё невесть что. При чтении книга показалась мне несвязной и слабо структурированной. К счастью, навыки предварительного анализа и скимминга сэкономили мне кучу времени.

Проблема не в самих темах. Они реально полезны при работе с большой организацией. Проблема в том, что авторы постоянно прыгают между моделями мышления, оргдизайном, метриками и отдельными практиками, но не собирают их в последовательный ответ на вопрос «что делать завтра». Как руководство по внедрению LeSS книга для меня не сработала.

Не повторяйте моих ошибок. Если вам вдруг нужно внедрить LeSS (или вы просто хотите познакомиться с ним) — вот два замечательных ресурса:
➡️ LeSS Brochure — краткое, но ёмкое и наглядное описание LeSS в 8 страниц.
➡️ LeSS Rules — буквально шпаргалка по LeSS.

Если нужно быстро познакомиться с LeSS или освежить его устройство, книгу можно спокойно пропустить. Пригодиться она может тем, кто уже знает основы LeSS и хочет покопаться в лежащих под ним моделях мышления. Но как точку входа я её не рекомендую.

Все мои обзоры книг доступны по тегу #обзор_книги и в этом посте.

➡ А для тех, кто хочет читать с большей пользой, у меня есть практикум «ИнфоСушка», в котором мы полностью меняем подход к чтению и делаем его эффективным.

➖➖➖➖➖➖➖➖➖➖➖
📝 @ulshinblog