Изначально Agile ассоциировался исключительно с ИТ-сферой и стартапами. Для ИТ продуктов идеально подходит гибкая методология разработки и она легко ложиться укладывается в основу молодых проектов, которые только выходят на рынок.
А что делать большим традиционным компаниям, которые годами жили в WATERFALL проектах и чтобы согласовать новую кнопку на сайте проходят семь кругов бюрократического ада?
Сейчас мы наблюдаем распространение Agile в новых сферах: банковские структуры (и речь далеко не только о финтехах), транспортные услуги и пр.
Часть компаний применяют новую методологию к отдельным продуктам, некоторые, переводят целые подразделения в такой формат.
Про что не стоит забывать и что может помочь при внедрении Agile в крупной компании?
Не всё сразу
Самое главное- сохранить баланс. В любой крупной компании есть ограничения, про которые не нужно забывать при внедрении гибких методологий. Нужно понимать, что часть подразделений продолжат свою привычную работу и не перейдут в Agile. Руководителям важно устанавливать приоритеты и последовательность действий.
Необходимо ответить себе на вопрос: сколько гибких команд мы сможем запустить и поддерживать?
Где золотая середина между интересами сотрудников и ограничениями компании?
Число agile-команд повысит уровень гибкости компании, но не стоит забывать о том, как команды взаимодействуют с остальной организацией.
Начни с себя
Большая ответственность при внедрении новых методологий лежит на руководстве компании. Здесь пригодятся все лидерские качества. Только подавая личный пример и меняя свое отношение к ведению бизнеса и бизнес процессам, руководитель сможет каскадировать до всех сотрудников значимость изменений и их необходимость.
Все просто, хочешь что-то изменить- начни с себя.
Если руководитель заходит на Stand Up в одну из команд и в комнате виснет гробовая тишина, то что-то здесь не так.
Усиливай команду
Команда в этой истории, пожалуй, самый важный пункт. И об этом стоит думать с самого начала.
Необходимо провести обучение сотрудников с полным погружением. Сейчас на рынке образования достаточно сильных игроков, которые специализируются на теме внедрения Agile.
Также большую популярность набирают акселераторы, в которые компании отправляют своих сотрудников. Акселератор позволяет сделать несколько важных замеров для руководителей. Например, на сколько замотивирован сотрудник, посмотреть на практические задания, а не только дать теорию, понять с кем дальше не по пути, а кого стоит поощрять и развивать.
Нанять правильных людей — это не самое главное для успеха. Важнее вовремя уволить неправильных.
Если в компании в текущий момент нет сотрудников, которые необходимы для полноценной работы команды, нужно усиливать команду.
Если в компании часть сотрудников токсично влияют на работу других и мешают изменениям, нужно прощаться с такими людьми.
Научись делегировать по-настоящему
Большая проблема крупных компаний- перепроверять чужую работу. Десятки кругов согласования, бесконечные правки… в результате человек не чувствует ответственность за свою работу. Какие проблемы? Меня же все равно перепроверят!
Важная задача руководства — научиться делегировать по-настоящему.
Руководители полностью отвечают за результаты бизнеса, но при этом полагаются на более клиентоориентированные agile-команды.
Руководитель говорит ЧТО делать, а не КАК.
Весь waterfall в голове
Часто результат работы сотрудников в больших корпорациях измеряют вехами дорожных карт.
Составляется дорожная карта продукта с вехами на 5 лет вперед и по ней нужно следовать, отчитываться по каждой вехе. И во главу создания продукта встает не прибыль от продукта, его полезность, цели по важным для продукта метрикам и тд, а четкое соблюдение дорожной карты.
Что делают сотрудники, если провалили задачу? Правильно, переносят веху.
Что делают сотрудники, если выполнили задачу за 2 недели, а не за квартал? Правильно, отчитываются о перевыполнении в конце квартала.
За годы работы создается определенный образ мышления. Именно с ним нужно бороться при внедрении гибких методологий.
Скорректировать ценности, научиться брать на себя и разделять ответственность, иметь общие понятные цели.
«Почему Agile не работает в крупных компаниях?Пусть эта штука будет не про ваш бизнес.
Стикеры через 6 месяцев отклеиваются.»
Становиться гибкими, создавать более адаптивные решения, слышать потребности наших клиентов и развиваться в новом темпе современного мира- именно эти вызовы мы получаем каждый день.
Комментарии (18)
AnROm
21.04.2019 15:23Полностью согласна с комментарием выше. Автор просто написал общие принципы, о чем не нужно забывать, когда вообще хоть какие-то процессы управления внедряются.
Особенностями внедрения Agile даже и не пахнет
in_heb
21.04.2019 18:36Статейка уровня булшит-презентаций, когда рассказывают о космических кораблях на волне хайпа.
Где ваши истории успеха?
Где lessons learned? (Не знаю как это перевести на русский, сорри)
Где ограничения применимости методологии?
NeverIn
21.04.2019 20:47Если в компании часть сотрудников токсично влияют на работу других и мешают изменениям, нужно прощаться с такими людьми.
Как правило такое впечатление производят неравнодушные люди, указывающие на критичные недостатки продукта или бизнеса. Вместо того, чтобы прислушаться, конечно, проще признать «токсичными».ilnuribat
22.04.2019 02:29Тут речь про мешающих другим, критики процессов — полезные люди, пока их критика базируется на ценностях agile. Их ещё называют скрам мастерами
mad_nazgul
22.04.2019 07:58А судьи кто?
Или как обычно, критиковать можно, но только в русле «линии партии».
А какая сейчас «линия партии» нужно догадаться самому :-)
ggo
22.04.2019 10:02Токсичность — это не про критику.
Токсичность — это отравление командной работы в буквальном смысле. Токсичность нельзя ни с чем перепутать. Токсичность лечится только у молодых, у состоявшихся к сожалению не лечится, и остается только избавляться от токсичных.NeverIn
23.04.2019 08:35Конечно, молодыми легче манипулировать, чем теми, кому за 40. Которые имеют свое устоявшееся мнение, опыт и не ведутся на корпоративные заманухи в ввиде бесплатного боулинга, дартса и печенюшек в офисе. Они циничны, ввиду того, что предвидят результат еще до начала работ. Все это и воспринимается как «токсичность» бездарными руководителями, зачастую не имеющие достаточной квалификации в своем бизнесе.
ggo
23.04.2019 10:22Манипуляции, истинные, кстати тоже токсичны.
Предвидеть — это хорошо.
Бездарные руководители есть.
Так же как и токсичные сотрудники.
От тех и других нужно избавляться.
Maxmyd
22.04.2019 09:02Если руководитель заходит на Stand Up в одну из команд и в комнате виснет гробовая тишина, то что-то здесь не так.
Да, что-то не так. А именно — руководитель не должен присутствовать на стендапе. You are not welcomed here.ggo
22.04.2019 10:03Почему не должен присутствовать?
Maxmyd
22.04.2019 10:44Первое правило стендапа — никому не говорить о стендапе :)
Если мерить рамками Agile, стендап — это в первую очередь встреча участников разработки, на которой они актуализируют текущее состояние разработки, намечают способы разрешения проблем, координируют действия между членами команды. Это если кратко.
Присутствие любого руководящего лица на стендапе не приветствуется, так как, помимо того, что руководитель не может внести какую-либо ценность в саму разработку (это главное!), он еще и демонстрирует некую определенную степень недоверия к команде, тем самым нарушая принцип саморегулирующихся команд.
Самое сложное — убедить руководителя (это если он хочет продемонстрировать свою вовлеченность в процесс) в том, что стендап — это не совещание.ggo
23.04.2019 10:31Категоричность — это то что мне нравится.
Руководитель присутствует на любом движняке не для того, чтобы своими руками заменить руки сотрудников (руки можно заменить любые другие части тела). Руководитель хочет из первых рук получить картину происходящего. Если что-то буксует, почему бы не выйти в поле. Да, стендап не совещание. Но почему нельзя то…Maxmyd
23.04.2019 10:50чтобы своими руками заменить руки сотрудников
В этом случае в данном процессе руководитель имеет роль участника разработки, а значит, имеет право там находиться как разработчик. И раздавать указания не сможет :)
Руководитель хочет из первых рук получить картину происходящего
Получит, но после стендапа. Из первых рук, так как в стендапе участвуют те, кто непосредственно занимается. И да, можно прямо сразу после.
В целом, если в компании практикуется участие руководителя в стендапе, это их дело. Я рассуждаю с позиции Agile.ggo
24.04.2019 10:02Agile то как запрещает посещение стендапов? Главное не нарушать правил стендапа.
Так все таки руководитель не может посещать стендап, или не должен раздавать указаний на стендапе? ;)Maxmyd
24.04.2019 11:18То, что вы пытаетесь сделать, называется подменой понятий. Вы не адвокат часом? Изо всех сил, любой ценой, цепляясь за каждую букву, пытаетесь заставить меня согласиться с вами, как будто мир рухнет.
Agile то как запрещает посещение стендапов? Главное не нарушать правил стендапа.
Правило стендапа — в нем должны участвовать только непосредственные разработчики или те, кто вносит ценность в спринт. Изначально фраза звучала «Если руководитель заходит на стендап...» Это означает, что в описанном случае НЕ является участником стендапа и НЕ является разработчиком. Просто зашел послушать. Это нарушение правил.
Рискну предположить, что Вы являетесь таким руководителем, или у вас в компании такое практикуется. И, видимо, Вы точно так же давите на разработчиков на стендапах, которые посещаете. Но это только предположение, основанное на нашем диалоге.
На этом предлагаю его закончить.ggo
25.04.2019 12:06В правилах стендапа вашей команды?
Или некоторых референсных правилах стендапа? Если второе, можете дать ссылку на эти правила?
Mikluho
Ну и… блин, даже не сказать культурно…
Статья, точнее статеечка, не отвечает на вопрос, поставленный в заголовке.
Так, махание лозунгами, не более.
Да и с русским в тексте много проблем.