command and control OVER agile management

[Alexey Krivitsky]

всем привет

немного философии. об этом много пишут. но тем не менее это не помагает...

все кто ценят agile подходы и в частности скрам,
знают что подход в управлении, который основан на диктовании стратегий эффективен только в кратковременном плане -
пока есть тот, кто дает команды и то, при условии, что он один может все просчитать и предвидеть.

более же эффективным в долгосрочной перспективе является подход в делигировании решений на ступени,
максимально близкие к людям, которых они касаются.

что это дает?
во-первых, людям будет интереснее работать. во-вторых - в итоге не только менеджер будет отвечать за успех проекта,
его качество и характеристики, а и все члены команды - что несомненно приносит положительные результаты.
во-третьих - быть руководителем в таком проекте намного легче и менее болезненно.

но.. тяжело перестать отдавать команды и начать слушать. особенно же, если вы знаете "то самое правильное решение".
когда команда обсуждает решение тяжело устоять и не сказать: "так стоп. делаем вот так...".
достаточно так сделать - и всё. это уже не agile, не scrum, не lean. вы вернулись на первую ступень развития менеджера.
начинайте все сначала.

а теперь тест.
как часто вы как руководитель или лидер говорите команде что-то вроде
"вам делать, вам и решать" или
"вы лучше меня придумаете как это лучше сделать" или
"решите сами".


леша.

[Serhiy Yevtushenko]

Привет.
А теперь еще один маленький ньюанс:
кто из скрам мастеров является членом команды (работает в небольшой комманде).
Как часто его обязанности как члена комманды вступают в противоречие с его обязанностями как скрам мастера?

Как вы разделяете свою ответственность как скрам мастера (фасилитатора митингов) и свою участие в митинге как участника команды ?

20.07.07, Alexey Krivitsky <alexeyk...@gmail.com> написал(а):

[Alexander Lockshyn]

Думаю, тут для нашей отрасли есть еще одна отягощающая причина: как
правило руководителями проектов/команд в IT становятся люди сами
бывшие техническими специалистами (при том довольно опытными в
большинстве случаев). Таким людям первое время бывает тяжело
согласиться с решениями команды, если они объективно видят, что эти
решения не идеальны.

Мне кажется, самый очевидный вариант решения таких проблем --
предлагать свои варианты решения (если они есть) команде,а команда уже
должна решать как им поступить. Ну и, естественно, заботится о
повышении профессионального уровня команды, чтобы они чаще принимали
"правильные" решения.

[Theme]

On Jul 20, 3:33 pm, Alexander Lockshyn <redw...@gmail.com> wrote:
>
> Мне кажется, самый очевидный вариант решения таких проблем --
> предлагать свои варианты решения (если они есть) команде,а команда уже
> должна решать как им поступить. Ну и, естественно, заботится о
> повышении профессионального уровня команды, чтобы они чаще принимали
> "правильные" решения.

IMHO если кто-то опытнее, он должен обосновать почему его подход
лучше, иначе это простой диктат.
Я часто сталкиваюсь когда "опытные" люди говорят: это сделать
невозможно, это делаем так-то и так-то...
На вопрос "Почему именно так ?" они ответа дать зачастую не
могут... :)
Мне кажется, лучший способ направить комманду на путь истинный, это
задавать вопросы. Т.е. вы с высоты
своего опыта видите, где будет проблема, и спрашиваете "Как ваш подход
решает вот такую-то задачу?" и вот тогда
команда начинает думать :)
Правильно поставленный вопрос нетёс в себе половину ответа, и команда
сама прийдёт
в результате к наилучшему решению.
Такая тактика мне кажется лучше предложения своего варианта, поскольку
тут нет "предложения от начальника" что
снимает частичто ответственность с работника и ухудшает его
эффективность, и нет эффекта "своя рубашка ближе к телу",
когда каждый стремится протащить свой вариант потомучто он свой.
Вы вместе идёте к решению, что всегда приятно для менее опытного
человека :)

[kin...@gmail.com]

> Думаю, тут для нашей отрасли есть еще одна отягощающая причина: как
> правило руководителями проектов/команд в IT становятся люди сами
> бывшие техническими специалистами (при том довольно опытными в
> большинстве случаев).

