Короткая ссылка: AgileDays-2019

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

Потому будут конспекты и посты с докладов, в которых было много концептов и много практики. И тут уместно отметить призыв Бориса Вольфсона на открытии (мой пост): "Не верьте, что вам будут рассказывать эти два дня я и другие спикеры, относитесь с полным недоверием. А в понедельник придите на работу и проверьте на практике :)"

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

И еще надо отметить, что на конференции было много общения, можно было поговорить с докладчиками о своих проблемах и вопросах, можно было обсудить свои кейсы с другими участниками и послушать их, а можно было обсудить кейсы в Agile-клинике, в которой был канбанолог, скраммолог, продуктолог agile-акушер и много других. И Асхат Уразбаев, которого на открытии назвали "agile-пенсионер" как главный врач-консультант. А еще можно было сделать селфи с картонными фигурами гуру аджайла и с медведем. Впрочем, активный нетворкинг, открытая обстановка и атмосфера сотрудничества всегда характерны для AgileDays, как и для других современных конференций.

Инсайты конференции

Трассируем мотивацию и коммуникацию до моделей психики и мозга

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

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

Нельзя оценивать человека, даже позитивно, говорить "ты молодец". В удачном случае он просто примет к сведению и продолжит свою работу, а в неудачном на базовом уровне реакций (рептильные отделы мозга, внутренний крокодил) у него возникнет вопрос "А кто ты такой, чтобы меня оценивать?". Потом на рациональном этот вопрос получит ответ, но осадочек-то останется.
Нельзя давать обратную связь неожиданно, например, просто зайдя в комнату. Если он в невротическом состоянии, то он на базовом уровне испугается вторжению в личное пространство. И вообще будет парадокс: вы похвалили, а человек начал бояться открывающейся двери "А-а, мне обратную связь могут дать". И рационально это очень тяжело гасится.
Надо связывать обратную связь с конкретными поступками, хвалить за результат или за поведение, или, наоборот, фиксировать нежелательность поведения или ставить точку на отсутствии ожидаемого результата. Часто думают, что человек сам догадается - не догадается.
Чтобы связь с поведением или результатом установилась, надо сначала прогреть кусочек коры (часть нейронной сетки), содержащий соответствующий рабочий контекст. Это делается разговором не менее 10 минут, иначе есть риск не прогреть. Понятно, что 10 минут - это дофига, но если вы не можете поговорить с человеком 10 минут о рабочем контексте, то оставьте свою обратную связь себе.

Вот такой посыл. При этом, помимо условий, еще есть конкретная рекомендация, основанная на протоколе авторизации результата, о смотри в моем конспекте доклада дальше.

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

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

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

Это был первый инсайт. Для тех, кто заинтересовался и хочет больше узнать об этих механизмах - можно смотреть доклады Анны Обуховой. Записи конференции будут опубликованы, но она начала рассказывать об этом уже несколько лет назад, и ее доклады есть на youtube, например Как не угробить людей фидбеком, Хочу/буду и деньги. Мотивация Agile команды, Утомленные Аджайлом: как коучить уставшую команду и другие.

P.S. Свежие доклады Сколько нужно энергии для работы Scrum Master, Product Owner и Agile Coach? (CodeFest-2019) и Саботаж — понять и не простить опубликовано.

Такты дальнейшего развития бизнеса детализируются

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

Сейчас многие компании создают зеленую среду для самореализации. Но при этом изо всех сил стараются передать это сотрудникам, выведя его на желтый уровень самостоятельного осознанного развития.
Как только сотрудник учится это делать, у него появляется компетенции управления собственной энергией, развития и самоопределения, то он перестанет быть привязанным к одной команде, у него станет несколько активностей, и он начнет осуществлять арбитраж.
Если ты умеешь сам управлять внутренней энергией, балансом между работой и семьей, работой и отдыхом - ты можешь делать арбитраж между работой в нескольких командах. Потому что умея удерживать 2-3 нитки развития (работа в команде, семья, обучение, хобби), к ним легко можно добавить еще парочку интересных проектов разных команд. С учетом скорости переключения контекста и прочих накладных расходов, которыми ты умеешь управлять.
А если ты можешь делать арбитраж между командами, то можешь делать арбитраж между командами разных компаний, выходишь за их границы. И полем твоей деятельности становится весь мир, при этом ты можешь одновременно участвовать в нескольких глобальных проектах.
А параллельно ты осознанно рефлексивно осваиваешь понимание работы собственного мозга, о чем речь шла в предыдущем инсайте. Это получается необходимая поддержка в квадранте Я-внутреннее (по Уилберу) для изменений во внешних активностях. Последствия этого такта развития пока не очевидны, но они явно будут. Вполне возможно, будет синтез между представлениями и техниками медитативной осознанности разных видов и представлениями о психических и нейрофизиологических моделях. И они могут привести к выходу на следующие уровни.

Новый менеджмент осваивается уже не пионерами, а входит в повседневность

Если в отчете о прошлой AgileDays я писал о волне широкого распространения Agile за пределы IT, то на этой ясно видно, что вслед за волной пришло успешное освоение. Доклады про Agile делаются не в залоге обсуждения первых экспериментов, о которых рассказывает Agile-коуч, пусть в паре с руководителем. Теперь их делают руководители, которые показывают содержание изменений и детали. Это было видно по осенней Agile Business (отчет), и это развивается сейчас.

Это показывают такие доклады, как "Канбан на литейном заводе" Нурмагомеда Джафарова, "Как в Agile войти не в IT. 550 дней Agile в операционном управлении банка Агророс" Дмитрия Кондрацкова. Доклады делали не Agile-тренеры, а руководители: Нурмагомед Джафаров - заместитель генерального директора Литмашдеталь, Дмитрий Кондрацков - председатель правления банка Агророс. Отмечу, что как-то не ожидаешь, что выступление о внедрении Agile в банке на AgileDays будет делать председатель правления. И было много других докладов из производства, в том числе и целых два доклада от Северстали - Александра Колобова и Дмитрия Козлова.

