Pull to refresh

Comments 18

Ну и… блин, даже не сказать культурно…
Статья, точнее статеечка, не отвечает на вопрос, поставленный в заголовке.
Так, махание лозунгами, не более.

Да и с русским в тексте много проблем.

Полностью согласна с комментарием выше. Автор просто написал общие принципы, о чем не нужно забывать, когда вообще хоть какие-то процессы управления внедряются.
Особенностями внедрения Agile даже и не пахнет

Статейка уровня булшит-презентаций, когда рассказывают о космических кораблях на волне хайпа.
Где ваши истории успеха?
Где lessons learned? (Не знаю как это перевести на русский, сорри)
Где ограничения применимости методологии?

Если в компании часть сотрудников токсично влияют на работу других и мешают изменениям, нужно прощаться с такими людьми.
Как правило такое впечатление производят неравнодушные люди, указывающие на критичные недостатки продукта или бизнеса. Вместо того, чтобы прислушаться, конечно, проще признать «токсичными».

Тут речь про мешающих другим, критики процессов — полезные люди, пока их критика базируется на ценностях agile. Их ещё называют скрам мастерами

А судьи кто?
Или как обычно, критиковать можно, но только в русле «линии партии».
А какая сейчас «линия партии» нужно догадаться самому :-)
Токсичность — это не про критику.
Токсичность — это отравление командной работы в буквальном смысле. Токсичность нельзя ни с чем перепутать. Токсичность лечится только у молодых, у состоявшихся к сожалению не лечится, и остается только избавляться от токсичных.
Конечно, молодыми легче манипулировать, чем теми, кому за 40. Которые имеют свое устоявшееся мнение, опыт и не ведутся на корпоративные заманухи в ввиде бесплатного боулинга, дартса и печенюшек в офисе. Они циничны, ввиду того, что предвидят результат еще до начала работ. Все это и воспринимается как «токсичность» бездарными руководителями, зачастую не имеющие достаточной квалификации в своем бизнесе.
Манипуляции, истинные, кстати тоже токсичны.

Предвидеть — это хорошо.
Бездарные руководители есть.
Так же как и токсичные сотрудники.
От тех и других нужно избавляться.
Если руководитель заходит на Stand Up в одну из команд и в комнате виснет гробовая тишина, то что-то здесь не так.

Да, что-то не так. А именно — руководитель не должен присутствовать на стендапе. You are not welcomed here.
Почему не должен присутствовать?
Первое правило стендапа — никому не говорить о стендапе :)
Если мерить рамками Agile, стендап — это в первую очередь встреча участников разработки, на которой они актуализируют текущее состояние разработки, намечают способы разрешения проблем, координируют действия между членами команды. Это если кратко.
Присутствие любого руководящего лица на стендапе не приветствуется, так как, помимо того, что руководитель не может внести какую-либо ценность в саму разработку (это главное!), он еще и демонстрирует некую определенную степень недоверия к команде, тем самым нарушая принцип саморегулирующихся команд.
Самое сложное — убедить руководителя (это если он хочет продемонстрировать свою вовлеченность в процесс) в том, что стендап — это не совещание.
Категоричность — это то что мне нравится.

Руководитель присутствует на любом движняке не для того, чтобы своими руками заменить руки сотрудников (руки можно заменить любые другие части тела). Руководитель хочет из первых рук получить картину происходящего. Если что-то буксует, почему бы не выйти в поле. Да, стендап не совещание. Но почему нельзя то…
чтобы своими руками заменить руки сотрудников

В этом случае в данном процессе руководитель имеет роль участника разработки, а значит, имеет право там находиться как разработчик. И раздавать указания не сможет :)
Руководитель хочет из первых рук получить картину происходящего

Получит, но после стендапа. Из первых рук, так как в стендапе участвуют те, кто непосредственно занимается. И да, можно прямо сразу после.
В целом, если в компании практикуется участие руководителя в стендапе, это их дело. Я рассуждаю с позиции Agile.
Agile то как запрещает посещение стендапов? Главное не нарушать правил стендапа.

Так все таки руководитель не может посещать стендап, или не должен раздавать указаний на стендапе? ;)
То, что вы пытаетесь сделать, называется подменой понятий. Вы не адвокат часом? Изо всех сил, любой ценой, цепляясь за каждую букву, пытаетесь заставить меня согласиться с вами, как будто мир рухнет.
Agile то как запрещает посещение стендапов? Главное не нарушать правил стендапа.

Правило стендапа — в нем должны участвовать только непосредственные разработчики или те, кто вносит ценность в спринт. Изначально фраза звучала «Если руководитель заходит на стендап...» Это означает, что в описанном случае НЕ является участником стендапа и НЕ является разработчиком. Просто зашел послушать. Это нарушение правил.
Рискну предположить, что Вы являетесь таким руководителем, или у вас в компании такое практикуется. И, видимо, Вы точно так же давите на разработчиков на стендапах, которые посещаете. Но это только предположение, основанное на нашем диалоге.
На этом предлагаю его закончить.
В правилах стендапа вашей команды?
Или некоторых референсных правилах стендапа? Если второе, можете дать ссылку на эти правила?
Sign up to leave a comment.

Articles