Скрам, LeSS, Канбан, Аджайл и многое другое
Возвращаясь к теме командного доверия, сегодня хочется поделиться набором полезных инструментов. Для удобства составили список инструментов и категоризовали их с точки зрения фокуса и места использования (Персональный — Командный, Удаленная — Локальная).
Что же у нас получилось.
Читать далее «Trust Toolbox: палитра командных инструментов»или ежедневный чистый продукт
Кто-то взял инструмент и не вернул его обратно. Команде приходится искать его. Еще хуже, команда шлет письмо всем сотрудникам, а это отвлекает от работы и отнимает время. Крайняя мера — команда приобретает новый инструмент.
…Команда разработки двигается к Цели Спринта.
✥ ✥ ✥
Если вокруг беспорядок, вы тратите время и силы на поиск того, с чего нужно начать.
Если участник команды вынужден спрашивать, с чего начать работу, — это пустая трата времени. Если участник команды вынужден наводить порядок перед началом работы, это пустая трата времени. Если участник команды работает в беспорядке и переделывает за кем то работу, это пустая трата времени. Если участник команды не знает прогресс по продукту и повторяет сделанное другим, это тоже пустая трата времени и сил. Если участник команды спрашивает, что делать дальше, это пустая трата времени.
Слишком большой объем информации на Доске информации путает сотрудников и мешает отделить главное от второстепенного. Это отнимает время.
Если команда откладывает наведение порядка на конец Спринта, это тормозит прогресс. Команда может вообще не навести порядок в рабочей среде, так как к концу Спринта появляется много «срочной работы». Беспорядок в ходе Спринта существенно снижает производительность (см. Заметки о производительности) и качество продукта.
Пустая трата времени возникает из-за работы в условиях неясного прогресса.
Поэтому:
Каждый день продукт (код) и рабочее пространство должны быть абсолютно чистыми.
Читать далее «Правильное ведение хозяйства»
…Скрам-команда обслуживает многих стейкхолдеров, и все они борются за внимание команды. Команда получает запросы и требования от стейкхолдеров, от каждого клиента, от отделов продаж и маркетинга. Кроме того, в ходе работы появляются баги и это тоже требует внимания. Частота и важность этих запросов меняется. Иногда их объем и срочность просто чрезмерны.
✥ ✥ ✥
Смена приоритетов или проблемы с эксплуатацией часто прерывают работу Скрам-команды в ходе Спринта. Требования отделов продаж и маркетинга, вмешательство стейкхолдеров могут послужить причиной хронических сбоев в работе, многократных провалов Спринтов, несоблюдения сроков релизов и даже провала компании.
Скрам-команда — общий ресурс, который закрывает потребности многих стейкхолдеров. Трагедия общин — это дилемма, возникающая, когда множество людей, действуя независимо и рационально, руководствуясь своими личными интересами, в конечном итоге истощают общий ресурс, даже если очевидно, что такой результат не отвечает чьим-либо долгосрочным интересам. Впервые описал эту дилемму американский эколог и философ Гаррет Хардин в знаменитой статье «Трагедия общин» («The Tragedy of the Commons»), опубликованной в журнале Science в 1968 году.
Часто неудачные решения Владельца Продукта ведет к тому, что к Скрам-команде начинают обращаться с конфликтующими запросами. Некоторым командам приходится даже работать над фичами, которых нет в Бэклоге Продукта.
Желательно, чтобы Скрам-команда отвечала за результаты своей работы (“eat your own dog food”). Если выявляется дефект, команде нужно его исправить как можно быстрее. Если создается специальная команда для исправления дефектов, Скрам-команда не будет обращать внимание на скрытые дефекты.
Это, а также другие причины постоянно мешают работе Скрам-команды.
Читать далее «Illegitimus Non Interruptus (без стука не входить)»
Перевод оригинальной статьи Рафаэля Саббаха «Scrum Master: The Skilled Facilitator«
В книге «Умелый фасилитатор» (2002 г.) Роджер Шварц определяет групповую фасилитацию как
«процесс, в котором человек, чья кандидатура принята всеми участниками группы, занимающий нейтральную позицию, не влияющий на процесс принятия решений, выступает диагностом и помогает группе улучшить работу над проблемами, процессом принятия решений, способствуя повышению эффективности взаимодействия».
На основе этого определения Шварц создал модель «умелого фасилитатора».
Мы можем использовать ее, чтобы описать некоторые качества, которые ожидаем от Скрам-мастера при его работе с Командой Разработки и Владельцем Продукта — все они вместе образуют Скрам-команду. В частности, я применяю подход, когда фасилитатор обучает команду улучшать рабочие процессы и все менее зависеть от него. Это то, что Шварц называет развивающей фасилитацией.
Читать далее «Скрам-мастер: умелый фасилитатор»
Эд Аттербери, коллега Джеффа Сазерленда, сбит зенитной ракетой над Ханоем. На изображении видно, как он прыгает с парашютом!
…компании, команды и отдельные сотрудники часто обнаруживают, что не могут поставить продукт вовремя, и Sprint Burndown Chart свидетельствует о неизбежном провале. Для работы в Аджайл-стиле необходимы быстрое определение проблем и оперативная реакция.
✥ ✥ ✥
В середине Спринта проблемы возникают из-за срочных требований или непредвиденных изменений. К середине Спринта становится очевидно, что Команда разработки не в состоянии успешно завершить Бэклог Спринта. Команда находится наверху Sprint Burndown Chart и видит, что при текущем выполнении работ она не может достичь Цели Спринта.
Есть много причин для срывов Спринта, в данном паттерне рассматриваются три основные из этих типичных проблем:
Для гибкости необходимо быстрое реагирование на изменения, а для этого проблемы должны выявляться как можно раньше. К сожалению, часто новые команды и среднестатистические команды не хотят, чтобы проблемы становились заметными. В частности, они не хотят останавливать работу, устранять проблемы и подвергаться критике. На первом заводе NUMMI (New United Motor Manufacturing, Inc) компании Тойота в Америке руководители из Японии посетили фабрику через шесть месяцев после открытия и увидели, что сотрудники боялись дергать шнур-андон — если дернуть этот шнур, срабатывает сигнальная лампа и начинается обратный отсчет, после которого конвейер останавливается. Рабочие не останавливали конвейер достаточно часто, чтобы разрешать свои проблемы. Руководство дернуло за шнур несколько раз, чтобы остановить конвейер и продемонстрировать рабочим, что самым главным препятствием было их нежелание останавливать конвейер. Остановка конвейера позволяет заметить проблемы и правильно их разрешить. «Отсутствие проблем — это проблема», как гласит мантра японских руководителей. Читать далее «Аварийная процедура (Emergency Procedure)»
Перевод оригинальной статью Барри Оверима “The Value of Liberating Structures for Scrum Masters”
В августе 2018 года Scrum.org запустил тренинг Professional Scrum Master II. Его цель — предложить Скрам-сообществу продвинутый класс, предназначенный для поддержки Скрам-мастеров в их профессиональном развитии. Особенность PSM II — его формат, состоящий из освобождающих структур.
Поэтому возникает вопрос:
«В чем ценность Освобождающих Структур для Скрам-мастеров?»
Освобождающие структуры — это набор из 30+ моделей взаимодействия, которые уравнивают, обогащают и углубляют взаимодействия в группах. Кит МакКэндлесс и Анри Липманович выяснили, что корни Освобождающих структур лежат глубоко в науке комплексных систем. Они реализуют пять элементов дизайна и десять принципов. Это означает, что они не являются жестким, статичным набором активностей. Новые структуры постоянно разрабатываются, а существующие модифицируются, корректируются или удаляются. С освобождающими структурами можно начать трансформировать целые организации, изменяя способы взаимодействия групп и отдельных людей. Читать далее «Освобождающие структуры для Скрам-мастера»
«Возьми на себя ответственность! — Твоя ответственность, ты и бери!»
I’m not happy. I’m cheerful. There’s a difference. A happy woman has no cares at all. A cheerful woman has cares but has learned how to deal with them.
— Beverly Sills
Привет, я Ира Скрыпник и я хочу открыть тему Ответственности для обсуждения и практики. Когда я приехала на тренинг к Кристоферу Айвери, то не до конца понимала, что он подразумевает под ответственностью. Для меня ответственность была набором правильных действий: платить налоги, быть примерным гражданином, быть удобной для других, не создавать никому проблем, брать на себя ответственность за поступки, задачи, достижение целей, особенно если не хочется их достигать. Это было высшее проявление ответственности для меня тогда, такое самоотверженное геройство! Ох, как сильно я ошибалась… 🙂
Я спросила несколько человек, мнению которых доверяю, что для них ответственность:
Меня эти ответы очень впечатлили. Свобода, выбор, ресурс, внутренняя мотивация! Во многом это похоже на то, что Кристофер Айвери понимает под ответственностью:
Это свобода, выбор и сила решить любую проблему.
Читать далее ««Возьми на себя ответственность! — Твоя ответственность, ты и бери!»»
В статье делюсь с вами эпизодом запуска большой продуктовой группы. Стояла задача быстро познакомить 70+ разработчиков, а затем сформировать фиче-команды, работающие над одним продуктом.
Market of Skills — активность, помогающая лучше узнать друг друга. Она часто открывает слепые зоны, о которых люди не догадываются. Идея проста — у каждого есть персональное место на “базаре”, на котором продаем себя, навыки и таланты, а также покупаем их у коллег.
Раздав листы флип-чартов, я попросил изобразить на них:
Из-за большого размера группы базар был разделен на 3 раунда. В первом раунде (15 мин) торговали только первые номера, а остальные выступали в роли покупателей, во втором раунде вторые и т.д. Покупатели получили базарную валюту — стикеры и наклейки. На стикерах можно писать:
Раз, два, три… Поехали! По сигналу колокольчика базар стартовал. И он был настоящим!
Продавцы зазывали покупателей и продавали себя. Небольшое помещение наполнилось гулом десятков голосов. Повсюду были улыбки и смех. Я снял шапку фасилитатора на некоторое время и отправился на прогулку по базару, знакомясь с людьми и раздавая наклейки. С каждым раундом уровень энергии возрастал. И мне жалко было закрывать последний раунд, ведь это было так здорово!
Проводя Ретроспективу дня, ребята отметили, что Market of Skills была одной из самых ценных активностей за день.
✥ ✥ ✥
Если работать над большим количеством задач одновременно, это может значительно снизить эффективность работы сотрудников, производительность команды и благополучие всего предприятия. Это может навредить производительности и в отдельных случаях свести ее к нулю. Если каждый будет работать только над собственной задачей, они вряд ли смогут помочь друг другу и в долгосрочной перспективе научиться чему-нибудь у коллег.
Личные предпочтения сотрудника и препятствия в рабочей среде часто ведут к разрозненности усилий. Если команда одновременно работает над несколькими элементами, это ведет к чрезмерному количеству незавершенной работы, низкой эффективности и соответствующим задержкам.
WIP (количество незавершенной работы) или незавершенное производство — это частично завершенные задачи, ожидающие доработки и последующей продажи, а также ценность этих элементов. Эти элементы либо только что разработаны, либо ожидают доработки в очереди или во временном хранилище. Термин используется на производстве и в управлении поставками.
Оптимальное управление производством направлено на минимизацию незавершенной работы. Незавершенная работа требует дополнительного хранилища, представляет собой связанный капитал, недоступный для инвестиций, и несет в себе риск, что срок хранения продуктов уменьшится. Если на производственном этапе образовалась очередь, значит, этому этапу не грозит нехватка задач с предыдущих этапов, но также это может указывать на недостаток ресурсов для обработки результатов от предыдущих этапов.
Предположим, команда пытается увеличить выработку путем параллельной работы, когда каждый сотрудник работает над одним элементом Бэклога Продукта (PBI). Работая в одиночку, члены Команды разработки с большей вероятностью сосредоточатся на разработке элемента, а не на его тестировании, в частности, потому что специалистов, обладающих компетенциями и желанием проводить тестирование, намного меньше, чем специалистов для творческих задач проектирования и разработки. Если в ходе Спринта возникает задержка нескольких элементов, возрастает риск того, что к концу Спринта PBI не придут к статусу «Готово». Что еще хуже, некоторые разработчики из Кремниевой долины и Европы, работающие над сложным программным обеспечением, обнаружили, что если не выявить и не исправить ошибку в ходе Спринта, один час тестирования кода может превратиться в 24 часа тестирования три недели спустя. Если команда откладывает тестирование, а не применяет Сворминг, то элемент, который можно было бы поставить через месяц, будет поставлен через два года. Читать далее «Swarming: one-piece flow»
Перевод оригинальной статьи Виллема-Ян Агелинга “Scrum — Self-organization isn’t a fluffy thing”
Разговоры про самоорганизацию происходят не из-за того, что мы хотим просто видеть сияющих от счастья людей.
Да, счастье — это бонус, побочный эффект. Но для чего на САМОМ ДЕЛЕ нужна самоорганизация?
Интересно, что в Руководстве по Скраму не говорится, ПОЧЕМУ самоорганизация — это хорошо. Словно создатели Скрама не видят необходимости объяснять нам ее важность. Предполагается, что все и так это знают. Но я считаю, что это не способствует осознанию ее важности.
К счастью, хорошее обоснование приводится в статье от 1986 года, с которой начался Скрам — «The New New Product Development Game» авторов Хиротака Такеучи и Икуджиро Нонака. Они описывают несколько ярких примеров, когда самоорганизация эффективна и ведет к более быстрой и качественной разработке продукта:
Первый документ по Скраму от 1995 года не упоминает самоорганизацию. Похоже, что данный термин отсутствовал в Скраме начала 90-х годов. Однако при этом в рамках экстремального программирования (Extreme Programming, XP) оно считалось ключевым фактором успеха:
«Блестящие программисты, конкурирующие между собой в эгоцентричном окружении, не смогут создать продукт, который создадут обычные программисты, работающие коллаборативно как самоорганизующаяся команда. Чтобы полностью раскрыть потенциал, нужен рабочий процесс, в котором преобладают командный дух и сотрудничество». — www.extremeprogramming.org
В те дни между XP и Скрамом было сильное взаимовлияние, один подход вдохновлял другой. Более того, в 2001 году люди, создавшие и популяризовавшие Скрам и XP, встретились с другими светлыми умами и разработали Аджайл-манифест. Самоорганизация упоминается как один из 12 принципов Аджайл-манифеста:
«Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд», — Аджайл-манифест (2001).
В 2001 году стало очевидно, что самоорганизация стала частью Скрама, это отмечают Кен Швабер и Майкл Бидл в книге «Agile Software Development with SCRUM» (2001):
«Команда часто проходит через короткий период, когда она не понимает, что у нее есть все полномочия. […] Но это удивление быстро проходит и сменяется продуктивностью, возникающей из-за самоорганизации», — «Agile Software Development with Scrum», 2001.
С этих пор самоорганизация стала частью фреймворка. Без описания контекста, так как предполагается, что это знание не способствует лучшему описанию фреймворка Скрам.
Скрам и другие Аджайл-подходы приветствуют самоорганизацию, потому самоорганизующиеся команды более креативны и продуктивны, а не просто ради “счастья во всем мире”.
Самоорганизация — необходимое условие для создания продуктивных и креативных команд.