Это же показывает доклад "Agile-школа: образование для поколения будущего" о применении eduScrum в гимназии 21 города Электросталь Московской области - его делала завуч Людмила Мартыненко и учительница английского Наталья Коробейникова.

И это показывает очень интересный рассказ Виталия Сытникова "Разрушая мифы: самоорганизация в производстве и продажах стройматериалов" о становлении самоорганизации в Ascott Group, компании по производству стройматериалов.

Много докладов про использование Agile в страховании и в банках, но это естественно, потому что туда Agile пришел раньше, потому что в этих отраслях бизнес очень плотно связан с IT-системами.

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

Концептуальные представления - Kanban и бирюзовые организации

Казалось бы, концептуальные представления вряд ли могут стать для меня предметом инсайта. Однако, очень качественный доклад Алексея Пименова, представившего Kanban именно как эволюционный путь развития организации, естественного становления новых ценностей позволил мне по-новому взглянуть на Kanban. До этого я смотрел на него как на мощный инструмент организации работы с потоком создания ценности, а вот взгляд на него как на эволюционную конструкцию органичного изменения был не главным. Хотя, конечно, я понимал и представлял Kanban именно как эволюционный путь, в отличие от революционного Scrum. Алексей, спасибо. Читайте конспект доклада дальше, вместе с конспектом доклада Бориса Вольфсона об опыте использования Kanban в НН.

И было два концептуальных доклада про организации будущего. Максим Гапонов рассказывал про эволюционное органичное прорастание самоуправления в метафоре фантастической истории, а Александр Горник детально рассказывал про организацию MindBox. Самое важное у Горника проявилось в ответах на вопросы - об отношении к интровертам, которые хотят просто работать. Нет задачи сделать всех инициативными. Тут другая история: если ты считаешь, что что-то несправедливо или требует изменения - то дорога открыта. А если тебя устраивает текущая работа - то ты можешь просто работать, тебе не надо обязательно голосовать или управлять. Об этом, кстати, забывают, создавая условия, при которых надо быть активным обязательно.

А теперь перейдем к конспекту докладов.

Концептуальные доклады

Анна Обухова. Саботаж — понять и не простить

Пост на FB Фееричный доклад Anna Obukhova "Саботаж — понять и не простить". Видео

Американская брошюра 1944 Simple Sabotage - инструкция по саботажу в тылу врага для тех, кто не сочувствует гитлеровскому режиму, но не готов на открытую борьбу: подсыпать песок в бензобак и другие вещи. И там раздел подорвать производительность организации. В 2015 взяли этот раздел и сопоставили с практикой современных организаций (статья). Тогда это называли саботажем, а теперь - повседневная жизнь.

Вот список топ-10 от Анны, вы все это видели:

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

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

А дальше - классификация форм с учетом личностных качеств.

Намеренный и осознанный. Человек действительно хочет сделать плохо. Потому что обидели - увольнение или не повышение.
- Когда человек собирается что-то сделать - он проговориться. И он готовиться заранее, смотрит дырки, и рассказывает о них. Даже рассказывает про будущую месть - 64% по статистики люди знали. Надо слушать.
Ненамеренный, но осознанный. Понимаю, что делаю, но не могу остановиться.
- Манипуляторы, получают результат для себя, а не для компании.
- Пограничные личностные расстройства: тревожные и другие. Обеспечить свои эмоциональные люди за счет других. И он не хочет результат, хочет эмоций и хочет сохранения статус-кво. И он будет рассказывать негативные сценарии чтобы ничего не изменилось. И чтобы сохранить много пограничников идет во власть. И у них запредельные требования по качеству работы других - но не себя, от себя не требует. Невротик под нажимом сделает больше и выгорит, а пограничник - уйдет в истерику.
Намеренный, но не осознанный. Хотел как лучше, получилось как всегда. Невротик, хочет быть хорошим. Вообще говорят, производительные. Но! ориентирован на обратную связь и как похвалили - он перестал делать, результат для себя получен, организации неважно.
- Невроз - первый учитель. Бессмысленность достижения результата ради одобрения руководства и страх перед коллективом. Террариум единомышленников, когда реально все крокодилы. Саботаж коллектива против руководства. И первые два типа корпоративных культур из Лидер и племя - оно.
- Внутренний критик. Есть у всех, на выживание вас и семейной системы. Самореализация, счастье, радость жизни - нет таких понятий. Хорошо не жили, и начинать не надо. У нас все неудачники. Убрать внутреннего критика нельзя, и ссориться нельзя - он сильнее, у него больше энергии. Подружиться - можно, с этим работают, но непросто. Когда идешь в направлении собственной мечты внутренний критик задирает тревожность вплоть до панических атак - и это признак правильно направления, он не хочет, чтобы ты был счастлив. Самоедская лайка, сомневаться в себе вместо радости от достижения результата.
Не намеренный и не осознанный.
- Биполярное эффективное расстройство. Что это было или какой новый опты? Взял все контракты, подписался на все технологии. Упс, что это было? И ты в норме или в депрессии.
- Социопатия. Синдром Аспергера. Отсутствие эмпатии: "Я просто сказал Васе, что код - г, в чем проблема?"

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

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

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

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

И когда можем рассказать - результат встраивается в идентичность.

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

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

checkup - проверяете здоровье. Сахар, витамин Д и т.п. Примеры

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

Как работать.

Намеренно осознанный - перевербовка, переговоры с конфликтологом, увольнение так, чтобы сразу ушел, с безопасником
ненамеренный осознанный - ничего. Или лечить (3%) или убирать из команды (10% токсичных), и половина из тех, кто не может в agile - такие. А так - частые дедлайны, четкие процессы, артельная работа.
ненамеренный неосознанный - тоже самое, частые дедлайны, четкие процессы, артельная работа.
неосознанный ненамеренный. тоже А еще выводить из такого состояния

Разные города саботируют по-разному.

Питер. Линяющий саботаж. Я добросовестный, здесь нет условий сделать хорошо, а плохо не могу.
Москва. Что должен специалист за 10тр - ничего и даже немного вредить. Итальянская забастовка.
Краснодар, Одесса
- Как вы хотели не это? Но я же старался
- Я знаю, что вы хотите - и побежал делать не слушая заказчика
Казань, Екатеринбург. Вот вам заказ, вот риски, вы теперь за них отвечаете - Да, все сделаем, но сломаем оборудование и обесточим две улицы.
Новосибирск - экспериментируем! Главное - процесс, и все эксперименты оплачивает заказчик.

