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

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

А как с этим у вас в компании? Есть куда расти? 🙂 Поделитесь с вашим 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

Главная причина появления devops. Только это не еще один человек с лопатой, как принято считать во многих компаниях, где есть должность devops инженера. А это когда лопата у единорога в руках:)

fb напомнил, 5 лет назад. получили полномочия на Agile, который может противоречить устоявшемуся процессу :)