Не думаю, что это мешает, наоборот, это позволяет лучше
ориентироваться, что происходит в проекте. Все остальное лечится
разграничением обязанностей: только человек, закомитившийшся на
стори, принимает окончательное решение. Не нравится решение -
возьмите разработку стори на себя и делайте как считаете нужным.
Только потом сами отчитывайтесь перед заказчиком, почему вы не успели
ее закончить :)

[kin...@gmail.com]

> кто из скрам мастеров является членом команды (работает в небольшой
> комманде).

Я так делаю

> Как часто его обязанности как члена комманды вступают в противоречие с его
> обязанностями как скрам мастера?

Бывает, когда вам надо закончить к концу итерации свою свою стори, а
при этом еще надо решить проблемы разработчиков, пособеседовать нового
человека, да мало ли чего еще. В таких случаях все просто - система
приоритетов помогает (прийдется вам не успеть доделать ваше задание -
старайтесь не комититься в что-то важное)

> Как вы разделяете свою ответственность как скрам мастера (фасилитатора
> митингов) и свою участие в митинге как участника команды ?

На митинге - вы - скрам мастер, прежде всего, иначе когда вы не СМ, то
кто выполняет его роль? Отчитываетесь перед командой за свою работу
как и все остальные, я не вижу тут противоречий.

[Olex]

Интересная тема.
Иметь классического фасилитатора большая роскошь для маленьких
команд.

Я вижу это так:

1. Все должно быть нацелено на эффективность. Глупый выбор - быть
"настоящим скрам-мастером" ИЛИ отстаивать свои идеи.
2. Суть фасилитатора не подвести команду к понимаю того что он знает.
Наводящими вопросами и т.д.
Зачем этот цирк? Есть мысли - говори наравне со всеми. Суть в том
чтобы общими усилиями сгенерировать лучшие идеи.
3. Чтобы не уходить в стороны - четкий гоал, план и тайм-бокс на
каждый митинг.

2Sergey
Ну не вижу я тут конфликта. А ты сам что думаешь?

[Serhiy Yevtushenko]

25.07.07, Olex <olexandr....@gmail.com> написал(а):

Интересная тема.
Иметь классического фасилитатора большая роскошь для маленьких
команд.

Я вижу это так:

1. Все должно быть нацелено на эффективность. Глупый выбор - быть
"настоящим скрам-мастером" ИЛИ отстаивать свои идеи.
2. Суть фасилитатора не подвести команду к понимаю того что он знает.
Наводящими вопросами и т.д.
Зачем этот цирк? Есть мысли - говори  наравне со всеми. Суть в том
чтобы общими усилиями сгенерировать лучшие идеи.
3. Чтобы не уходить в стороны - четкий гоал, план и тайм-бокс на
каждый митинг.

2Sergey
Ну не вижу я тут конфликта. А ты сам что думаешь?

Я на основании своего опыта в своей конкретно комманде вижу.
Какие моменты вызывают конфликт (тут включается не только императивный стиль управления против стиля управления, направленного на сотрудничество)
1) Роль фасилитатора и участника митинга. Как только начинаеш активно участвывать, высказывать свое мнение, то теряеться роль фасилитации, то есть обеспечение процесса сотрудничества. Наличие своего мнения мешает нейтральности в обсуждении. Это больше всего относиться к ретреспективам.

2) Разделение коммитментов по тому, что берешь на себя как член комманды, и того, что должен делать как скрам мастер. При этом задачи скрам мастера часто  (в моих конкретных условиях) являються важными, но длительными по внедрению (пример - изменение branching policy для существующего проекта, делающего регулярные и частые релизы)
3) Конфликт интересов как члена команды и как скрам мастера.
Пример - нечетное количество людей в команде при работе с парным программированием.
Как член команды, тебе тоже нужна пара или ревьювер, с другой стороны - люди беруться за задачу, на которую коммитились, в паре, и оценивают, что у них не будет времени ревьювить твою задачи и завершить свою, поэтому твоя задача страдает.

[kin...@gmail.com]

> 1) Роль фасилитатора и участника митинга. Как только начинаеш активно
> участвывать, высказывать свое мнение, то теряеться роль фасилитации, то есть
> обеспечение процесса сотрудничества. Наличие своего мнения мешает
> нейтральности в обсуждении. Это больше всего относиться к ретреспективам.