Убираем саботаж: Убираем культуру насилия. Представлять результат. Сотрудничать с исполнителем и заказчиком. Гибкий протокол общения. И это - Agile-манифест. Противодействие саботажу сейчас - Agile. Доклад замкнулся, начался он с того, что саботаж сейчас - распространенная практика...

Анна Обухова. Производительность Agile команды

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

В комментариях к моему посту спрашивали про этот кейс. Анна говорила про fully dispersed team, Петербург с Америкой. Кейс 2006 года, ссылка на статью есть в докладе. А я в обсуждении вспомнил, что слышал от Джеффа Сазерленда в 2011 слышал кейс на SECR-2011 (видео), когда была смешанная немецко-индусская команда, которая работала в двух офисах - в Германии и в Индии, он ставил их совместную работу, несмотря на удаленные коммуникации и культурные различия. При этом на втором такте каждая из частей команды (немецкая и индусская) разделилась еще на две, и добавились новые люди. И несмотря на распределенность, получилось линейное возрастание производительности по людям.

Дальше логика доклада очень сильно изменилась. Был рассказ про историю понятия производительности. От 500 года, потому что до этого просто заливали числом рабов, и до наших дней. Из интересного - производительность крестьянина реально определялась силой феодалов, который защищал их от грабежей соседа. То есть производительность определялась просто безопасной средой. А потом безопасность начали обеспечивать города.

В городах появились артели - первые кроссфункциональные команды. Два типа: потребительская артель на рынок и эталонная, которая задает стандарты качества как Страдивари. Это mindset и работа дофамина. И те, кто работает на рынок не поймут того, кто работает на внутренние стандарты качества и наоборот. И это - типичная проблема до сих пор. Тут производительность определяет поведение.

А потом появляются мануфактуры, и производительность определяет не поведение человека, а станок. При чем это происходит на фоне последствий чумы, последовавшего голода и сифилиса, когда Европа обезлюдела. Следующая изменение - кодекс Наполеона, который породил разделение на собственников и менеджеров (это интерпретация Анны). И менеджеру не жалко не людей ни имущества собственника, он работает в короткую, все выжимая. Эпоха меркантилизма, которая привела к великой депрессии, кризисам перепроизводства и громадному негативу. И не только у рабочих, которым выжимали соки - менеджеры тоже выгорали, а владельцы впадали в депрессию от бессмысленной жизни. Есть статистика, что девушки из золотой молодежи, вступавшие в свет в 18 доживали до 27-32, а потом - депрессия, суициды, таблетки и наркотики и прочие фейлы. Меркантилизм пожирал людей на всех уровнях. И интересный тезис, что Штаты пытались решить вопрос осмысленности и сплочения через маленькую победоносную войну во Вьетнаме, которая провалилась, так же как за 60 лет раньше провалилась попытка царизма решить свои проблемы русско-японской войной.

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

И снова рассказ сильно меняется. Фреймворк современной производительности: внешняя среда, внутренняя среда, Свобода выбора (дофамин), эмоциональный фон (окситоцин и серотонин), намерение и внутри Я - знай себя. Внутренняя среда: Батарейка, управление энергией, выгорание, стрессоустойчивость. Работа мозга. модель SCARF -что приносит мотивирует и не мотивирует. Самоосознание - какой у меня психотип, какие реакции и так далее. Что меня зажигает - и выборы с учетом этого. Управлению производительностью в пост-меркантилистской субъектной среде - компетенция, ей надо учиться. Но! В 1950-х годах, чтобы станки-люди не могли взбрыкнуть убрали навык авторизации из образования в принципе. И это надо пробуждать во взрослых. И сейчас проблемы, практически эпидемия на уровне физиологии - дефицит витамина Д. Встаю уже уставший. Мотивация нормальна, а сил уже нет. Уровень витамина Д, сахара, железа, Д3. Потому что жизнь требует авторизации, актуализации, самоопределения, а человек - не может. В современной среде относиться к себе как к объекту - выгорание гарантировано. Но мир таков, и никуда нам с этого корабля не деться, надо идти вперед.

Отмечу, что доклад развернул интересную big picture. В целом она сопоставима с моей, и в логике развития я увидел собственную рабочую модель спиральной динамики, хотя и пунктиром и с вариациями. А еще осмысление доклада и породило второй из инсайтов, о которых я писал в начала отчете - про следующие такты развития.

Алексей Пименов. Скрытая механика работы Kanban Method

Пост на FB На самом деле, ничего скрытого нет, в докладе хорошо рассказано 4 шага эволюционного развития Kanban. С основным посылом, что Agile не надо продавать, а потом насильно внедрять, ломая mindset человека, изменения должны быть эволюционны и новый mindset должен мягко и естественно прорастать.

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

Никакой скрытой работы
Показывать параллельные и последовательные процессы
Обязательные и необязательные этапы работ
Никаких скрытых очередей

Бэклог - штука, где теряются обязательства, превращаясь в плоский список. Проработка backlog для планирования - это скрытая очередь. Где заморожено много денег в незавершенке.

Пример - реально как работают люди. Маркетинг. Отдел маркетинга крупной компании - это отдел ждунов. Потому что он ждет смежников.

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

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

Если они не понимают, что там твориться - возникают вопросы. В том числе - содержание проектов.

Далее - петля обратной связи, статусное собрание. Проходим по этапам. И вопрос - что надо делать, чтобы перенести на следующий этап. И тут идет "руки не дошли" - и это вешается как блокер. И они не пополняют, без всяких WIP-лимитов.

2. Вытягивание и WIP-лимиты. Мягко и постепенно, от текущего состояния. Для начала - простейший лимит - на человека. Сколько человек может взять задачи. Дальше - на команду, дальше на этапы, лимиты на классы обслуживания. Лимиты вводят постепенно, от нелимитированной к лимитированной.

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

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

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

