И в продолжение темы с самоорганизацией

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

Предположим, команда решила пойти по пути A, хотя мы (с нашей менеджерской колокольни) уверены, что правильный путь A' или даже B.
Но ведь невозможно построить самоорганизацию, запрещая людям поступать правильно (по их мнению).

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

Прекрасная цитата, отражение которой должно появиться в культуре каждой современной компании: "Sometimes you succeed, sometimes you learn.”

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

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

А как с этим у вас в компании? Есть куда расти? 🙂 Поделитесь с вашим HR

Очень крутая аллегория - ребята в Biocad написали свое ПО для kanban проектов и назвали его Репка.
Вытягивание типа (pull). Naming огонь🔥

http://www.hrmexpo.ru/exhibition/agenda/view/dizayn_organizatsionnykh_izmeneniy/

Кратко про ретроспективы. Часто бывает, что вытащить команду на целый день не получается, а тут 2-4 часа и парни готовы пробовать новые идеи. А еще паззл в головах сошелся, зачем ретроспективы вообще и как и почему они работают. Хорошо же

Мастерство делегирования.

Огромная проблема большинства компаний в том, что руководители решают вопросы в парадигме «моя задача поставить задачу своим -1».

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

Или, например, ключевое для бизнеса ИТ решение не внедряется в срок. Уже в третий.
CEO зовет в свой кабинет директора по ИТ и песочит его. На выходе новый дедлайн и коммит на его выполнение.

Хотя, если вдуматься, можно увидеть две истории:
- недостижение результата - это проблема бизнеса в целом, а не отдельного директора департамента. А это уже уровень именно CEO.
- если бы директор департамента знал, как исправить или недопустить проблему, он бы это давно сделал:)

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

Интересная статья Алексея Яна про адаптацию и развитие сотрудников в компании.

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

А теперь самое интересное - почему бы эти практики не использовать для наших внутренних клиентов, то есть сотрудников компании?

Внимательно изучить опыт сотрудников в точках контакта с организацией, построить Employee Journey Map. И тогда станут очевидными многие из вещей, которые можно улучшить прямо сейчас. Сделав шаг в сторону организации как места, где люди работают с удовольствием.

https://onagile.ru/trends/talents/employee-journey-map

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

Про митинги, которые нужно высиживать до конца

Очень рекомендую пост Андрея (CEO Cognitive Technologies) о том, сколько времени впустую мы тратим на встречи, хотя вопросы можно было бы решить за несколько минут.

Я помню в некоторых крупных компаниях, назначаешь встречу на четверых, а приходит 12 человек. Спрашиваешь, а кто эти люди? Говорят это наши замы. Без них мы не можем обсуждать ничего и принимать решения (wtf?). Банки, телеком и нефтянка здесь лидеры, по моему опыту.

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

А когда вы последний раз завершили встречу и разошлись на 15 минут раньше времени ее окончания? 🙂

https://www.facebook.com/photo.php?fbid=361743651019776&set=a.111637802697030.1073741828.100015524319525&type=3&permPage=1

Сегодня получили самый лучший RFP, который мне доводилось видеть.

Идеально описано все, включая проблематику. В команде 6 разработчиков, нужно дотюнить scrum и наладить общение с бизнесом.

Ирония в том, что только писать этот документ и проводить по нему отбор заявок дольше, чем решать исходную задачу:)

Хороший пример попытки внедрения agile, используя pmi-ный подход. Уж с ежом. Делаем ставки

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

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

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

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

Если раньше, в функциональной структуре, их развивал непосредственный руководитель: делился опытом, отправлял на обучение и тп, то как теперь, когда продавцы распределены по продуктово-сервисным командам?

Хорошо работающий инструмент здесь - это Community of Practice (CoP). Люди внутри компании собираются по интересам и развивают компетенцию (например, продажи) внутри своего сообщества. Делятся опытом, обсуждают новые идеи, тренды, и тп.

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

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

Да, команда будет ошибаться, иногда эти ошибки могут быть очень неприятными - зато это отлично работает на самоорганизацию, самостоятельность и внутреннюю мотивацию команды.

Без права на ошибку не может быть развития. 🧠💪

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

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

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

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

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

И да, пара свободных штатных единиц за счет отсутствующей роли ПМов:)

Интересная метафора - организация, как политическая система

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

Положения об организационных изменениях:
- Изменения не будут иметь успеха, если их не поддержит влиятельный человек
- Чем больше сторонников у изменений, тем лучше
- Необходимо знать политическую карту и понимать, кто в результате изменений выиграет, а кто проиграет
- Среди эффективных стратегий — создание новых коалиций и повторное обсуждение вопросов

Встречали организации такого типа? Я да, причем обычно это большие, полугосударственные коммерческие структуры.

Мне понравилось: Минутка мудрости от Джона Седдона: Попытки изменения культуры организации - это глупость, они всегда проваливаются. Поведение людей (культура) - это продукт системы. Поведение людей меняется тогда, когда вы меняете систему.

Один из лучших роликов на русском языке на тему "Что такое Agile" - https://www.youtube.com/watch?v=VRIevtlCdc4

Есть проблема, много ребят в России пишут статьи и снимают видео (иногда анимационные) на эту тему, но очень часто в них есть серьезная путанница или недопонимание самими авторами концепции и границ Agile. Потом эти видео смотрят обычные люди, пытаются наложить на свою работу и понеслась - у кого что.

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

Влияние матрицы 2х2 на развитие современного менеджмента:) Удивительно, но просто нарисовав такую картинку на встрече, можно словить пару сильных инсайтов. Как мы сегодня

Я знаю, среди вас точно есть люди, которым это будет интересно.

Антон Зотин покопался в русском переводе Scrum Guide (руководство по Скраму) и начал описывать неточности перевода. В некоторых случаях, концептуальные.
Не то, чтобы мир от плохого перевода на русский стал хуже. Но это очень познавательно, почитайте 🙂

"Скрам — это фреймворк, предназначенный для разработки, поставки и поддержки сложных продуктов."

В оригинале “complex”. Данное слово несёт чуть другую смысловую нагрузку, чем слово “сложный”. Для понимания рекомендуется погуглисть complicated vs complex, а так же почитать работы Дейва Сноудена. С потерей данных смыслов теряется и огромный смысловой пласт лежащий в основе Скрама.

https://medium.com/@antonzotin/the-scrum-guide-official-russian-translation-inconsistencies-intro-75a7f37e7012