Dmytro Yarmak: Аgile? Ви зрозуміли його неправильно
•
2 likes•202 views
Dmytro Yarmak: Аgile? Ви зрозуміли його неправильно Kyiv Project Management Day 2021 Spring Website - https://pmday.org Youtube - https://www.youtube.com/startuplviv FB - https://www.facebook.com/pmdayconference
Recommended
Recommended
More Related Content
Similar to Dmytro Yarmak: Аgile? Ви зрозуміли його неправильно
Similar to Dmytro Yarmak: Аgile? Ви зрозуміли його неправильно (20)
More from Lviv Startup Club
More from Lviv Startup Club (20)
Dmytro Yarmak: Аgile? Ви зрозуміли його неправильно
- 1. Agile? You might got it wrong!
- 2. Немного о себе: • Release Train Engineer, @SimCorp • Agile & Organisational Coach, @agiledrive • Professional Coach & Facilitator • 13 лет в IT Common Sense Master Phychological Safety Make it Simple Scrum can Scale
- 5. Это может нарушить психологическую безопасность команд! Psychological Safety
- 9. Односторонний фокус на Психологическую безопасность может привести к: Страху челенджить команду Давать меньше конструктивной обратной связи Не задавать “неловкие” вопросы Psychological Safety
- 10. Ты не должен говорить, что и как делать! Servant Leadership
- 12. “a servant leader leads and that the team follows, but follows by choice.”
- 13. Ситуационное Лидерство Методы принятия решений: - Авторитарный - Консультативный - Групповой Высокая мотивация Низкая мотивация
- 14. “Неправильное” понимание Сервант Лидершипа может привести к: Отсутствию лидершипа. Избеганию принятия решений. Популизму. Саб-оптимизации. Однобокого лидершипа. Servant Leadership
- 15. А давайте спросим команды! Teams Engagement
- 20. Злоупотребление вовлечением команд может привести к: Усталости команд. Снижению скорости принятия решений. Игнорированию сообщений. Уменьшению вовлеченности команд. Teams Engagement
- 21. Тебе нужно делегировать! Твои команды должны быть самоорганизованными! Delegation & Self- organization
- 26. Договаривайтесь “на берегу”, что вы подразумеваете под самоорганизацией. Обозначьте, где полномочия команды начинаются и где они заканчиваются. Делегировать нужно по разному, не всё и не всем. Определите, куда вы движетесь для повышения уровня самоорганизации. Delegation & Self- organization
- 27. Agile команды должны быть кросс-функциональными и кросс-компонентными! Teams structure
- 29. Teams structure
- 30. Не только кросс-функциональными командами едиными. Не только кросс-компонентными командами едиными. Teams structure
- 31. Сотрудники и команды должны Ти-шейпиться! T-shaping
- 36. Важна стратегия развития команд. Баланс между интересом команды, видением продукта и архитектуры. Важность понимания когнитивной загрузки команды. T-shaping может привести к большим потерям переобучения, не ассоциации команды с продуктом, не создания длительных отношений с клиентом. T-shaping
- 37. Мы не контролируем, мы доверяем командам. Metrics
- 40. @TroyMagennis
- 41. @TroyMagennis
- 43. Данные - основа эмпирического процесса. Команды можно и нужно сравнивать, но сравнивать с общим трендом и сравнивать саму с собой. Через страх быть лидером, который “контролирует”, мы перестаем использовать данные, что ведет к уменьшению возможностей для обучения и улучшения. Metrics
- 44. Experimentation towards Agile itself
Editor's Notes
- Всем привет. Спасибо, что пришли послушать мой доклад. И спасибо, что все с включенными камерами :) Вообще очень необычно после долгого перерыва вернуться на конференции и выступать не сидя на монитором. Хочу начать свой доклад с замечательной истории. Учитель математики младших классов, спрашивает у шестилетнего ученика: “если я тебе дам одно яблоко, еще одно яблоко и еще одно яблоко, то сколько у тебя будет яблок?” Сколько это получается? Через несколько секунд мальчик уверенно говорит: “Четыре” :) Учитель немного встревожился так как ожидал получить правильный ответ на такой легкий вопрос. Может ребенок не расслышал. “Послушай, пожалуйста, еще раз. (Наши учителя бы тут добавили ВНИМАТЕЛЬНЕЙ :) ) Это очень просто.” “если я тебе дам одно яблоко, еще одно яблоко и еще одно яблоко, то сколько у тебя будет яблок?” Мальчик заметил расстройство на лице учителя и начал внимательно пересчитывать на пальчиках и в этот раз сомневаясь ответил снова: Четыре. Разочарование явно проскальзывало на лице учителя. Она вспомнила, что ученик любит клубнику. Может это поможет ему сфокусироваться. “если я тебе дам одну клубничку, еще одну клубничку и еще одну клубничку, то сколько у тебя будет клубничек?” С сомневающейся улыбкой мальчик ответил “Три?” Учитель победно заулыбалась, осталось разобраться с яблоками. “Теперь, если я тебе дам одно яблоко, еще одно яблоко и еще одно яблоко, то сколько у тебя будет яблок?” “Четыре” С закатывающимися глазами, учитель спросил “Как? объясни мне как?” “Потому что у меня уже есть одно яблоко в рюкзаке” История, которая хорошо иллюстрирует, что ответ, который отличается от того, который вы ожидали, не всегда неправилен. Иногда может быть обстоятельства, которые мы просто не понимаем. Я вижу аналогию с этой историей с тем, что происходит со многими важными аспектами, понятиями, утверждениями, тесно связанными с движением Agile. И в моем докладе мы поговорим о том, что зачастую смысл этих понятий и восприятие (лидерами или членами команд) - очень разнятся.
- Немного о себе. Меня зовут Дмитрий, работаю Release Train Engineer (либо простыми словами Скрам Мастер Скрам Мастеров) в компании SimCorp. До этого работал на различных позициях: разработчиком, тестировщиком, тим лидером, менеджером, скрам мастером. На данный момент я Аджайл коуч либо Скрам Мастер Скрам Мастеров в отделе (так называемом Agile Release Train), который состоит из 14 команд (7 в Копенгагене и 7 в Киеве). Также частично работаю в компании AgileDrive. Последние 4 месяца помогаю одному из крупных украинских банков с аджайл и IT трансформацией. Есть у меня всякие бейджики, сертификаты, ачивки) у меня к ним ироническое отношение и поэтому я их называю своими именами)
- У меня есть опыт работы В системе команды команд. За время моего пути как лидера я поработал с примерно 30 командами из разных стран. Сейчас я работаю с 14 командами в Киеве и Копенгагене. Также у меня есть опыт работы ВНЕ системы (на англ. ON the system), которая включает 60 команд, работающих над одним продуктом. Сегодня я буду делиться опытом своих эпик фейлов понимания Agile на моем пути лидера, а также эпик фейлов понимания Agile моими коллегами.
- С чем приходится сталкиваться современному лидеру? С множеством понятий, концепций, каждая из которых должна удостаиваться отдельного глубокого изучения. По факту же, мы часто слышим про одно из понятий на одном из смежных тренингов, а может просто услышали от коллег, в лучшем случае прочитали книгу или были на посвященному этому понятию тренинге. Мало кто обсуждает это понятие, с коллегами, дискутирует, старается понять, что это означает для их рабочего контекста. И часто эти понятия очень сильно взаимносвязанны с Аджайлом. и если ты не дай боже, делаешь что-то не в соответствии с психологической безопасностью, либо против самоорганизации, либо против важности Ти-шейпинга, все, у тебя не Аджайл майндсет :) и как ты вообще работаешь как лидер у нас ) И сегодня я хочу поговорить о том, что эти понятия часто воспринимаются однобоко, немного поверхностно, иногда некомпетентно, что приводит зачастую к большому вреду для организации, команд, и для самого течения аджайл. Это основано на моем собственном опыте и на опыте моих коллег-лидеров из разных уголков нашей планеты.
- https://www.facebook.com/watch/?v=940194819724014 Давайте начнем про психологическую безопасность :) Google делал исследование, ему уже много лет и о нем очень много говорили и говорят на тренингах и такого рода конференциях они назвали это исследование Проект Аристотель, целью которого было понять факторы влияющие на эффективность команд Кто слышал про это исследование? поднимите руку Кстати, а вы знали, что они потратили на него 2 года? как вы думаете, почему? не потому что у них было в планах исследовать много команд, а потому что они не могли найти паттерн среди 180 высокоэффективных командах. Причина по которой они не могли найти паттерн, пов том, что их фокус во время интервью был на такие аспекты, как их менеджер, на обучение, время работы и т.д. Что-то что можно пощупать, осязать. после этого они начали фокусироваться на групповые нормы, что-то невидимое, принятые нормы поведения, традиции, например, никогда не повышать голос, дать возможность высказаться каждому и т.д. https://www.inc.com/michael-schneider/google-thought-they-knew-how-to-create-the-perfect.html#:~:text=Fast%20forward%20two%20years%2C%20and,a%20dream%2Dteam%20generating%20algorithm. Так вот, психологическая безопасность была определена как ключевой фактор для формирования высокоэффективной команды. А теперь давайте представим лидера, который получил эти знания, узнал про это исследование. Конечно, он фокусируется на то, чтобы в команде была психологическая безопасность. А что, по вашему, это такое психологическая безопасность? menti.com Through its research, Google made the ancient Greek philosopher Aristotle proud by proving, "The whole can be greater than the sum of its parts." A situation in which everyone is safe to take risks, voice their opinions, and ask judgment-free questions. A culture where managers provide air cover and create safe zones so employees can let down their guard. That's psychological safety. Я вижу, что в погоне за психологической безопасностью лидеры стали бояться: челенджить команду; давать меньше конструктивной обратной связи. Пример из жизни, у нас в отделе есть такое понятие как zero defect mindset, то есть когда дефекты имеют наивысший приоритет. Мы либо видим смысл починить дефект и чиним его как первый приоритет, либо мы считаем их ненужными и мы их удаляем. Так вот в какой-то момент, когда у нас в отделе было много дефектов, мы практикуем такое понятие как стоп зе лайн, когда все команды фокусируются на починку дефектов и уменьшение уровня. В одной команде на доске было 10 дефектов, и еще было несколько дефектов из области команды, которые еще ни одна команда не взяла, и один сениор девелопер сказал, что он ничем не может помочь из этих 10 дефектов и он будет продолжать работать над фичей. Что бы я ожидал от Скрам Мастера в этой ситуации? Первое, доверие. И это то, что Скрам Мастер собственно и показал. Он сказал, что ну ок, раз так оно и есть, тогда продолжайте работать над фичей, пока остальные команды фокусируются на дефектах. Но помимо доверия я бы ожидал от Скрам Мастера задать вопрос команде, как так что опытный член команды никак не может помочь с 10+ дефектами? Если и команда скажет, что так и есть. Тогда я бы задал вопрос, а в чем собственно причина? И понимая причину можно было бы работать над тем, чтобы изменить эту ситуацию. Например, если все 10+ дефектов в области, в которой разработчик никогда не работал (что уже есть удивительным, учитывая 3 года в команде), то можно парно поработать и передать знания и т.д.
- Something that is often misunderstood about servant leadership is the idea that a servant leader is really just someone who facilitates or assists team. In fact, Greenleaf clearly says in his essay that
- Standish group report 2018
- ТОЧНО озвучить, что это интересный факт: Кто слышал такое понятие как T-shape? Стратегия развития команд важна в случае: Некомпонентных команд; Либо очень широкого продукта Отсутствие стратегии развития команды ведет к тому, что в организации присутствует очень много потерь переобучения; к неудовлетворенным командам. Для стратегии развития команд не достаточно только желания команды, необходимо понимания дорожной карты развития продукта и архитектуры, чтобы команда понимала, какие знания будут востребованы в будущем. Кстати, знаете, что лала Рассказать про компании, которые повышают после изучения новой области