3. Анализ метрик. Их немного, а в докладе была только одна, зато с подробным разбором. Диаграмма потока - для команды ждунов. Видно, когда возникли аппетиты к задачам, когда исчезли. Там несколько зон. Рисует линию от попадания к CEO до поставки. И длинное согласование (от 30 до 50% времени реализации, строил во многих местах). И это способ на 30-50% увеличить скорость работы. Хочешь - доверь директору по Маркетинга принимать решение без согласования.

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

4. Масштабирование системы.

а) вверх - стратегические инициативы, портфели. И на уровне команд эффективность не слишком, а вот покрытие value-stream - очень ценно.

б) горизонтальная - цепочки в value-stream

в) по горизонтальным связям и взаимным зависимостям.

Kanban-лакмус-тест.

изменило ли руководство свое поведение
изменился ли способ предоставляния услуги (все есть услуга)
изменился ли способ того, как команда дает обязательства по услуге? Есть ли SLA, вероятности
изменилась ли бизнес-модель компании по предоставлению услуги?

Если два "да" - значит правильно.

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

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

Вопрос. А вдруг кто-то берет задачу втихую? Ответ: у вас lack of leadership. И если ты занимался другим, то для начала - пусть повесит на доску. Потом объяснит, почему - у него может быть хорошее объяснение, почему он это делал. То есть важно проявить.

Прием. А что ты будешь делать сегодня? Вот это. А когда доделаешь - завтра. И ставишь точечку. И завтра спрашиваешь "доделал?". Спрашиваешь "что делал", а дальше "кто может помочь?".

Вопрос: Как работать с лимитами, когда все ждут? Ответ: для начала ставим его от факта. Важно: если человек уперся на лимит, и ничего не делает - сервис НЕ деградирует, поэтому нет цели обязательно занять. Эффективность не зависит от использования ресурсов.

Максим Гапонов. Оставьте меня в покое: я знаю, что делаю

Пост на FB Название доклада - фраза Кими Райкконен, чемпиона Формулы-1, обращенная к окружающим советникам. И, собственно, если в организации каждый будет делать то, что считает нужным, не оглядываясь на других, и при этом организации не будет нанесен вред, то это будет грандиозно. Вопрос - как это сделать? Об эволюционном становлении правил, которые это позволяют и был рассказ. С обращением к классикам фантастики - Артур Кларк, Шекли, Азимов, в метафоре истории, когда вас наняли сделать космический флот, для этого вывезли на планету. На которой намудрили что-то с атмосферой, поэтому менеджерско-коммуникативные навыки были утрачены. Собственно, когда навыки утрачены, запускается естественный эволюционный процесс, где надо учиться выживать. Для начала выигрывают те, кто умеет делать продукт от начала до конца автономно. Но дальше у них наступает перегруз, не все можно сделать целиком, и начинается объединение в команды.

Работа в псевдоплоской организации. У вам влетает задача. И вы ее делаете в четких ролях. И вдруг вы прерываетесь, есть всего 3 причины

Потому что забыли что-то запланировать
Потому что что-то неправильно с договоренностями или правилами (смежники)
Межличностные конфликты - и их надо решать

Еще засада. Пока делали сами и во-время приносили, то никого не волновало, как внутри организовано. А если делаете вместе - нужны правила. И дальше - простой свод правил - и они есть у Азимова

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

Правила принятия решений - Консент (consent)

Варианты: Автократия, Большинство Консенсус Консент
Но автократия и большинство - нарушают принцип "я делаю то, что считаю нужным и важным"
Консенсус - но реально ни один человек не согласен с консенсусным решением.
Консент - надо чтобы не было голоса против (а не были все согласны). Если голос против есть - надо интегрировать.

Нет контроля, поэтому нужна прозрачность: предзназначения (зачем существуем), роли, проекты/задачи, решения. Это все что нужно.

Дальше то, что происходило с вами - происходит с командами. И там виды совещаний.

Делание чего-либо - узнавание того, что должно быть сделано
Совместное обучение - процесс состоит из стадий
Метрики
Риски и ошибки

В книгах все это - Робертсон Холакратия - про организацию и Сесиль Грин Collab - там все типы обсуждений и фасилитационные планы для них.

Если решите это проделать в компании, будьте готовы

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

Зоны работы

Mindset - решается обучением или тренингом
Практика - это вы сами, правила надо соблюдать
Отношения -
Среда - то есть взаимодействие с окружением

В заключении. Те, кто умеет делать работу от начала и до конца - могут работать сами. Кто не умеет - должны научиться объединяться с другими или умрут.

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

В ответах - мягкий троллинг.

Никакая самоорганизация не возникает, когда есть менеджер - потому что люди придут к менеджеру.
Вопрос. Вы сказали, что нужно обучаться, а что еще нужно делать? Ответ: А ничего больше не существует. Даже когда вы планируете бюджет, вы просто учитесь отвечать на вопрос, хватит ли у организации денег.
В крупных компаниях 60-70% сотрудников координируют чью-то работу. А не приносят бизнес-ценности.
Горизонт вымирания современных крупных компаний 20-30 лет. Новое поколение не умеет работать без смысла.

Александр Горник, Mindbox. Agile чтобы что? Счастье на работе или выжимание эффективности?

Пост на FB Видео и презентация. Рассказ про Mindbox, в которой поток работы по Чиксентмихайи, мотивация по Пинку и принципы по Лалу. И сделка между компанией: вовлеченная работа сотрудника против счастья на работе, условия которого обеспечит компания. Дальше - просто конспект выступления в комментариях.

Когда мы повышаем эффективность, надо дать что-то взамен? Даем счастье. Реально. Нет менеджеров на 86 человек, много нерабочих отношений, много пар на работе. Полностью открытые зарплаты и porfit and lost компании. Высокомаржинальная. Интересно, что доля зарплат в доходе - уменьшается, это все видят и нормально воспринимают.

Анонимный телеграмм-канал, где высмеивают то, что не нравится на работе.

Поток Чиксентмихайи и Пинк про мотивацию. Счаcтье на работе == Внутренняя мотивация. Когда вы приходите и вам хочется улучшаться. Условия: большая цель, автономия, мастерство. Mindbox: мотивация по Пинку и принципы по Лалу.