Много дебатов в команде? Тут ничего не поделаешь - навязывание своего
мнения не работает, поверь. Я тоже прошел через это - оставь все как
есть, со временем команда сама прийдет к правильному виденью. Думаю,
что лучше на время уйти от "полярных" тем. Старайся подбирать новых
людей грамотно, которые бы разделяли твои идеи - тогда они (новые
люди) начнут толкать команду в нужном направлении изнутри.

> 2) Разделение коммитментов по тому, что берешь на себя как член комманды, и
> того, что должен делать как скрам мастер. При этом задачи скрам мастера
> часто (в моих конкретных условиях) являються важными

Не бери на себя такие задачи. Как СМ ты должен устранять конфликты, а
не порождать новые. Точка.

> 3) Конфликт интересов как члена команды и как скрам мастера.
> Пример - нечетное количество людей в команде при работе с парным
> программированием.

Опять повторюсь. Не можешь эффективно выполнять програмистские задачи
- не бери их. В одном проекте, где было всего 2 разработчика, я не
кодил вообще - взял на себя общение с заказчиком, координацию с QA и
всю черновую работу: подготовка инсталяций, администрирование, ...
Если есть интерес и желание, можно брать какие-нибудь
исследовательские задачи, это, как правило, отдельный thread,
пересечений с основными задачами - минимум - меньше конфликтов.

[Alexey Krivitsky]

что лучше
1 плохой SM, но зато хороший девелопер
2 хороший SM, но не пишущий код?

[Артур Ракицкий]

IMHO, второй вариант предпочтительнее. Особенно, если SM (да и, безотносительно agile, PM) все же разбирается в технологиях и может качественно выполнить Code Review при возникновении каких-либо проблем/багов. В этом случае, даже не создавая код, SM все же является разработчиком, и не занят организациооными вопросами на 100% :)

А первый вариант зачем вообще обсуждать? Идеальных команд не бывает, и плохой SM, IMHO - это хуже чем вообще без SM. Под "плохим" я понимаю человека, который на эту роль не подходит (по характеру, складу ума, организационным скилам), а не того, кто подходит, но еще не обладает всеми навыками и знаниями.

11.08.07, Alexey Krivitsky <alexeyk...@gmail.com> написал(а):

--
С уважением,
Артур Ракицкий

------------------
ICQ: 21062147

[Yuriy Mann]

Полностью поддерживаю взгляды А. Локшина и Олекса.

Другими словами: нет смысла создавать искусственную "непричастность" к
решениям. Глупо СМ держать в тайне свои идеи, просто чтобы не
"спугнуть" скрамовский дух команды. В реальности, надо признать,
разработческий опыт СМ минимум не хуже среднего уровня по команде -
зачем же интригантски таить интересные мысли, если можно выложить их
как пищу для обсуждения остальной команде. Единственное условие: все
время напоминать команде, что окончательное решение и ответственность
за него - на ней. Ну и демонстрировать это другими возможными
способами - это уже скорее вопрос правильного психологического
подхода, и такой подход важен независимо от того, вмешиваетесь вы в
обсуждения команды или нет.

Как вариант, можно взглянуть на СМ как на стороннего консультанта,
который предлагает лучшие, с его точки зрения, решения на рассмотрение
команды. Как технические, так и по планированию. Право команды -
выбирать.

On Jul 20, 3:33 pm, Alexander Lockshyn <redw...@gmail.com> wrote:

[Alexey Krivitsky]

привет, привет!

согласен со всеми ;)
не стоит стоять в стороне, если ты реально можешь помочь.
но все-таки не стоит в то же время отталкивать локтями тех, кто взял на себя ответственность что-либо сделать
с криками: "не так, смотри как надо!".

СМ, как мне кажется, на раннем этапе формирования команды, должен быть примерным членом команды:
- давать commitments,
- отвечать за качество работы
- быть хорошим партнером для pair programming,
- правильно рапортовать на утреннем митинге,
- быть готовым помочь каждому,
- быть позитивным и конструктивным во всём что происходит в проекте
- разрешать (и иногда и провоцировать) конфликты - учить команду общатсья
и что довольно важно - не отбирать возможность у других людей ошибаться, всё-таки учиться на своих ошибках необходимо.

