Есди вы про бирюзу, то да я тоже вижу что для крупного предприятия это может быть и выполнимая задача, но весьма трудоемкая — придется вложить огромные силы и средства в развитие каждого сотрудника индивидуально. Есть такие компании но им пришлось кроме всего прочего и избавляться от процентов 30 команды. В общем это сложная и неоднозначная тема. Но выполгимая
Ну я точно не изобретал чегото что никогда нигде никем не пробовалось. Я скорее взял идею и концептуализировал, упорядочил и оформил в более или менее стройную методологию (я пока в начале пути и она будет конечно дорабатываться ибо пока сыровата). И исходил я чисто из практического применения. Революция данная методология не совершит, но точно поможет расшивке таких мифов как "Lean и Agile не работают". А учитывая какие суперуспешные результаты она даёт на практике, ценность (как минимум пока для меня).
По поводу вашего случая — вот именно такие случаи возможны при классических внедрениях Lean и Agile. В Agilean всегда превалирует ценность. Если психологическая безопасность нарушена — значит будем делать по другому. Но опять же надо понимать — психологическая безопасность это когда атмосфера в команде позитивная, открытая и демократичная, каждый может высказывать любые глупые идеи и нет никакого иерархического давления на свободу общения.
Если человеку предлагают поработать а он не хочет, прикрываясь психологической безопасностью, то конечно будет рассмотрено почему он так чувствует, но в итоге такой токсичный человек просто сам будет выдавлен командой, которая все таки обьединилась для получения результата а не для благостного ничегонеделанья
Сейчас в Agile есть много фреймворков и каждая провозглашает что только одна она правильная, ни одна не провозглашает "разные фреймворки могут применяться в зависимости от контекста и условий, а в определенных случаях они могут совмещаться, гибридизироваться, или на их базе могут строиться новые, совсем другие". Что было бы как раз правильным Agile подходом. Но сейчас на практике такого нет.
Смотрите у Agile ценности: Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
У Agilean ценности: Свободная коммуникация, Психологическая безопасность, Непрерывное улучшение и Гибкость
Какие более универсальны и лкгко адаптируемый под любой бизнес контекст бищнес отрасли?
Так что у меня изменение и на уровне Скрам и на уровне Аджайл
Именно так. Потому что отталкиваются от инструмента или методологии а не от ценностей.
В Agilean они бы не "внедряли Agile в девтимах" а решали проблемы со Свободой коммуникаций, Психологической безопасностью, Непрерывным улучшением и Гибкостью
Оттуда выпали бы совсем другие меры а не локалтная трансформация одной команды
Agilean — не равно "бирюзовость". А там где сотрудники плюются от "бирюзовости" и там где плюются от "Agile" ситуация одна — неправильное понимание и применение.
Например бирюза работает только там где уровень развитости сотрудников в духе "внутреннего энтерпренёрства" очень высокий. То есть каждый сотрудник высококомпетентный самомотивированный профессионал, которому не нужны указания, чтобы знать куда двигаться, и нужна только координация чтобы достигать вместе большего.
Согласитесь такие команды редки. Просто нужно знать на каком уровне развития сотрудников какой инструмент внедрять
Новые сущности нужны, так как пока ни в одной трактовке Agile нет гибридизации и создания новых инструментов "от контекста". Везде пытаются натягивать контекст на инструмент.
Более того я считаю что Agilean — это попытка выйти на верхний уровень где основное ценности, а все методологии типа Lean, ToC, Agike и т.д. Суть просто локальные проявления законов этой Вселенной организационного управления. Так что имхо абсолютно точно нужен такой пересмотр. Это как разрабатывать механизмы отталкиваясь от законов физики. Сейчас фигурально выражаясь это разработка механизмов способом копирования других механизмов.
Про консультантов согласен но учитывая принцип свободной гибридизации, зарегламентировать эту методологию будет сложней
По сути Agile в идеальном понимании и есть Agilean. Но в своём реальном состоянии Agile пока слищком заточен под IT, в нём недостаточно системно реализован компонент кайзен (системные механизмы непрерыаных улучшений) и он перезарегламентирован всеми этими "евангелистами Agile" которые просто остановивщиеся в своем развитии консультанты, которые хотят сшибать денежку за минимальные знания. Они настаивают что Agile-решения должны регламентироваться до каждого мини шажка и не признают на деле гибридизации и экспериментов.
В этом смысле Agilean и есть тот самый "правильный Agile" абсолютно свободный в экспериментах и гибридизации подходов и инструментов под задачу
"коэффициент использования энергии" не относится к Голдратту. Я написал что по факту все усилия ТоС влияют на КИО. Что вас тут смущает не пойму потому что это именно так и есть и оспорить этот факт невозможно.
Я ничего не натягивал — откройте любую научную статью про дофамин и мотивацию и прочитайте сами.
Эта "хрень" связана с Lean и Agile тем что максимально эффективно использует инструменты и той и другой методологии избавившись от недостатков каждой.
Я не говорю что нет "необходимости помочь", я говорю что при правильной конфигурации системы "необходимость помочь думать по-другому" минимальна, так как происходит learning by doing
Этот фактор точно присутствует, но и работа самих сотрудников тоже переформатирована от бездумного индивидуального выполнения задач на работу с группой, анализ собственной эффективности и непрерывное улучшение.
Работа руководства перефокусировалась на предоставление чётких стратегических KPI, методологический коучинг подчиненных (само собой они были сначала этому обучены), и защиту команды от внешних воздействий.
Нет, материальной мотивации не было. А пристальное внимание руководства точно помогло для первого импульса, который помог сподвигнуть людей (особенно миддл менеджмент) к начальным изменениям.
Рядовве сотрудники в принципе были готовы поддержать такие изменения так как работали в условиях перманентного стресса, отставания от плана и абсурда в целеполагании. Они и являются основной движущей силой механизмов Agilean, так как один раз попробовав свободу самоорганизации и получив высокие результаты минимумом усилий, ни за что не вернутся к старой системе
Вы говорите о методологии и да там есть много разумных практик, перекликающихся с Agile методами, но я больше говорю о практике. Я из ни разу не видел и не слышал о waterfall проекте в России, где заказчик не требовал бы полного графика от подготовки до заключительной фазы.
То есть можно конечно увлечься релятивизмом и сказать, что кое где кое кем все же делается не так. Но это вопрос научно-методологического пуризма.
Статья же об исключительно практическом инструменте и самой расхожей ситуации в реальности
Я согласен, что стресс и абсурд при желании можно где угодно создать, но когда я говорил про waterfall, я имел в виду, что гибкий бэклог генерит гораздо меньше дезинформации, стресса и абсурда, чем расписанный на долгий период вперёд график проекта (вот тут я детально писал о причинах habr.com/ru/post/422327). А большая доля различия Скрам и Вотерфолл — это как раз гибкость планирования.
Согласен, что неправильное использование Плана коммуникаций это от непонимания, незнания. Но в формате работы по Коттеру такого непонимания, незнания автоматически становится меньше, потому что его модель изменений очень точно, глубоко и понятно описывает, какие коммуникации и когда в течение жизни проекта нужно сделать.
«Эти системы Agile часто неправильно применяются и требуют унизительной прозрачности работы, несмотря на отсутствие взаимности»
Статья отличная, очень грамотно и глубоко проанализирована ситуация с Agile и Scrum внедрением. Но выводы сделаны не совсем верные.
В строчке, которую я процитировал выражена вся проблема — Agile в таком виде, какой есть в большинстве фирм сейчас, это не Agile. Это профанация. И если ваша Scrum-команда не может принять решение НЕ работать в open-space и если она не может получить обоюдную прозрачность и участвовать в принятии решений о продукте, то это не Agile. Это потогонка и микроменеджмент под нарядной драпировкой.
Ну а решение одно — внедрять ценности, а не фреймворки. А ценности — Самоорганизация и Самоуправление, Прозрачность, Психологическая безопасность и Непрерывное улучшение
Есди вы про бирюзу, то да я тоже вижу что для крупного предприятия это может быть и выполнимая задача, но весьма трудоемкая — придется вложить огромные силы и средства в развитие каждого сотрудника индивидуально. Есть такие компании но им пришлось кроме всего прочего и избавляться от процентов 30 команды. В общем это сложная и неоднозначная тема. Но выполгимая
Ничто не вечно под луной
Отнюдь. В небольших стартапах чаще всего такие команды и собираются. В крупныхэто да, сложнее воплотить
Ну я точно не изобретал чегото что никогда нигде никем не пробовалось. Я скорее взял идею и концептуализировал, упорядочил и оформил в более или менее стройную методологию (я пока в начале пути и она будет конечно дорабатываться ибо пока сыровата). И исходил я чисто из практического применения. Революция данная методология не совершит, но точно поможет расшивке таких мифов как "Lean и Agile не работают". А учитывая какие суперуспешные результаты она даёт на практике, ценность (как минимум пока для меня).
По поводу вашего случая — вот именно такие случаи возможны при классических внедрениях Lean и Agile. В Agilean всегда превалирует ценность. Если психологическая безопасность нарушена — значит будем делать по другому. Но опять же надо понимать — психологическая безопасность это когда атмосфера в команде позитивная, открытая и демократичная, каждый может высказывать любые глупые идеи и нет никакого иерархического давления на свободу общения.
Если человеку предлагают поработать а он не хочет, прикрываясь психологической безопасностью, то конечно будет рассмотрено почему он так чувствует, но в итоге такой токсичный человек просто сам будет выдавлен командой, которая все таки обьединилась для получения результата а не для благостного ничегонеделанья
Сейчас в Agile есть много фреймворков и каждая провозглашает что только одна она правильная, ни одна не провозглашает "разные фреймворки могут применяться в зависимости от контекста и условий, а в определенных случаях они могут совмещаться, гибридизироваться, или на их базе могут строиться новые, совсем другие". Что было бы как раз правильным Agile подходом. Но сейчас на практике такого нет.
Смотрите у Agile ценности: Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
У Agilean ценности: Свободная коммуникация, Психологическая безопасность, Непрерывное улучшение и Гибкость
Какие более универсальны и лкгко адаптируемый под любой бизнес контекст бищнес отрасли?
Так что у меня изменение и на уровне Скрам и на уровне Аджайл
Именно так. Потому что отталкиваются от инструмента или методологии а не от ценностей.
В Agilean они бы не "внедряли Agile в девтимах" а решали проблемы со Свободой коммуникаций, Психологической безопасностью, Непрерывным улучшением и Гибкостью
Оттуда выпали бы совсем другие меры а не локалтная трансформация одной команды
Agilean — не равно "бирюзовость". А там где сотрудники плюются от "бирюзовости" и там где плюются от "Agile" ситуация одна — неправильное понимание и применение.
Например бирюза работает только там где уровень развитости сотрудников в духе "внутреннего энтерпренёрства" очень высокий. То есть каждый сотрудник высококомпетентный самомотивированный профессионал, которому не нужны указания, чтобы знать куда двигаться, и нужна только координация чтобы достигать вместе большего.
Согласитесь такие команды редки. Просто нужно знать на каком уровне развития сотрудников какой инструмент внедрять
Новые сущности нужны, так как пока ни в одной трактовке Agile нет гибридизации и создания новых инструментов "от контекста". Везде пытаются натягивать контекст на инструмент.
Более того я считаю что Agilean — это попытка выйти на верхний уровень где основное ценности, а все методологии типа Lean, ToC, Agike и т.д. Суть просто локальные проявления законов этой Вселенной организационного управления. Так что имхо абсолютно точно нужен такой пересмотр. Это как разрабатывать механизмы отталкиваясь от законов физики. Сейчас фигурально выражаясь это разработка механизмов способом копирования других механизмов.
Про консультантов согласен но учитывая принцип свободной гибридизации, зарегламентировать эту методологию будет сложней
По сути Agile в идеальном понимании и есть Agilean. Но в своём реальном состоянии Agile пока слищком заточен под IT, в нём недостаточно системно реализован компонент кайзен (системные механизмы непрерыаных улучшений) и он перезарегламентирован всеми этими "евангелистами Agile" которые просто остановивщиеся в своем развитии консультанты, которые хотят сшибать денежку за минимальные знания. Они настаивают что Agile-решения должны регламентироваться до каждого мини шажка и не признают на деле гибридизации и экспериментов.
В этом смысле Agilean и есть тот самый "правильный Agile" абсолютно свободный в экспериментах и гибридизации подходов и инструментов под задачу
"коэффициент использования энергии" не относится к Голдратту. Я написал что по факту все усилия ТоС влияют на КИО. Что вас тут смущает не пойму потому что это именно так и есть и оспорить этот факт невозможно.
Я ничего не натягивал — откройте любую научную статью про дофамин и мотивацию и прочитайте сами.
Эта "хрень" связана с Lean и Agile тем что максимально эффективно использует инструменты и той и другой методологии избавившись от недостатков каждой.
Я не говорю что нет "необходимости помочь", я говорю что при правильной конфигурации системы "необходимость помочь думать по-другому" минимальна, так как происходит learning by doing
Так и было
Ну визуализация это вообще старый инструмент
Этот фактор точно присутствует, но и работа самих сотрудников тоже переформатирована от бездумного индивидуального выполнения задач на работу с группой, анализ собственной эффективности и непрерывное улучшение.
Работа руководства перефокусировалась на предоставление чётких стратегических KPI, методологический коучинг подчиненных (само собой они были сначала этому обучены), и защиту команды от внешних воздействий.
Нет, материальной мотивации не было. А пристальное внимание руководства точно помогло для первого импульса, который помог сподвигнуть людей (особенно миддл менеджмент) к начальным изменениям.
Рядовве сотрудники в принципе были готовы поддержать такие изменения так как работали в условиях перманентного стресса, отставания от плана и абсурда в целеполагании. Они и являются основной движущей силой механизмов Agilean, так как один раз попробовав свободу самоорганизации и получив высокие результаты минимумом усилий, ни за что не вернутся к старой системе
Вы говорите о методологии и да там есть много разумных практик, перекликающихся с Agile методами, но я больше говорю о практике. Я из ни разу не видел и не слышал о waterfall проекте в России, где заказчик не требовал бы полного графика от подготовки до заключительной фазы.
То есть можно конечно увлечься релятивизмом и сказать, что кое где кое кем все же делается не так. Но это вопрос научно-методологического пуризма.
Статья же об исключительно практическом инструменте и самой расхожей ситуации в реальности
Согласен, что неправильное использование Плана коммуникаций это от непонимания, незнания. Но в формате работы по Коттеру такого непонимания, незнания автоматически становится меньше, потому что его модель изменений очень точно, глубоко и понятно описывает, какие коммуникации и когда в течение жизни проекта нужно сделать.
Это новое сочетание старых инструментов для успешного внедрения проектов НЕ связанных с разработкой ПО.
Статья отличная, очень грамотно и глубоко проанализирована ситуация с Agile и Scrum внедрением. Но выводы сделаны не совсем верные.
В строчке, которую я процитировал выражена вся проблема — Agile в таком виде, какой есть в большинстве фирм сейчас, это не Agile. Это профанация. И если ваша Scrum-команда не может принять решение НЕ работать в open-space и если она не может получить обоюдную прозрачность и участвовать в принятии решений о продукте, то это не Agile. Это потогонка и микроменеджмент под нарядной драпировкой.
Ну а решение одно — внедрять ценности, а не фреймворки. А ценности — Самоорганизация и Самоуправление, Прозрачность, Психологическая безопасность и Непрерывное улучшение