Зачем это бизнесу? А потому что эти принципы позволяют строить высокоэффективную компанию. Сделка: ты работая эффективно и вовлекайся, а мы создадим условия для счастья на работе.

Scrumtrek у них внедрял Agile в 2008, и они долго работали в гибкой разработки. В 2016 начали трансформацию к открытым финансам.

Признаки: польза, порядочность, автономность, эволюция

Прибыль - не цель, а метрика измеряющая полезность миру. Долговременные отношения с клиентами через разные формы.
Открытые зарплаты, открытый profit and lost, открытые расставания. И открытое обсуждение проблем вокруг.
Но: к этому надо идти постепенно, не делайте резко. Начинали с раскрытия новых на групповых собеседников, раскрытия грейдов, раскрытия метрик. В Норвегии - открытые зарплаты и доходы, и на самом деле это с 1814.
Публичные цели и результаты - доска в трелло, где есть цели и есть зарплаты.
Публичная обратная связь - тоже через Trello, карточки на похвалу и на увольнение с обсуждением причин, а не на фиксацию процесса.
Доступные топы.

Автономия: любой может принять любое решение, любой может наложить вето с дальнейшим разрешением конфликта. Публичное уведомление - за счет того, что любое решение - карточка трелло, уведомления идут автоматом. Хочешь контролировать - смотри уведомления и останавливай конвейер. И по этому же workflow идет работа с зарплатой: ставишь карточку "повышаю себе зарплату", и если за установленный срок (за неделю) не прилетело вето, то карточка уходит на исполнение в бухгалтерию.

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

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

Бирюзовая организация - группа команд, которые согласились платить налоги на общее дело. Найм силами команды, а не впихивание людей, ретроспективы, метрики performance команды.

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

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

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

Netflix - топ-500 зарплат открыты.

Вопрос - какие пределы роста? Росли всегда быстро, но органично. Предел роста 40% в год.

Красота формулы "любой может принять любое решение" - оно, в том числе, перейти в авторитарный режим в кризисе. Прецедент - когда открыли зарплаты, то промахнулись в планировании и не хватило денег, надо было кого-то уволить. Они тогда как раз открыли profit and lost. И провели голосование, вдруг люди согласятся понизить зарплаты на 10% и никого не увольнять. Результат голосования был - зарплаты не понижать, выберите, кого уволить, мы согласны.

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

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

Про интровертов. Нет задачи сделать всех инициативными. Тут другая история: если ты считаешь, что что-то несправедливо или требует изменения - то дорога открыта. А если тебя устраивает текущая работа - то ты можешь просто работать, тебе не надо обязательно голосовать или управлять.

Про зарплаты. И не хотят повышения зарплат, когда видят, что нет денег. Разработчики, когда открыли P&L - пошли и оптимизировали железо. Люди - хорошие.

Примеры сложных решений. Были сложности с разработкой, но программисты как способ борьбы с этим предложили "давайте еще 4 часа свободного времени". У не-разработческой части полыхнуло, но потом решение приняли и сейчас уже видны преимущества.

Юлия Баринова о культурной составляющей agile-трансформации и о граблях

Пост на FB Это была часть из совместного с Дмитрием Козловым доклада. Рассказ про большое количество граблей несовместимых элементов при внедрении Agile, когда новые процессы пробуют внедрить без демонтажа старых практик. И возникает резкое противоречие, потому что командная работа плохо совместима с индивидуальным KPI, самоорганизация - с сохранением прямых указаний от менеджеров и так далее. И дальше agile-процессы не работают. Так же как ориентации на клиента нельзя достигнуть, если существенная часть компании занимает позицию: ублажать клиента - ваша задача, а наша - спасать компанию от рисков. В общем-то вещи известные, только почему-то регулярно воспроизводятся при попытках внедрения.

А еще большая часть была про культурную составляющую, на которую надо обращать внимания. Правда, моделей тут не было, но общие опорные точки, создающие среду, побуждающею людей к изменениям - были: осмысленность (зачем меняться, какие проблемы решаются), поддержка (терапия, коучинг) и неизбежность перемен (поэтому "пилот" - не слишком хорошо).

Денис Сальников. Отпускаем команду в свободное плавание: как, когда и почему?

Пост на FB Интересная и новая для меня ссылка на 8 stances of scrum master

servant leadership
coach
facilitator
teacher
mentor
manager
impediment remover
change agent

Это свидетельство последовательной проработки деталей работы с soft skill, появления адаптированных моделей - как рост отрасли.

В целом доклад - про жизненный цикл команды, который, естественно, начинается не с формирования команды и постановки процессов, а с оценки/формирования культура и ценности организации, затем миссия и видение продукта, его метрики. И только потом - фундамент Scrum, потому что рамочная цель есть, без нее не интересно.