но это все на раннем этапе. когда же в команде уже успешно работает 5 и более человек, эти навыки уже должны перейти ко всем членам команды, и больше пользы СМ уже сможет принести, будучи 100% СМом.

такие вот мои мысли, братья. ;)

Лёша.

[Artem Marchenko]

Привет всем

Я тоже так считал раньше.

Мне кажется, поведение в такой ситуации слишком сильно зависит от
контекста, чтобы давать конкретные рекоммендации. Тем не менее, "as a
rule of thumb" в подобных ситауациях я бы держал идеи при себе и не
предлагал слишком много своих - как максимум, чуть больше, чем просят.
Можно ещё рассказывать о вариантах работающих для других команд, но,
желательно, вне "предметного" разговора.

Говорю это совсем недавно обжёгшись на подобной ситуации. Ситуция
только отягчалась тем, что будучи СМ, в ряде областей я оказался самым
опытным человеком. Каким опытным бы ни был СМ, свои знания не положишь
в голову соседям.. Можно обучать, но это не происходит за один день.
Можно рассказывать о возможных вариантах, но нужно быть очень
осторожным, чтобы команда не отмахнулась "ну, давай сделаем как ты
говоришь", морально снимая с себя ответственность. То, что СМ считает
лучшим для себя, совершенно не обязательно окажется лучшим для
команды. Например, что толку рассказывать о преимуществах юнит-тестов
и continuous integration, если СМ - единственный, кто может их
поддерживать?

Мой опыт не претендует на абсолютную истину. Разумеется, могут быть
ситуации, когда СМ лучше всего быть "примерным членом команды". Тем не
менее, даже в таком случае я считаю очень важным, чтобы роли СМ и
члена команды были очень чётко различимыми, чтобы всегда было очевидно
в какой момент СМ говорит как СМ, а когда предлагает идеи как член
команды. Иначе слишком велик шанс, что в какой-то момент команда
примет "мнение" СМ-члена команды за указание СМ-проджект менеджера.

Знаю, что некоторые команды в подобных случаях находят полезным
специальный символ с помощью которого легко (и весело) можно
определить когда СМ - СМ, а когда член команды. Например, он может
снимать/надевать кепку СМ. Лично я, в случаях когда приходится
доставлять мнение Product Owner или когда никак не могу удержаться от
технического совета, совершаю такое детское движение головой - как бы
"выхожу" из роли СМ, и "захожу" в другую. Смешно и по-детски - зато ни
малейшего сомнения, что мой совет - это не прямое руководство к
действию

Всем удачи!
Артём.

P.S.
Мой Scrum trainer говорил: "Если СМ приходится о чём-то думать так
сильно, что болит голова, скорее всего это не его дело" :)

On 12 авг, 17:28, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:

> привет, привет!
>
> согласен со всеми ;)
> не стоит стоять в стороне, если ты реально можешь помочь.
> но все-таки не стоит в то же время отталкивать локтями тех, кто взял на себя
> ответственность что-либо сделать
> с криками: "не так, смотри как надо!".
>
> СМ, как мне кажется, на раннем этапе формирования команды, должен быть
> примерным членом команды:
> - давать commitments,
> - отвечать за качество работы
> - быть хорошим партнером для pair programming,
> - правильно рапортовать на утреннем митинге,
> - быть готовым помочь каждому,
> - быть позитивным и конструктивным во всём что происходит в проекте
> - разрешать (и иногда и провоцировать) конфликты - учить команду общатсья
> и что довольно важно - не отбирать возможность у других людей ошибаться,
> всё-таки учиться на своих ошибках необходимо.
>
> но это все на раннем этапе. когда же в команде уже успешно работает 5 и
> более человек, эти навыки уже должны перейти ко всем членам команды, и
> больше пользы СМ уже сможет принести, будучи 100% СМом.
>
> такие вот мои мысли, братья. ;)
>
> Лёша.
>

[Borys Lebeda]

Конечно второй вариант предпочтительнее, уж тем более если речь идёт о SCRUM. По ряду причин:

1) Зрелой команде техническое решение предпочтительнее решение принимать самой

2) Технический руководитель большую часть времени тратит на консультации по технической же части. Если он при этом ещё и программирует, то времени на impediments не технического плана уже не остаётся. А они чаще всего и позиционируются как объекты интереса SM

