Комментарии 48
Нет, материальной мотивации не было. А пристальное внимание руководства точно помогло для первого импульса, который помог сподвигнуть людей (особенно миддл менеджмент) к начальным изменениям.
Рядовве сотрудники в принципе были готовы поддержать такие изменения так как работали в условиях перманентного стресса, отставания от плана и абсурда в целеполагании. Они и являются основной движущей силой механизмов Agilean, так как один раз попробовав свободу самоорганизации и получив высокие результаты минимумом усилий, ни за что не вернутся к старой системе
По моему опыту основная проблематика введения Agile заключается в том, что люди не понимают что этот самый Agile не работает "локально". То есть нельзя перевести на Agile только девтимы а всё остальное оставить как есть.
По хорошему надо всю фирму под это дело "перестраивать" и самое главное клиентов. Иначе на мой взгляд ничего хорошего из этого не получится. И многие фирмы делают именно такую ошибку и в результате начальство довольно что "у нас теперь аджайл", а работники страдают от диссонанса структур и процессов.
Именно так. Потому что отталкиваются от инструмента или методологии а не от ценностей.
В Agilean они бы не "внедряли Agile в девтимах" а решали проблемы со Свободой коммуникаций, Психологической безопасностью, Непрерывным улучшением и Гибкостью
Оттуда выпали бы совсем другие меры а не локалтная трансформация одной команды
Agilean — не равно "бирюзовость". А там где сотрудники плюются от "бирюзовости" и там где плюются от "Agile" ситуация одна — неправильное понимание и применение.
Например бирюза работает только там где уровень развитости сотрудников в духе "внутреннего энтерпренёрства" очень высокий. То есть каждый сотрудник высококомпетентный самомотивированный профессионал, которому не нужны указания, чтобы знать куда двигаться, и нужна только координация чтобы достигать вместе большего.
Согласитесь такие команды редки. Просто нужно знать на каком уровне развития сотрудников какой инструмент внедрять
каждый сотрудник высококомпетентный самомотивированный профессионал
Это утопия, где-то рядом с коммунизмом.
Отнюдь. В небольших стартапах чаще всего такие команды и собираются. В крупныхэто да, сложнее воплотить
В небольших стартапах чаще всего такие команды и собираются.
А как надолго хватает самомотивированности? Пока не женился?
Ничто не вечно под луной
Есди вы про бирюзу, то да я тоже вижу что для крупного предприятия это может быть и выполнимая задача, но весьма трудоемкая — придется вложить огромные силы и средства в развитие каждого сотрудника индивидуально. Есть такие компании но им пришлось кроме всего прочего и избавляться от процентов 30 команды. В общем это сложная и неоднозначная тема. Но выполгимая
Постоянно это слышу, но прописаных практик по "здравому смыслу" найти не могу. Как, например, в здравом смысле релизы планируются? А как проверяется скорость/готовность выполнения фич? А трудоёмкость каждой задачи? А важность задачи? Это наверное меньше 1% того, на что в аджайле есть прямые непротиворечивые ответы.
А со "здравым смыслом" как разобраться чтобы каждый от управляющего директора до последнего разраба/qa имели консистентную картину в головах? А не перетягивал одеяло в соответствии со своим пониманием картины мира.
Очень хочется посмотреть как это сработает хотя бы в среднего размера департаменте команд на 25-40.
Т.е. до аджайла проекты ИТ сферы не делали? Делали и весьма хорошо.
Это немного демагогия, не находите? Вместо аджайла можно подставить любое слово. Например система контроля версий, CI, юнит-тесты, код-ревью и так далее…
А вопросы, которые вы задали решаются достаточно просто. Собираетесь, задаете вопросы и принимаете по ним решения, как вам это нужно.
Как определить, на какую дату назначить релиз? Или наоборот, какие фичи будут готовы к заранее известной дате релиза? Предлагаете поверить на слово?
Я вполне допускаю, что если каким-то чудом собрать в одном офисе достаточно умных и замотивированных на результат людей, то какой-то (пускай значительной) части аджайл-церемоний можно и избежать. Но я ни разу не видел, чтобы это работало на практике. Возможно у нас разный опыт
До: некомпетентное начальство хочет чувствовать себя начальством, и поэтому лезет к работникам и мешает работать (всё время).
После: игры начальства с работниками регламентированы и ограничены по времени, у работников появляется свободное время для того, чтобы делать работу, поэтому она начинает делаться. Начальник чувствует себя начальником, но им не является, функции начальника исполняет кто-то из толковых работников (самоорганизация).
Написанное в статье — как раз регламент игр.
Этот фактор точно присутствует, но и работа самих сотрудников тоже переформатирована от бездумного индивидуального выполнения задач на работу с группой, анализ собственной эффективности и непрерывное улучшение.
Работа руководства перефокусировалась на предоставление чётких стратегических KPI, методологический коучинг подчиненных (само собой они были сначала этому обучены), и защиту команды от внешних воздействий.
Ну визуализация это вообще старый инструмент
Ох какой песец… Как вы читали Голдратта если потом пытаетесь "увеличить коэффициент использования энергии" в общем, хотя до этого говорили что метод "бутылочного горлышка" состоит как раз в противоположном — улучшение малыми затратами одного места, а не попыток улучшить везде и всё?
Заголовок — желтуха, как вот эта хрень связана с agile и lean вообще непонятно. Изобрели очередное громкое слово для недоруководителей.
Что потом подкрепляется словами "Нет необходимости «внедрения методологии и философии»". Т.е. вы натянули рефлексы собаки Павлова на человека и утверждаете что решили все проблемы, моментально, без побочных эффектов и без необходимости помочь и научить людей думать по-другому? Трешачок.
"коэффициент использования энергии" не относится к Голдратту. Я написал что по факту все усилия ТоС влияют на КИО. Что вас тут смущает не пойму потому что это именно так и есть и оспорить этот факт невозможно.
Я ничего не натягивал — откройте любую научную статью про дофамин и мотивацию и прочитайте сами.
Эта "хрень" связана с Lean и Agile тем что максимально эффективно использует инструменты и той и другой методологии избавившись от недостатков каждой.
Я не говорю что нет "необходимости помочь", я говорю что при правильной конфигурации системы "необходимость помочь думать по-другому" минимальна, так как происходит learning by doing
примере данного бизнес-кейса продемонстрированы преимущества методологии Agilean над классическими методологиями и философиями оптимизации бизнеса типа Lean, Agile, ToC и всех подобных существующих на сегодняшний день
Если честно то я не вижу каких-то особых преимуществ. То есть вы их конечно перечислили, но все эти преимущества имеет и "обычный" Agile. А вот преимуществ вашей методики по сравнению с ним я не вижу.
Да и какой-то принципиально новой методологии я честно говоря не вижу. Обычное "натягивание" и подстраивание Agile на свою ситуацию.
По сути Agile в идеальном понимании и есть Agilean. Но в своём реальном состоянии Agile пока слищком заточен под IT, в нём недостаточно системно реализован компонент кайзен (системные механизмы непрерыаных улучшений) и он перезарегламентирован всеми этими "евангелистами Agile" которые просто остановивщиеся в своем развитии консультанты, которые хотят сшибать денежку за минимальные знания. Они настаивают что Agile-решения должны регламентироваться до каждого мини шажка и не признают на деле гибридизации и экспериментов.
В этом смысле Agilean и есть тот самый "правильный Agile" абсолютно свободный в экспериментах и гибридизации подходов и инструментов под задачу
В этом смысле Agilean и есть тот самый "правильный Agile" абсолютно свободный в экспериментах и гибридизации подходов и инструментов под задачу
Вы извините но "правильный Agile" это просто правильный Agile. И для того чтобы делать Agile правильно не нужны какие-то новые сущности и новые названия.
И даже если вы назовёте это Agilean или ещё как-то, то это никак не защитит вас от "евангелистов Agilean", которые точно так же будут:
просто остановивщиеся в своем развитии консультанты, которые хотят сшибать денежку за минимальные знания. Они настаивают что Agilean-решения должны регламентироваться до каждого мини шажка и не признают на деле гибридизации и экспериментов.
П.С. И не поймите меня неправильно, я не считаю вашу методику саму по себе чем-то плохим или ущербным. Просто это на мой взгляд не "убийца Agile", а только один из вариантов его реализации.
Новые сущности нужны, так как пока ни в одной трактовке Agile нет гибридизации и создания новых инструментов "от контекста". Везде пытаются натягивать контекст на инструмент.
Более того я считаю что Agilean — это попытка выйти на верхний уровень где основное ценности, а все методологии типа Lean, ToC, Agike и т.д. Суть просто локальные проявления законов этой Вселенной организационного управления. Так что имхо абсолютно точно нужен такой пересмотр. Это как разрабатывать механизмы отталкиваясь от законов физики. Сейчас фигурально выражаясь это разработка механизмов способом копирования других механизмов.
Про консультантов согласен но учитывая принцип свободной гибридизации, зарегламентировать эту методологию будет сложней
Новые сущности нужны, так как пока ни в одной трактовке Agile нет гибридизации и создания новых инструментов "от контекста"
Вот об этом пожалуйста поподробнее. Я может чего-то не понимаю, но у меня другое видение ситуации.
Про консультантов согласен но учитывая принцип свободной гибридизации, зарегламентировать эту методологию будет сложней
Вы походе смешиваете Agile как методологию с конкретными вариантами иеализации вроде того же Scrum. Но вас же никто не заставляет брать имеющиеся варианты и вы можете придумать свой. Что вы кстати на мой взгляд и сделали.
То есть как я это вижу вы скорее придумали альтернативу Scrum, а не альтернативу Agile.
Сейчас в Agile есть много фреймворков и каждая провозглашает что только одна она правильная, ни одна не провозглашает "разные фреймворки могут применяться в зависимости от контекста и условий, а в определенных случаях они могут совмещаться, гибридизироваться, или на их базе могут строиться новые, совсем другие". Что было бы как раз правильным Agile подходом. Но сейчас на практике такого нет.
Смотрите у Agile ценности: Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
У Agilean ценности: Свободная коммуникация, Психологическая безопасность, Непрерывное улучшение и Гибкость
Какие более универсальны и лкгко адаптируемый под любой бизнес контекст бищнес отрасли?
Так что у меня изменение и на уровне Скрам и на уровне Аджайл
Сейчас в Agile есть много фреймворков и каждая провозглашает что только одна она правильная, ни одна не провозглашает "разные фреймворки могут применяться в зависимости от контекста и условий, а в определенных случаях они могут совмещаться, гибридизироваться, или на их базе могут строиться новые, совсем другие". Что было бы как раз правильным Agile подходом. Но сейчас на практике такого нет.
Я соглашусь что такое часто встречается. Очень часто. Но при этом всё-таки не абсолютно везде. И как я уже писал выше это скорее проблема "исполнителей", а не самой методики. И на мой взгляд эта проблема будет у любой методики такого "типа".
Какие более универсальны и лкгко адаптируемый под любой бизнес контекст бищнес отрасли?
Ок, теперь немного понятнее о чём речь. На мой взгляд "проблема" ваших ценностей в их размытой формулировке. И в том что они местами "конфликтуют" друг с другом.
Если совсем упрощать, то приходит мой коллега/начальник с каким-то "гибким улучшением", а я ему в ответ что это несовместимо с моей "психологической безопасностью". И как этот конфликт будет решён в средней фирме? На мой взгляд скорее всего введением какого-то жёсткого "приоризирующего" правила. И рано или поздно этих правил будет много.
Ну я точно не изобретал чегото что никогда нигде никем не пробовалось. Я скорее взял идею и концептуализировал, упорядочил и оформил в более или менее стройную методологию (я пока в начале пути и она будет конечно дорабатываться ибо пока сыровата). И исходил я чисто из практического применения. Революция данная методология не совершит, но точно поможет расшивке таких мифов как "Lean и Agile не работают". А учитывая какие суперуспешные результаты она даёт на практике, ценность (как минимум пока для меня).
По поводу вашего случая — вот именно такие случаи возможны при классических внедрениях Lean и Agile. В Agilean всегда превалирует ценность. Если психологическая безопасность нарушена — значит будем делать по другому. Но опять же надо понимать — психологическая безопасность это когда атмосфера в команде позитивная, открытая и демократичная, каждый может высказывать любые глупые идеи и нет никакого иерархического давления на свободу общения.
Если человеку предлагают поработать а он не хочет, прикрываясь психологической безопасностью, то конечно будет рассмотрено почему он так чувствует, но в итоге такой токсичный человек просто сам будет выдавлен командой, которая все таки обьединилась для получения результата а не для благостного ничегонеделанья
Вы ошибаетесь. Agile и манифест Agile — разные вещи
Методики Agile нет, но «делать Agile» — вполне себе можно. Есть даже такое понятие «Do Agile» — то есть организация своей деятельности в духе философии Agile.
Ну плодить бюрократию и бумагооборот — это точно не Lean и не Agile)
Так, как вы это описываете, вы на самом деле не работаете по "водопаду".
То есть agile это или нет надо ещё разбираться. Но это точно не "водопад" :)
upd. И кстати, согласен с VMichael, «то что ранее называлось здравым смыслом...» Стараюсь всегда руководствоваться им, а не только методичкой :)
Ну если совсем упрощать то на мой взгляд "водопад" это действительно когда у вас есть определённая последовательность и вы её жёстко придерживаетесь.
Плюс я бы ещё наверное причислил к особенностям "водопада" и достаточно большие по объёму "пакеты" и относительно длительное время на разработку прежде чем готовый результат видит заказчик.
И я бы сказал что то, что вы описываете, скорее ближе к какому-нибудь канбану чем к "водопаду".
Agilean: Lean + Agile