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

С другой стороны, мы знаем, что поиск новых работающих решений возможен только методом проб и ошибок.
Но для этого сама культура организации должна базироваться на непрерывных экспериментах и лернингах с них. 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, который может противоречить устоявшемуся процессу :)

Если нет времени полистать книгу целиком, вот summary. Я уже упоминал у ней, Лидер и Племя, помогает взглянуть на некоторые вещи по-другому. http://summary.romansergeev.com/lider-i-plemya

Кажется, индустрия моды уже готова опередить digital по скорости вывода новых продуктов на рынок.

Раньше новые модели (коллекции) разрабатывались около года.
Потом появилась скоростная Zara, которая выпускает модели за несколько недель и ориентируется на географически локальные предпочтения клиентов.
Уже неколько месяцев мы работаем с Российской 12Storeez, которые выпускают 12 (!) полных коллекций в год и растут в два-три раза за год.
Есть американская Fasion Nova, у которой предзаказ модели доступен через 48 часов, а на отшив уходит несколько дней.

В этот момент условно-отличные три недели на выпуск MVP программного продукта с нуля уже не кажутся чем-то амбициозным 🙂

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

Быстрее только печатать на 3D принтере у клиента дома, сразу после скачивания макета с сайта. Но это пока в будущем.

Отличное видео Фредерика Лалу об огранизациях нового типа. Смотреть и слушать для вдохновления, мне время от времени хорошо помогает. А Далай Лама там просто устал очень, но внимательно слушает.
https://www.youtube.com/watch?v=JMzhkPMrRA4

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

Лонгрид кейса на выходные 🙂

https://onagile.ru/industries/health/buurtzorg

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

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

Кому канбан-игру?:) Последнее время часто проводим у клиентов, work in progress лимиты хорошо заходят. Особенно в бизнесовые (не связанные с ИТ) команды