3) Если SM не программист, разделение ролей в SCRUM происходит естественным путём.

 

Я бы поставил обратный вопрос: бывает ли ситуации, когда Scrum мастеру нужен поможник непрограммист? Это вопрос практический, а не теоретический ...

 

На этой картинке правды больше чем юмора:

http://lestnizza.com/upload/image/it_range.jpg
ПМ этот как раз тот, который протирает фуражку кастомеру или топ менеджеру

[alexey]

есть другой вариант решения этой проблемы.
решить её по-скрамовски:
вместо того, чтобы опять таки принимать решение за команду типа "что
делать? быть СМ или девелопить?"
можно просто предоставить этот выбор самой команде.

когда нужна будет тех помощь - вас попросят применить или поделиться
вашими programming skills.
когда кол-во или тягость импедиментов привесит какой-то уровень - вас
попросят все бросить и бежать решать проблемы

[Tim Yevgrashyn]

On 25/07/07, Serhiy Yevtushenko <syevtu...@gmail.com> wrote:

Я на основании своего опыта в своей конкретно комманде вижу.
Какие моменты вызывают конфликт (тут включается не только императивный стиль управления против стиля управления, направленного на сотрудничество)
1) Роль фасилитатора и участника митинга. Как только начинаеш активно участвывать, высказывать свое мнение, то теряеться роль фасилитации, то есть обеспечение процесса сотрудничества. Наличие своего мнения мешает нейтральности в обсуждении. Это больше всего относиться к ретреспективам.

 

Наш тренер (Майк Виздос) дал интересный совет, если вы в такой ситуации:

- Попробуйте пообщаться с кем-то одним из команды и пусть он вместо вас выскажет мысли на митинге. Тогда вы по прежнему держитесь за роль фасилитатора и смотрите на развитие ситуации.

- В худшем случае, когда высказаться самому очень нужно, то пригласите для фасилитации кого-то со стороны. Например коллегу СМа из другого проекта.

 

2) Разделение коммитментов по тому, что берешь на себя как член комманды, и того, что должен делать как скрам мастер. При этом задачи скрам мастера часто  (в моих конкретных условиях) являються важными, но длительными по внедрению (пример - изменение branching policy для существующего проекта, делающего регулярные и частые релизы)

 

А почему, собственно, "изменение branching policy" ты не ставишь в Product Backlog? Ты сам мне неоднократно говорил, что PB должен отражать все нужды проекта :-)

Заведи PBI, оцени и возьми его в работу на спринт для себя. Тогда и всем будет виден прогресс и заодно сбалансируешь свою нагрузку.

 

 

3) Конфликт интересов как члена команды и как скрам мастера.
Пример - нечетное количество людей в команде при работе с парным программированием.
Как член команды, тебе тоже нужна пара или ревьювер, с другой стороны - люди беруться за задачу, на которую коммитились, в паре, и оценивают, что у них не будет времени ревьювить твою задачи и завершить свою, поэтому твоя задача страдает.

 

Тут тоже вопрос из области здравого смысла. Почему, например, команда не планирует ревью друг-друга помимо пары? Эдакие коллективные обзоры общего кода :-) 

И опять же, почему команда не может выделить своего времени на ревью твоего кода при планировании? Это вопросы правильного планирования, имхо.

 

 

--
With best regards,
Timofey Yevgrashyn

[Borys Lebeda]

У меня есть дополнение по поводу пункта номер 3:

мне кажется это нехорошая практика, когда код проверяется всегда одним и тем же сотрудником. Возникает некая отчуждённость пары от общего процесса. Лучше делать "перевязки" между парами (подобно тем перевязкам которые делают строители в кирпичной кладке).

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

Это было терпимо пока таких людей не больше 4-5 ...

[Alexey Krivitsky]

Борис

я тут перечитывал посты.
касательно твоей ситуации - мне кажется что ты как scrummaster должен объяснить суть проблемы команде, спровоцировав дискуссию, возможно вынести это на ретроспективу
а там - уже им решать. если им так лучше - значит пусть так и будет.

можно договориться назначить кого-то курирующим этот вопрос как мин до следующей ретроспективы, чтобы он собрал и предоставил какие-то реальные данные.

леша.

[Borys Lebeda]

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