Для культуры организации - Модель Шнайдера. И я, пожалуй, в первый раз понял, что это кусочек модели спиральной динамики. Может быть потому, что услышал от нее на выступлении Асхата в 2013 (мой отчет http://mtsepkov.org/SPMconf-2013), когда со спиральной динамикой только начал знакомиться, она показалась мне поверхностной и потому я потом не углублялся. Вот соответствие культур и уровней.

Контроля - Успех за счет поддержки и контроля -- синий
Компетенции - Успех потому, что мы лучшие -- оранжевый (да, компетентные индивидуалы)
Взаимодействия - Успеха добьемся только вместе -- зеленый
Роста и развития - Успех потому, что мы правильно растем -- желтый

В комментариях Artem Serdyuk написал, что Майкл Сахота, который принес модель Шнайдера в Agile-контекст, сейчас от нее отказался и перешел на спиральную динамику (модель Лалу, как он ее называет) - об этом есть его статья, где явно указано, что в 2016 году он перешел на модель Лалу.

А в докладе далее было про формирование команды и ее становление, а потом - про отпуск в свободное плавание. И тут стоп-факторы

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

А для мониторинга здоровья подходит Spotify Squod Health Check

Bjarte Bogsnes. Beyond Budgeting

Пост на FB В перерыве забежал на рассказ Bjarte Bogsnes про Beyond Budgeting. Я слушал его два года назад ITSpring, и он произвел большое впечатление продуманным рассказом про гибкое устройство финансирования инициатив в большой корпорации вместо традиционного бюджетного подхода. Поэтому я не мог не посмотреть сейчас, хотя слушать все-таки предпочитаю новое для себя. В моем отчете http://mtsepkov.org/IT_Spring-2017 можно найти подробности и, главное, ссылку на видео - потмоу что с последних AgileDays выкладываются далеко не все доклады, а сильно избирательно. И даже для участников доступ к записям ограничивается по времени.

Patrick Kua. Создание эволюционирующих архитектур

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

Обвязка процессов - в докладе есть. Сontinious delivery с книгами (и без содержания). Тезис о том, что старые процессы, когда архитектурные решения принимались в начале, и за счет этого easy staff делал реализацию больше не работают, процесс инкрементален. Список практик поддержки архитектуры с деланием на новые, способствующие гибкости и более не работающие old school практики. Тесты, включенные в delivery pipeline, включая тесты производительности - это правильно, понятно, но очевидно. Это - все знают, хотя не у всех есть. И никто не сомневается, что по-хорошему это нужно, только не все понимать, как сделать в условиях своей компании. А вот об это в докладе - НИ СЛОВА.

И про архитектуру - почти ни слова. Только во второй половине доклада - схема вариантов big ball, layer, kernel, microservices, которые известны сто лет назад, и объяснение о том, что big ball - плохо, что в layer запрос на изменение идет через все слои, что при ядре все хорошо, пока не надо менять ядро, а микросервисы как раз позволяют менять локально. Очевидные и известные вещи. Очень обидно :(

А дальше - организация разработки через feature team, а не функциональные отделы фронта, бэка и БД. И немного слов про Principle driven architecture, тоже без раскрытия. Единственный паттерн - написать адаптеры для маршрутизации обращений и скрытия внутренней структуры. И призыв "мыслите как при проектировании городов - как будто это очевидная и общеизвестная практика. Многие ли проектировали города?

Architecture briefing - понятная практика, но без раскрытия, а она - сильно не простая, и наиболее известные варианты - как раз недопустимо дорогие и медленные, потому что сформированы в old school, когда архитектурные решения принимались на начальном этапе и их было мало, а не в течении всего процесса. Пара паттернов - Coding via configuration, Choosing style - тоже без раскрытия... Квадрат, что надо делать важное и ценное...

Доклады про опыт организаций

Виталий Сытников. Разрушая мифы: самоорганизация в производстве и продажах стройматериалов

Виталий Сытников из Ascott Group: 200 сотрудников, 40% рынка обойного клея. 12 филиалов по России и СНГ, 247 городов присутствия. Обойный клей KLEO, и смежные вещи. Про компанию можно подробнее посмотреть на их сайте.

История развития самоорганизации в компании, которой он хотел развеять мифы:

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

И ему это удалось.

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

В конце 2016 года - кризис, в течении полугода сменилось 3 директора за полгода, что-то не получалось. И тогда производственники предложили менеджменту: давайте не будем искать четвертого, а попробуем сами. Сформировался совет производства и наиболее идейных сотрудников. Поставил правила игры, много достижения. Менеджмент - шаблонное мышление, транслирование информации, царизм. А тут получилось экспертное отношение, вовлеченность сотрудников и доверие. Модель была успешна.

Но дальше такая структура сработала как бомба. В 1 декаде 2018 ушло 5 топов компании: управляющий, по производству, по развитию, коммерческий и кадров. Часть - потому что сотрудники снизу начали давать отрицательную обратную связь по директивному управлению. И тут Николя объявил: Топ-менеджеров больше набирать не будем. И вместо менеджеров появились советы - команда сотрудников, объединившаяся добровольно для решения каких-то вопросов. Советы - добровольные, только один сделал Николя - совет-правление. Совет менеджеров, кадровый, коммерческий, производства, развития - в общем, примерно по ответственности топов.

Реперные точки. Создать может любой сотрудник (если это не заблокирует правление). Должен сформировать положение: смысл, какую ценность несет совет, и процедуры. Совет обязательно ротируется (частично) каждые 3 месяца. И кроссфункциональность, для них это наличие нецелевого сотрудника, обеспечивающего взгляд со стороны. Кроме основных - громадное количество других рабочих групп разного характера. Создали, начали работать, думали, что поймали дзен. Не получилось - фасилитация, тайм менеджмент стреляла. Но справились.

Принципы

Публичность - всех советов
Свободный доступ к протоколам
Ежемесячные опросы
Опросы 360

Не эффективных советов не было, совет может быть не эффективен только месяц, потом обратная связь это выявит. Есть советы, которые пока не взлетели, с этим работают.

Вопрос: А кто несет ответственность за деньги. Доходная и расходная части. Ответ: мы контролируем P&L и это прозрачно. Все понимают, жестких вопросов не стояло. Вопрос, кто принимает решение о скидках решился так: или ты доверяешь или нет? Если доверяешь - то доверяешь до конца и каждый имеет право на решения по скидкам и по суммам. Но при больших суммах обязательна консультации.

Ротация совета - на самоорганизации. Ротация частичная, и совет должен принять новых. А еще участие в совете - добровольное, оплачивается, но не освобождает от основной работы.

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

В комментариях к посту Виталий уточнил про компанию: производство и центральный офис - город Москва, и филиалы по России-от Воронежа до Новосиба. Плюс два внешних филиала. Зарплаты в рынке. Причем значительно. Уровень счастья и возможность повышения ЗП хороший. Есть токсичные сотрудники, но куда без них.

Дмитрий Козлов о трансформации в Северсталь

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

Тему трансформации нельзя начинать без лидера. К лидеру обращается как привыкли, а все остальное - по-новому.

директор пересел в openspace
повесил описание своей роли на видное место
повесил доску делегирования как раз в круг стратегического управления.

Это - часть их совместного доклада с Юрией Бариновой.

Об опыте Северстали на конференции еще рассказывал Александр Колобов. Я слушал его доклад полгода назад на AgileBusiness, в отчете есть подробный рассказ, и потому на AgileDays к нему не пошел.

Дмитрий Кондрацков, банк Агророс. 550 дней Agile в операционном управлении!

Пост на FB видео Неожиданно - Scrum в чистом виде. Потому что Scrum работает в запутанной системе (это по Cynefin) - вы экспериментируете и идете. А вот в сложных и простых системах ставьте Kanban - там он прекрасно работает.

История - были филиалы-добровольцы. И один из региональных офисов рванул вперед буквально за один спринт. И тогда другие офисы тоже взяли опыт. Параллельно - трансформация центрального офиса, отделы по Scrum. И дальше сверху это синхронизировали по OKR. У них 350 человек.

Продуктовые команды тоже работают по Scrum. Взаимодействие - через демо, и там возникает вовлеченность и сопричастность. А так - Product Owner.

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

Стратегия в офисе - идти от проблемных отделах. Кредитный отдел, Просрочки, Информационная безопасность и далее. Если отдел работает неплохо - не надо менять. Операционка - Kanban, а там где запутанные системы и надо отрабатывать варианты - Scrum.

В комментариях в FB был вопрос - что такое "запутанные системы". Поясняю. Это из перевода Cynefin-фреймворка. Complicated переводят как сложные, а Complex как запутанные. Кто автор такого перевода я не знаю, слышал очень давно. Я сейчас посмотрел - услышал это в 2014 http://mtsepkov.org/SECR-2014 и там ссылка на статью Дмитриева 2012 в которой перевод именно такой.

Cynefin-фреймворк делит системы на 4 типа по сложности причинно-следственных связей:

а) простые, в которых есть четкие законы устройства;

б) сложные (complicated), в которых можно установить законы путем исследования, а также изучить контекст (окружение) и дальше предсказывать последствия своих действий;

