Swarming: one-piece flow

Если работать над большим количеством задач одновременно, это может значительно снизить эффективность работы сотрудников, производительность команды и благополучие всего предприятия. Это может навредить производительности и в отдельных случаях свести ее к нулю. Если каждый будет работать только над собственной задачей, они вряд ли смогут помочь друг другу и в долгосрочной перспективе научиться чему-нибудь у коллег.

Личные предпочтения сотрудника и препятствия в рабочей среде часто ведут к разрозненности усилий. Если команда одновременно работает над несколькими элементами, это ведет к чрезмерному количеству незавершенной работы, низкой эффективности и соответствующим задержкам.

WIP (количество незавершенной работы) или незавершенное производство — это частично завершенные задачи, ожидающие доработки и последующей продажи, а также ценность этих элементов. Эти элементы либо только что разработаны, либо ожидают доработки в очереди или во временном хранилище. Термин используется на производстве и в управлении поставками.

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

Предположим, команда пытается увеличить выработку путем параллельной работы, когда каждый сотрудник работает над одним элементом Бэклога Продукта (PBI). Работая в одиночку, члены Команды разработки с большей вероятностью сосредоточатся на разработке элемента, а не на его тестировании, в частности, потому что специалистов, обладающих компетенциями и желанием проводить тестирование, намного меньше, чем специалистов для творческих задач проектирования и разработки. Если в ходе Спринта возникает задержка нескольких элементов, возрастает риск того, что к концу Спринта PBI не придут к статусу «Готово». Что еще хуже, некоторые разработчики из Кремниевой долины и Европы, работающие над сложным программным обеспечением, обнаружили, что если не выявить и не исправить ошибку в ходе Спринта, один час тестирования кода может превратиться в 24 часа тестирования три недели спустя. Если команда откладывает тестирование, а не применяет Сворминг, то элемент, который можно было бы поставить через месяц, будет поставлен через два года. Читать далее «Swarming: one-piece flow»

Инкрементальный дизайн и архитектура

Перевод оригинальной статьи Рона Джеффриза «Incremental Development»

Суть подхода Big Design (детальное проектирование до начала разработки, англ. Big Design Up Front, BUFD) заключается в том, что у нас есть тщательно отобранный набор идеальных требований, и при помощи нескольких достаточно формализованных практик мы создаем красивую архитектуру для воплощения этих требований. Этот дизайн подобно солнцу освещает мир программирования, позволяя программистам без каких-либо глубоких раздумий идеально воплощать идеальную архитектуру для выполнения этих идеальных требований.

Даже если бы это было правдой (спойлер: это не правда), в большинстве случаев Big Design не смог бы удовлетворить наши потребности. Я бы сказал, он никогда не удовлетворяет наши потребности, и уж точно не в случае, который волнует меня больше всего —

В случае работающего продукта

За свою полувековую карьеру в разработке ПО я узнал многое — и самостоятельно, и работая с командами. Если бы я мог вернуться в прошлое и вынести только одну мысль, она была бы такой:

Какой бы продукт вы ни разрабатывали, поставляйте реально работающий продукт каждые две недели, а если возможно, то каждый день.

Читать далее «Инкрементальный дизайн и архитектура»

Создаем прозрачность и ответственность в команде

О чем эта статья

Основой современных организаций становятся команды, а индивидуальная ответственность замещается командной. Но ответственность не возникнет сама собой. Для ее возникновения необходима прозрачность и условия, при которых участники команды давали бы друг другу честную и открытую обратную связь. Как это сделать — читаем дальше.

Когда команды избегают продуктивного конфликта

Не так давно у меня был телефонный разговор с одним Владельцем Продукта, работающего с несколькими командами в масштабируемом Скраме. Он просил совета. По его словам, к нему неоднократно подходили отдельные представители команд и жаловались на поведение своих коллег. Они говорили, что некоторые работали “спустя рукава”. После нескольких минут разговора для меня ситуация представлялась в следующем свете: несмотря на то, что Ретроспектива Спринта как событие формально существовала, участники команд не давали друг другу открытую обратную связь. Они избегали продуктивного конфликта.

Команды ТОП-менеджеров тоже не являются исключением. Они часто дополнительно обременены политическими конфликтами, подковерными играми и борьбой за организационные “колодцы”. Читать далее «Создаем прозрачность и ответственность в команде»

Три самых эффективных способа, позволяющих руководителям заслужить доверие

Одна из наших любимых тем — доверие. Мы уделяем ей значительное время в рамках Аджайл-консалтинга, работая с командами и организациями. В продолжении развития это темы сегодня публикуем перевод статьи  «The 3 most effective ways to build trust as a leader».

Читать далее «Три самых эффективных способа, позволяющих руководителям заслужить доверие»

Как заставить говорить ваш Cumulative Flow Diagram?

Участвуя как спикер на разных конференциях я наибольшее удовольствие получаю не от выступлений на сцене с докладом и слайдами, а от живого общения на различных мастер-классах и воркшопах. Камерная атмосфера дает возможность апробировать интересные инструменты и извлечь уникальные инсайды. Не обошлось без этого и на Agile Days 2019, где я выступал с мастер-классом про накопительные диаграммы потока (CFD). Ниже тезисы моего воркшопа. Читать далее «Как заставить говорить ваш Cumulative Flow Diagram?»

