7023
правки
Изменения
Новая страница: «Файл:SpiralDynamics-InUse-Tsepkov-SQAdays-2014-2.pdf|page=40|right|thumb|400px|[[Спиральная динамика: понимай ценности –…»
[[Файл:SpiralDynamics-InUse-Tsepkov-SQAdays-2014-2.pdf|page=40|right|thumb|400px|[[Спиральная динамика: понимай ценности – и действуй! (Максим Цепков на SQAdays-16)|Из моего доклада на SQAdays 14.11.2014]]
Примерно неделю назад я прочитал [https://www.facebook.com/permalink.php?story_fbid=1980589221954579&id=100000105609030&pnref=story пост Ивана Дубровина] о том, как интенсивно шагает Kanban в традиционных госструктурах — Центральный банк, Федеральное канзначейство, региональные структуры. И в коментах мы обсудили, как там строят Kanban-доски при внедрении. Оказывается — по полной программе, с рассмотрением организации в сервисной модели, определением '''создаваемых ценностей подразделением'''. И я подумал, что это — очень радует. Происходит разморозка, возвращение смысла в деятельность организации.
Большим организациям свойственно бюрократизироваться, это в середине века исследовал Крозье ([[Блог:Максима Цепкова/2017-12-30: Как побудить организацию к изменениям|я об этом недавно писал]]), об этом же говорит жизненный цикл корпорации Адизеса, по которому корпорация уходит в аристократизм и бюрократию, а затем умирает. А Kanban — способен ее эволюционно оздоровить. Здесь уместно вспомнить схему из Спиральной динамики на рисунке справа. Она говорит о том, что эволюционные изменения возможны только если разрыв между состоянием организации и окружающим миром — не слишком велик, иначе необходима революция. Таким образом, эволюционное, а не революционное развитие наших крупных государственных организаций, откликающихся на внедрение Kanban, означает, что в целом наше государство в целом адекватно потребностям общества, способно к изменениям и развитию, и делает это. Что не может не радовать.
Собственно, я бы написал это неделю назад, но примерно тогда же на FB началась еще [https://www.facebook.com/groups/agilebeyondit/permalink/876119699236751/ одна интересная дискуссия] о том, что лучше для команды, переходящей на Agile — Scrum или Kanban. Там тема Kanban, его отличий от Scrum была достаточно активно затронута в обсуждением с Алексеем Пименовым, и я решил сначала завершить обсуждение там.
[[Файл:AgileTealOrg-HSE-2018-03.pdf|page=17|right|thumb|400px|[[Методы Agile и бирюзовых организаций для организации работы креативных команд (лекция 03.03.2018 ВШЭ СПб)|Из моей лекции в ВШЭ 03.03.2018]]
И здесь надо отметить, что для новой команды основное отличие Scrum от Kanban — как раз в эволюционном или революционном изменении не столько процессов, сколько системы ценностей. У любой организации есть две стороны, культура и процессы. Есть красивая схема-метафора кораблика, показывающая этот дуализм и придуманная Марком Розиным. И справа на схеме показана конструкция Agile в этой метафоре. Я тут процитирую один [https://www.facebook.com/groups/agilebeyondit/permalink/876119699236751/?comment_id=876165545898833&comment_tracking=%7B%22tn%22%3A%22R9%22%7D свой комментарий] из того поста — но советую прочитать всю дискуссию, а может — и принять участие.
<blockquote>
У этого вопроса есть два аспекта: ценности, процессы. С точки зрения процессов выбор зависит от того, есть ли в работе реальное квантование по поставке ценности потребителю — выпуск релизов. Scrum ориентирован на разработку, в которой ценности поставляются пакетами. Сейчас это, отчасти, снимается практикой continuous delivery, однако если новый функционал необходимо рекламировать, привлекать пользователей, то это все равно делается периодическими компаниями. А вот Kanban ориентирован на непрерывный поток задач, каждая из которых несет самостоятельную ценность и изолированно доставляется потребителю.
А вот с точки зрения трансформации культуры и принятия новых ценностей Scrum — гораздо лучше, потому что он резко перестраивает процесс, что влечет за собой осмысление и принятие людьми нового подхода к работе — или, наоборот, четкий провал в случае неприятия. Это происходит благодаря многочисленным встроенным встречам, которые значительно сфокусированы на ценностях, благодаря постановке целей на каждый спринт и другим подобным аспектам. И Scrum очень сложно внедрить без трансформации культуры. А Kanban с точки зрения ценностей — гораздо мягче, он вписывается в любую культурную среду, постепенно размораживая ее благодаря визуализации потока ценности, и благодаря старту постоянных улучшений. Поэтому его внедрение проходит мягче, но больше опасность, что трансформация будет ограниченной и затухнет. В IT это не слишком проявляется, потому что Kanban появился позже, чем Scrum, основные ценности и принципы Agile-манифеста уже были приняты сообществом, проявились успехи, и на повестку дня встал вопрос о мягкой трансформации больших компаний (ну и о работе с эксплуатацией и развитием систем, где нет четких релизов). Именно Kanban хорошо подходит для эволюционного размораживания и оздоровления больших бюрократизированных структур — он через доски workflow и побуждает задавать вопрос — несет ли конкретная работа ценность потребителю или нет, и кто вообще является потребителем для работ конкретного подразделения.
Если в терминах Спиральной динамики — то Kanban — может хорошо оздоровить бюрократизированный синий, без трансформации на следующие уровни (но в перспективе — трансформация запускается), а Scrum — пробует дотянуть до желтого достаточно интенсивно.
</blockquote>
[[Файл:AgileTealOrg-HSE-2018-03.pdf|page=59|right|thumb|400px|[[Методы Agile и бирюзовых организаций для организации работы креативных команд (лекция 03.03.2018 ВШЭ СПб)|Из моей лекции в ВШЭ 03.03.2018]]
Последний абзац как раз иллюстрирует вторая схема. После того, как Agile успешно развился и вышел на желтый уровень Спиральной динамики, как показано на левой, восходящей, ветви, и его методы доказали свое конкурентное преимущество, начались многочисленные попытки взять при внедрении только процессную часть Agile, не меняя ценности компании. Это показано на левой, нисходящей ветви. Впервые я показал эту схему в [[Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017)|выступлении на AgileBusiness-2017]], и на него был [https://www.facebook.com/photo.php?fbid=1668633256508140&set=a.702402356464573.1073741827.100000844450291&type=3 комментарий Андрея Павленко] ''«адаптации» Аджайла к незрелым уровням спиральной динамики — это же почти исчерпывающий справочник фейлов при «внедрении» Аджайла''. С одной стороны, это - так, и эффект от внедрения Agile в этих случаях является гораздо меньшим, чем при переходе организации на желтый уровень. Но, с другой стороны, организация должна быть адекватна своему окружению, и если внешние условия '''не требуют''' непременного перехода организации - то он - не обязателен. А вот оздоровление бюрократической организации и возвращение осмысленности деятельности - все равно происходит, и это - как раз элемент развития. И дальше можно развиваться, работая со смыслами деятельности.
На этом - все.
Примерно неделю назад я прочитал [https://www.facebook.com/permalink.php?story_fbid=1980589221954579&id=100000105609030&pnref=story пост Ивана Дубровина] о том, как интенсивно шагает Kanban в традиционных госструктурах — Центральный банк, Федеральное канзначейство, региональные структуры. И в коментах мы обсудили, как там строят Kanban-доски при внедрении. Оказывается — по полной программе, с рассмотрением организации в сервисной модели, определением '''создаваемых ценностей подразделением'''. И я подумал, что это — очень радует. Происходит разморозка, возвращение смысла в деятельность организации.
Большим организациям свойственно бюрократизироваться, это в середине века исследовал Крозье ([[Блог:Максима Цепкова/2017-12-30: Как побудить организацию к изменениям|я об этом недавно писал]]), об этом же говорит жизненный цикл корпорации Адизеса, по которому корпорация уходит в аристократизм и бюрократию, а затем умирает. А Kanban — способен ее эволюционно оздоровить. Здесь уместно вспомнить схему из Спиральной динамики на рисунке справа. Она говорит о том, что эволюционные изменения возможны только если разрыв между состоянием организации и окружающим миром — не слишком велик, иначе необходима революция. Таким образом, эволюционное, а не революционное развитие наших крупных государственных организаций, откликающихся на внедрение Kanban, означает, что в целом наше государство в целом адекватно потребностям общества, способно к изменениям и развитию, и делает это. Что не может не радовать.
Собственно, я бы написал это неделю назад, но примерно тогда же на FB началась еще [https://www.facebook.com/groups/agilebeyondit/permalink/876119699236751/ одна интересная дискуссия] о том, что лучше для команды, переходящей на Agile — Scrum или Kanban. Там тема Kanban, его отличий от Scrum была достаточно активно затронута в обсуждением с Алексеем Пименовым, и я решил сначала завершить обсуждение там.
[[Файл:AgileTealOrg-HSE-2018-03.pdf|page=17|right|thumb|400px|[[Методы Agile и бирюзовых организаций для организации работы креативных команд (лекция 03.03.2018 ВШЭ СПб)|Из моей лекции в ВШЭ 03.03.2018]]
И здесь надо отметить, что для новой команды основное отличие Scrum от Kanban — как раз в эволюционном или революционном изменении не столько процессов, сколько системы ценностей. У любой организации есть две стороны, культура и процессы. Есть красивая схема-метафора кораблика, показывающая этот дуализм и придуманная Марком Розиным. И справа на схеме показана конструкция Agile в этой метафоре. Я тут процитирую один [https://www.facebook.com/groups/agilebeyondit/permalink/876119699236751/?comment_id=876165545898833&comment_tracking=%7B%22tn%22%3A%22R9%22%7D свой комментарий] из того поста — но советую прочитать всю дискуссию, а может — и принять участие.
<blockquote>
У этого вопроса есть два аспекта: ценности, процессы. С точки зрения процессов выбор зависит от того, есть ли в работе реальное квантование по поставке ценности потребителю — выпуск релизов. Scrum ориентирован на разработку, в которой ценности поставляются пакетами. Сейчас это, отчасти, снимается практикой continuous delivery, однако если новый функционал необходимо рекламировать, привлекать пользователей, то это все равно делается периодическими компаниями. А вот Kanban ориентирован на непрерывный поток задач, каждая из которых несет самостоятельную ценность и изолированно доставляется потребителю.
А вот с точки зрения трансформации культуры и принятия новых ценностей Scrum — гораздо лучше, потому что он резко перестраивает процесс, что влечет за собой осмысление и принятие людьми нового подхода к работе — или, наоборот, четкий провал в случае неприятия. Это происходит благодаря многочисленным встроенным встречам, которые значительно сфокусированы на ценностях, благодаря постановке целей на каждый спринт и другим подобным аспектам. И Scrum очень сложно внедрить без трансформации культуры. А Kanban с точки зрения ценностей — гораздо мягче, он вписывается в любую культурную среду, постепенно размораживая ее благодаря визуализации потока ценности, и благодаря старту постоянных улучшений. Поэтому его внедрение проходит мягче, но больше опасность, что трансформация будет ограниченной и затухнет. В IT это не слишком проявляется, потому что Kanban появился позже, чем Scrum, основные ценности и принципы Agile-манифеста уже были приняты сообществом, проявились успехи, и на повестку дня встал вопрос о мягкой трансформации больших компаний (ну и о работе с эксплуатацией и развитием систем, где нет четких релизов). Именно Kanban хорошо подходит для эволюционного размораживания и оздоровления больших бюрократизированных структур — он через доски workflow и побуждает задавать вопрос — несет ли конкретная работа ценность потребителю или нет, и кто вообще является потребителем для работ конкретного подразделения.
Если в терминах Спиральной динамики — то Kanban — может хорошо оздоровить бюрократизированный синий, без трансформации на следующие уровни (но в перспективе — трансформация запускается), а Scrum — пробует дотянуть до желтого достаточно интенсивно.
</blockquote>
[[Файл:AgileTealOrg-HSE-2018-03.pdf|page=59|right|thumb|400px|[[Методы Agile и бирюзовых организаций для организации работы креативных команд (лекция 03.03.2018 ВШЭ СПб)|Из моей лекции в ВШЭ 03.03.2018]]
Последний абзац как раз иллюстрирует вторая схема. После того, как Agile успешно развился и вышел на желтый уровень Спиральной динамики, как показано на левой, восходящей, ветви, и его методы доказали свое конкурентное преимущество, начались многочисленные попытки взять при внедрении только процессную часть Agile, не меняя ценности компании. Это показано на левой, нисходящей ветви. Впервые я показал эту схему в [[Agile и игрофикация: за каким менеджментом будущее? (AgileBusiness-2017)|выступлении на AgileBusiness-2017]], и на него был [https://www.facebook.com/photo.php?fbid=1668633256508140&set=a.702402356464573.1073741827.100000844450291&type=3 комментарий Андрея Павленко] ''«адаптации» Аджайла к незрелым уровням спиральной динамики — это же почти исчерпывающий справочник фейлов при «внедрении» Аджайла''. С одной стороны, это - так, и эффект от внедрения Agile в этих случаях является гораздо меньшим, чем при переходе организации на желтый уровень. Но, с другой стороны, организация должна быть адекватна своему окружению, и если внешние условия '''не требуют''' непременного перехода организации - то он - не обязателен. А вот оздоровление бюрократической организации и возвращение осмысленности деятельности - все равно происходит, и это - как раз элемент развития. И дальше можно развиваться, работая со смыслами деятельности.
На этом - все.