в) запутанные (complex), которые на первый взгляд состоят из объектов с поддающимися изучению законами, однако связи между объектами столь многообразны, и часто неявны, что ты никогда не можешь уверенно предсказать последствия действий - всегда есть опасность упустить что либо в контексте системы;

г) хаотические, где предсказания невозможны из-за изменяющегося контекста и правил.

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

Подробности можно почитать в вики https://en.wikipedia.org/wiki/Cynefin_framework, а у Димы Безуглого на SECR в докладе была интересная интерпретация фреймворка как стадий научного освоения мира, с постепенным переводом исследуемых областей из хаотических в запутанные, сложные и, наконец, простые.

Нурмагомед Джафаров, Литмашдеталь. История о развитии Канбан в машиностроении на литейном заводе

Пост на FB (видео слайды) История о развитии Канбан (по Андерсону) в машиностроении на литейном заводе. 20 лет, опираясь на здравый смысл, развивали организационные принципы и в отдельных рабочих бригадах добились высочайшей эффективности. И тут, окунувшись в изучение Agile, выяснили, что уровень взаимодействия литейщиков уже практически полностью соответствует business agility: на людях объединили 4 профессии в одну, так что достигли полной кроссфункциональности и взаимозаменяемости людей и способности оперативно обработать любой заказ.

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

Но тут смежник, поставщик оснастки, внедрил Канбан у себя, и у них в 1.5 раза взлетела пропускная способность и на 16% выручка, они наняли нового продажника, чтобы загрузить систему. Стали разбираться - а у них 29 человек и единая Kanban-доска для всех на 80% потока. И они поняли, что основные оканбаненные процессы - не все. Дао Тойота так и говорит: Технологический/организационный процесс требуется перестроить таким образом, чтобы сформировался поток добавления ценности. И тогда они начали выстраивать длинную последовательность досок end-to-end, вскрыли узкие участки как раз в маркетинге и продажах и начали делать отдельные доски там, чтобы изменить ситуацию. Вот такая история.

Кто такой «учитель 21 века», и почему Agile так нужен в школах. Alexey Deryushkin

Пост на FB. Внедрение scrum в школах. Это была замена в напечатанной программе, я не отследил и пришел уже на ответы на вопросы. Рассказ был про кейсы внедрения, которых немало, спросить можно в группе eduScrum Russia на FB. А из ответов интересно, что сопротивления в IT-командах больше, чем в командах в образовании.

Agile-школа: образование для поколения будущего. Людмила Мартыненко и Наталья Коробейникова, Гимназия 21

Пост на FB. В докладе завуч Людмила Мартыненко и учительница английского из Гимназия 21 подмосковного города Электросталь рассказывали о перестройке образования в школе на основе eduScrum. Отмечу, что автор eduScrum Willy Wijnands из Нидерландов был на конференции и проводил workshop.

Рассказывали реальные учителя из школы, и с характерной учительской интонацией. И это был взгляд изнутри на школу будущего, школу Agile.

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

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

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

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

Учитель английского. Работает второй год, в прошлом году - со старшеклассниками, а в этом - уже с второклассниками. Как увлечь - игра, перенос шариков между коробками. Например, не поднимать шарики. И увидели - в команде больше делаешь и работать весело.

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

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

Проблемы

Я умнее всех, работать с командой не хочу. Сделаю все сам, не хочу, чтобы троечник получал мою оценку. Это в старшем классе. Его оставляют самого, и в результате ему надо проект делать самому, это много больше работы - и к третьему проекту он хочет в команде.
Второклассница. Чувствует себя некомфортно в команде. И вот тут должен быть правильный учитель, чтобы помочь решить ситуацию, в том числе сделать комфортный переход между командами. Учителям сложнее - все дети должны учиться, нет права увольнения.
Запускается проект. Не просто проходят тему покупки и ходят в магазин, а делают дизайн-проект торгового центра. Или делали глоссарий проекта по теме атом-космос.

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

EduScrum. что и зачем ставит учитель, а вот как - сами ученики. И даже у второго класса часто хватает своих идей. И фото доски 2 класса - интересно :) В готово вместо карточек - как раз рисунки с веселым алфавитом.

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

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

Проект оценивается 3 оценками:

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

И, что интересно, scrum очень хорошо помогает в подготовки ЕГЭ, они это выяснили у старшеклассников.