8 причин хронического незавершения работы в Спринте

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

Системы, паттерны и структуры.

Команда Разработки является системой с общей целью и взаимозависимыми между собой элементами (разработчики). Если события в системе повторяются, то они становятся паттерном. За каждым паттерном скрывается подкрепляющая структура. В данном случае паттерн системы — хроническое незавершение задач в Спринте.

Поиск структуры.

Задача Скрам-мастера — в партнерстве с командой найти структуру, которая вызывает паттерн и изменить ее. Для этого Скрам-мастер может предложить команде использовать на Ретроспективе инструменты системного мышления:

  • Пять почему
  • Fishbone
  • Causal-Loop Diagrams(CLD)
  • Дерево реальности
  • Метод А3

Фундаментальные причины, к которым приходят команды, могут сильно различаться. Приведу те, с которыми встречался в своей практике.
Читать далее «8 причин хронического незавершения работы в Спринте»

Модель коммуникации определяет продуктивность команды

Наука или искусство

Кто-то считает, что создание высокопроизводительных команд — это искусство, а не наука. Но исследование, проведенное лабораторией динамики человеческой деятельности MIT, выявило конкретные факторы, которые характеризуют высокоэффективные команды.

Паттерны коммуникации успешных команд

В статье The New Science of Building Great Teams профессор Сэнди Пентлэнд пишет, какие паттерны коммуникации и поведения определяют успешные команды:

  1. Все говорят и слушают примерно в равной мере.
  2. Общение происходит лицом к лицу и достаточно энергично.
  3. Люди общаются напрямую, не через лидера или руководителя команды.
  4. Участники команды периодически покидают группу, отправляясь на поиски информации, а затем приносят и делают доступной для каждого в команде.

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

Исследование очень сильно перекликается с многолетним исследованием Эми Эдмондсон о психологической безопасности, которое легло в основу проекта Аристотель (исследование в компании Google). Мне кажется, что психологическая безопасность является основополагающим фактором, который “открывает” людей и затем дает возможность раскрыться команде с помощью эффективных паттернов коммуникации.

Как это может изменить вашу работу как Скрам-мастера и агента изменений? 🙂

Как найти пользователей на Обзор Спринта

Проблема с поиском пользователей на Обзор Спринта

Часто команды жалуются на то, что не знают где найти внешних пользователей для Обзора Спринта. Я работаю Скрам-мастером в команде Альпина Диджитал уже несколько месяцев, и мы не исключение. Обычно к нам приходил лишь один внешний пользователь на Обзор Спринта.

Амбициозная цель

В последнем Спринте Команда Разработки поставила себе амбициозную цель: реализовать фичу на обоих платформах и получить обратную связь как минимум от двух конечных пользователей. Нам нужен был способ, как “затащить” людей в офис.

Где мы искали гостей

Я разместила приглашение на Обзор Спринта в группе Scrum Russia на FB. Несколько ребят подтвердили свое участие. Команде удалось найти четырех пользователей среди тех, кто обращался в техническую поддержку. А отдел продаж привлек ключевого b2b-клиента. Ура!

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

Читать далее «Как найти пользователей на Обзор Спринта»

Как убить очереди и ускорить команду при помощи моббинга

Команда организовывает свою работу

Команда Разработки в Скраме самоорганизующаяся и кросс-функциональная, и поставляет к концу каждого Спринта “готовый” к выпуску инкремент продукта. Команда сама определяет, как ей организовать работу в Спринте:

По результатам Планирования Спринта Скрам-команда решает: каким будет Инкремент в конце Спринта; как организовать работу, чтобы получить готовый Инкремент Продукта (Скрам Гайд, 2017).

Есть полезные современные практики организации работы команды в Спринте, которые вы можете взять на вооружение. И одна из них “моббинг” или “моб-программирование”.

Разработка в стиле “моббинг” или “моб-программирование”

Википедия определяет моббинг как “форму психологического насилия в виде травли сотрудника”, а вот определение “моб-программирования” от автора подхода Вуди Зила:

замечательные люди, работающие вместе над одной задачей в один момент времени в одном месте за одним компьютером.”

По сути, моббинг — стиль работы, когда команда постоянно работает вместе и вместе “набрасывается” на любые задачи.
Читать далее «Как убить очереди и ускорить команду при помощи моббинга»

Как фокус на занятости может повлиять на качество и гибкость в командах

О чем статья

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

Системные диаграммы

В статье некоторые концепции объясняются при помощи системных диаграмм (Causal Loop Diagrams).

Фокус на индивидуальной занятости снижает скорость

В первой части статьи мы подробно обсуждали, почему узкие специалисты в команде, работающие над “своими” задачами в Спринте, снижают общую скорость (Cycle Time) команды. Все дело в том, что узкие специалисты создают островки очередей. Когда возникает новая работа, то она помещается в конец очереди.  А это влечет за собой увеличение общего времени выполнения задачи, ведь Cycle Time = Queue Time (время простоя в очереди) + Service Time (время работы над задачей).

Читать далее «Как фокус на занятости может повлиять на качество и гибкость в командах»