А в заключении отмечу, что это еще не самая мощная трансформация в школах. В прошлом году Павел Рабинович рассказывал на AgileDays про трансформацию по Agile самих уроков, когда не учитель рассказывает теоретический материал, а ученики сами его изучают, определяя способ - вместе по учебнику, или поделив уроки между собой и рассказывая друг другу или как-то иначе, а учитель объясняет только по явному запросу. И только в конце темы - обычная контрольная работа, чтобы получить индивидуальные метрики обучения учеников, которые нормативно требуются. видео доклада, их анонс выступления Но это - средняя школа (5-6 класс), а здесь - второй, а не только старшие. И это интересно. А в комментариях к посту Павел написал, что с этого года наши дети уже в режиме Р2Р учат и своих сверстников и даже учителей. Приходите 28-29 марта пройдет http://ШколаВозможностей.рф - можно узнать подробности.

Философия Agile как основа для развития духа корпоративного предпринимательства. Евгения Дмитриева

Пост на FB Рассказ был про создание новых продуктов в Splat - парфюмерия, гигиена и т.п. Задача - сохранять творчество и качество при управлении сроками. Проекты - полу-индивидуальные: есть автор продукта, менеджер и продюсер. Фазы: Идея - Исследование - Подготовка выпуска. Для управляемости сделали прозрачность движения по фазам. Есть овеществленные результаты по вехам. В фазах есть скелет обязательных сроков, например, карантин и т.п., и фазы, которые движет автор и группа проекта. Дальше - техника, Jira сделал прозрачным ситуацию в 70+ проектов, и этого достаточно для планирования.

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

Борис Вольфсон. Kanban - Agile на стероидах

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

В целом доклад о том, как HeadHunter переходил от Scrum к Kanban. Причина: "Скажу политкорректно: с оптимизацией скорости поставки в скраме есть проблемы, а хотелось бы больше скорости". И поэтому перешли на Kanban - в scrum нет leaktime.

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

Правила команда пишет сама, и был пример правил в стиле устава монастыря :) "Греховно брать слишком много задач в работу".

Каденции - стандартные, но что-то заменено корпоративными процедурами. Демо - сохранили от Scrum, они идут вместе с ревью сервисов, чтобы распространять информацию, и ретро тоже есть (вроде не у всех команд).

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

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

Эффективность потока.

Статус между предварительной проработкой и пуском в работу
Флажок на доске "задача ждет"

62% шла работа, которая добавляет ценность и 38% ждали - это резерв. И отдельно считают discovery и delivery.

Как сочетать проектный подход с управлением по Канбану? Для проектов есть отдельна доска, фазы проектов отслеживают. Каждый проект добавляет ценности пользователям, а не просто техническая декомпозиция. LeakTime - не делали ничьим KPI и это очень важно, и и считают задачи в проработки (это треть) и в реализации.

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

Был интересный тезис, что жесткость Scrum Guide может нарушать ценность "Люди и взаимодействие важнее процессов и инструментов". Мое мнение, что это уже вопрос догматизма реализации. Любое коллективное взаимодействие подразумевает определенные правила организации, и scrum guide деат вариант таких правил, включая способ их изменения. А еще говорит, что если вы меняете правила дальше определенного предела, то из уважения к создателям метода не надо называть это скрамом, а называйте процессом на основе скрама. Вполне нормальная конструкция. Хотя я понимаю, что это у меня очень широкая трактовка :)

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

Пост на FB Ударный и искренний финал: главное - верить в свой проект по-настоящему и делиться верой с каждым. Не делайте проекты за деньги - зачем, если есть столько возможностей сделать то, во что вы верите.

А сам рассказ был про простые, но полезные практики поддержки.

weekly-status. Шаблон, который легко и быстро заполняет менеджер продукта - он это все знает. Фишка в том, что такая публикация позволяет обеспечить прозрачность.
release burndown. Идея - текущий прогноз даты релиза, которая корректируется, исходя из текущей ситуации в спринтах. При этом далекие задачи - большие и оценены грубо, этого достаточно для прогноза и неопределенности.

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

Ольга Леонтовец. Трансформация снизу возможна!

Пост на FB Это весьма интересный и поучительный рассказ. Ольга рассказывала историю внедрения Agile на своей прошлой работе, большого, но не названного банка, силами проектного офиса. Она два года назад впервые пришла на AgileDays, вдохновилась, и для нее был вызов, потмоу что говорили "внедрение из проектного офиса или HR не получается, нужна поддержка топов и полномочия". Они пошли типичным HR-путем внешних изменений: позовем консультантов и они все сделают. Руководство там кивнуло на инициативу благосклонно, потому что модно, и большой зеленый брат уже впереди. И позвали крутых консультантов - очень удобно, потмоу что они пришли и ушли, и если что - они плохие, а мы - хорошие. И вообще это просто - надо забронировать переговорки и организовать присутствие людей на обучении и все.

Были крутые консультанты из ScrumTrek, но оно не взлетело, даже на пилотных командах. Не взлетело классически: люди на обучении четко говорили, консультанты пробуют натянуть компанию на методологию, не понимая, как устроено внутри. И люди говорили, что Agile - замечательно, но совсем не для них, не взлетит. Потом консультантов сменили, но история повторилась, уже на другой команде. И только этого вскрыли разницу методологии и существующего процесса, который установлен топами. Тогда - обучили топов, обучал Асхат лично, они тоже вдохновились.

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

В целом, надо отметить, что история очень поучительна. Но грабли - они же известны. Да, могут быть неизвестны неофиту в мире Agile, особенно пришедшему из мира, где внедрение принято делать внешними консультантами. Впрочем, известно, успешность всегда сомнительна. Но Agile-консультантам-то известно, что так не работает. Тем не менее, они вели компанию по этому пути с тупиками по принципу "за ваши деньги - любой каприз". И что провал тоже является уроком, и есть надежда, что урок выучат и пройдут по пути трансформации. Что, в общем-то и получилось.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 00:25, 26 марта 2019 • нет комментариев

2019-03-26: AgileDays - много содержания и инсайтов