Как следует из названия, это продолжение серии статей про роли в scrum (часть 1 и часть 2). Сегодня рассмотрим следующую роль – scrum master. Как это ни парадоксально, успешность scrum во многом зависит от scrum мастера. Поэтому хочется снова призвать силу воображения и привести метафору (дисклеймер: пример никоим образом не должен оскорбить чьих-либо чувств). Есть культура, у которой есть свой культ, свои обряды, есть служители этого культа. Служителей можно разделить на различные классы:
- те, кто со своей культурой предпочитают быть один на один — отшельники, затворники, просветленные;
- те, кто выучили все правила, нашли лазейки, понимают, что и как делать, и используют культ в корыстных целях, наживаясь на людях, их страхах и предубеждениях;
- фанатики, которые пытаются насадить свою культуру к месту и не к месту. Для которых кроме их знаний, всё остальное ересь;
- те, кто искренне верит, чувствует и пытается поделиться, помочь и подарить это чудо людям; они рассказывают и объясняют, слушают и пытаются помочь.
Со Scrum и SM-ами, мне кажется, происходит очень похожая история. Попробуйте посмотреть на знакомых вам SM через такую призму. С какими SM вам бы хотелось работать?
Давайте разберемся, какие тревожные симптомы могут быть у SM.
Взаимодействие с владельцем продукта
Симптом: SM не работает с продуктовым backlog. Полностью оставляет его на совести PO. Ждет, что команда будет получать backlog и его элементы в необходимом им виде без участия SM.
Чем плохо: Одна из задач SM — это построение эффективного и прозрачного процесса, в котором всем участникам комфортно работать. SM необходимо следить за всеми элементами scrum, чтобы иметь возможность его улучшать, а backlog продукта — это очень важный артефакт scrum, который нельзя оставлять без внимания SM.
Как лечим: SM следует договориться с PO, чтобы вместе поработать над backlog и понять работу PO; проанализировать процесс; предложить улучшения; предложить свою помощь. SM следует узнать у команды, какие ожидания у них от backlog, как можно его улучшить. Коллективно принять решения по улучшению backlog, его элементов, процесса и активностей по взаимодействию с ним, можно посвятить этому отдельную ретроспективу. И возвращаться к этому вопрос с определенной периодичностью (помним, что в основе scrum лежит эмпирический процесс).
Симптом: SM не прислушивается к идеям / желаниям PO. Он противопоставляет себя ему. Идет местечковая война за влияние. Нет конструктивного взаимодействия между SM и PO.
Чем плохо: Мне нравится сравнение scrum команды с семьей, эта метафора очень часто помогает понять и объяснить, почему нужно делать так, а не иначе (Просто переносите ситуацию в семью, задавайте вопрос: «Как бы поступили в семье?». Часто вы сможете найти путь к ответу). Сложно назвать счастливым семейство, где постоянно ссорятся мать с отцом, ведь от этого очень сильно страдают дети (ВАЖНО: SM и PO не «родители» команде). Когда нет взаимопонимания и конструктивного взаимодействия между SM и PO, то страдать будет команда: подковерные игры, саботаж открытости и прозрачности. Если SM не может договориться с PO, то он не может решать одну из важнейших своих задач: "The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team."
Как лечим: Нужен опытный фасилитатор, который вскрыл бы причины конфликта, чтобы начать улучшать ситуацию. Активная команда и сама может начать собирать факты о деструктивном влиянии разногласий между SM и PO на результаты команды — просто записывая рабочие ситуации. А затем на ретроспективе, где присутствуют оба участника, выдать эти факты, обсудить их и попытаться найти варианты решения. Если же не удается выстроить диалог и всё сводится к поиску виноватых, а не решения, то нужно искать внешнего фасилитатора и эскалировать проблемы за пределы команды.
При этом команде важно не вставать ни на чью сторону: «не втягивайте нас в споры, как договоритесь, так дайте нам знать о решении». Такая позиция будет индикатором существующей проблемы для SM и PO.
Взаимодействие с командой
Симптом: Scrum master не «проповедует»: не объясняет сути элементов scrum, не проводит обучения, игры, тренинги, позволяющие команде лучше понять scrum и приобщиться к agile культуре. Не объясняет и не даёт команде ответов на вопросы, связанные с процессом. Не знает текущего уровня принятия и понимания scrum членами команды.
Чем плохо: Если нет регулярных встреч команды, где обсуждается scrum, то понимание и вера во фреймворк уходят. Любая культура (agile не исключение) требует подкрепления (не путать с карго-культом), скорее всего не будет работать схема: прошли тренинг, знаем scrum, scrum взлетел. С течением времени люди накапливают опыт, у них появляются новые вопросы, которые требуют внимания, объяснения. Если не помогать людям разбираться, то они перестанут жить с этими идеями, а утонут в проблемах и непонимании, в конечном счете, разочаруются.
Как лечим: SM, в первую очередь, должен все время обучаться сам, общаться с коллегами, читать статьи, посещать митапы, конференции и т.д. Этими знаниями он должен регулярно делиться с командой / PO / своей организацией: проводить тренинги и игры, иллюстрирующие принципы agile / scrum. Команда / компания развиваются, и надо давать актуальные знания, соответствующие текущим потребностям и запросам. Чтобы осознать эти потребности, нужно больше общаться с людьми на тему процессов и сложностей в работе. SM должен регулярно проводить личные беседы с каждым членом команды, чтобы понимать какие есть ожидания, проблемы, уровень понимания scrum в команде. Как и во многом, что касается scrum, важно задать ритм активностей по развитию agile культуры и scrum внутри команды / компании.
Симптом: Частичный SM, например, по совместительству с другой ролью. Причем scrum-мастерит он, когда есть на это время, по-остаточному принципу.
Чем плохо: Если SM полностью не отдается задаче развития scrum в команде / компании, а совмещает это с другой деятельностью, то скорее всего будут страдать все результаты. Быть хорошим SM непросто, а если делать это урывками, то scrum скорее всего будет деградировать. Например: если человек совмещает роли разработчика и SM, в случае проблем с достижением цели спринта, он скорее бросится делать задачи сам, чтобы достичь цели. А это плохо! Самое правильное поведение SM в этой ситуации — настроить команду на достижение результата, развить команду, помочь ей стать лучше.
Как лечим: Если мы говорим про работу SM в еще незрелой команде, то нужно попытаться изыскать способы освободить SM от любой другой работы, кроме scrum-мастерства. Это можно предложить как эксперимент на несколько спринтов, чтобы понять, что это дает команде. Если организация находится на пути апробации agile и scrum, на это должны дать зеленый свет. После проведения эксперимента стоит всеми заинтересованными лицами оценить результаты и принять решения о судьбе scrum, выделенных SM и agile культуры вообще.
SM, вырастивший зрелую команду, в которой bus factor больше одного и работа делается в отсутствии SM, может позволить себе совмещение или работу со второй командой (но не забывая о первой, возможно, воспитывая там замену себе).
Симптом: SM не фасилитирует встречи и совещания. Может либо тянуть одеяло на себя, «знает» ответы на все вопросы, не дает высказываться членам команды. Либо не «ведет» собрания, просто собирает людей, а дальше пускает все на самотек.
Чем плохо: Если SM не фасилитирует, не помогает выстраивать эффективные коммуникации (между членами команды; общение с PO, стейкхолдерами и др.; проведение встреч; и т.д.), то на коммуникации может тратиться много энергии, которую можно было бы направить на разработку продукта. Встречи могут не достигать возложенной на них задачи. Могут возникать конфликты из-за непонимания. И из эффективного инструмента принятия решений, собрания скорее всего превратитятся в источник стресса. А доминирование SM на общих собраниях будет демотивировать команду и негативно сказываться на инициативе и самоорганизации.
Как лечим: SM должен уметь фасилитировать. Его задача — выстроить открытые коммуникации внутри команды; настроить взаимодействие команды с внешним миром; научить команду проводить полезные собрания. SM должен сам осознавать необходимость того или иного собрания, сформулировать цель и повестку встречи, заранее обозначить продолжительность. Во время встречи нужно следить как за повесткой, так и за выделенными временными рамками, прерывать обсуждения на отвлеченные темы, например: «к этой теме мы обязательно вернемся позже, она записана, а сейчас давайте продолжим обсуждение нашего текущего вопроса». Можно попросить кого-то из участников помогать в проведении собраний (или делегировать проведение части собраний команде). В конце каждого собрания важно подводить итог и фиксировать результат. Полезно внедрить инструменты оценки встреч, чтобы в конце участники потратили еще несколько секунд и дали обратную связь (строим эмпирический процесс, там где он может быть полезен). Все результаты стоит донести до всех заинтересованных лиц по завершении встречи, например, письмом.
Симптом: SM не формирует из группы людей настоящую scrum команду. Не выстраивает доверительные профессиональные отношения, не сглаживает углы.
Чем плохо: нежелание общаться, конфликты, нерабочая атмосфера — негативно сказываются на результатах команды. Сплоченные команды дают лучший результат при прочих равных.
Как лечим: одна из важных задач SM сделать так, чтобы группа людей стала командой, т.е. вырастить команду и сделать её зрелой (когда SM стоит в стороне и умиляется). Для этого нужно как можно больше времени проводить с командой, примечать конфликты, чтобы их можно было разрешить и не дать им развиться, понять, как строятся коммуникации (если сидя рядом люди не разговаривают, а пишут друг другу email — это тревожно). SM должен на реальных ситуациях демонстрировать преимущества живого общения над перепиской. Он должен добираться до корневых причин конфликтов и разногласий и помогать людям договариваться друг с другом. Полезный инструмент для анализа — это построение графа коммуникаций (ставим вершинами каждого члена команды, а ребра — это каждый факт общения), анализируя его, можно поискать слабые стороны в коммуникациях (например, общение через одного члена команды — он "узкое горлышко"; либо отсутствие общения между конкретными парами людей). На его основе можно создавать ситуации для «выравнивания» коммуникаций, в которых вы объединяете «не общающихся» людей; и наоборот исключаете из некоторых ситуаций человека, на котором общение замыкается. Полезно и интересно следить за динамикой развития такого графа.
Симптом: SM не развивает команду, не предлагает постоянные изменения, не выводит команду из зоны комфорта, не поддерживает инициативы, а довольствуется текущими успехами: «Мы классные! Мы команда!»
Чем плохо: Если SM не является двигателем изменений (и развития), то скорее всего его команда будет деградировать. Подталкивать к изменениям могут любые участники процесса, но на это не стоит расчитывать. Без изменений в попытке улучшиться, команда со временем будет отставать от требований. Agile — это про способность быстро адаптироваться к изменениям.
Как лечим: SM должен быть инициатором изменений, предлагать пробовать новое в процессах, задачах, внедрять инженерные практики. Нельзя пребывать в состоянии покоя, нужно искать возможности для улучшений. Чтобы понимать, какие изменения делаются и в каком состоянии находятся, можно повысить прозрачность и визуализировать процесс. Работа с командой и её развитие – это работа такая же, как и создание продукта. SM может завести свою доску, на которую он будет помещать эксперименты, action items с ретроспектив, инициативы и т.д. Отсутствие изменений на доске может быть индикатором застоя деятельности SM. Долго работая с командой, у SM может замыливаться взгляд, есть угроза перестать видеть возможности для улучшения, тогда можно либо оставить команду одну на какое-то время (с одной стороны это полезно SM, с другой стороны это хорошая проверка зрелости команды, как они себя поведут в отсутствии SM), либо попросить помощи со стороны, например, договориться с SM соседней команды поменяться на некоторое время, чтобы помочь друг другу найти точки роста.
Симптом: SM позволяет работать не по scrum, спокойно относится к саботажу. Например:
"- да вроде же спринт прошел без факапов, давайте ретру не будем проводить, что обсуждать то?
— ок, проведем в следующий раз."
Чем плохо: Если SM не отстаивает чистоту и необходимость scrum перед командой, PO, компанией, то вряд ли это будет делать кто-то еще. Если принципы не защищаются, то нет ощущения их важности и полезности. SM положено быть очень адаптивным и лояльным к любым изменениям. Хороший SM не говорит «нет», он говорит «давайте попробуем. Проведем эксперимент.». Но относительно принципов фреймворка scrum нужно быть стойким и четко понимать, какие есть артефакты, события, ритуалы, ценности и прочие элементы scrum, и для чего они необходимы, какие задачи решают. Фреймворк меняют уже зрелые команды, на этапе становления scrum нельзя давать слабину и отходить от scrum guide (нарушив одно из правил, встаёт резонный вопрос: а почему бы не нарушить и другое?).
Как лечим: одна из задач SM — следить за «чистотой» scrum, и, пока команда не достигнет зрелости, он должен подавлять все бунты и саботажи, направленные на scrum. SM полезно проводить упражнения по взаимодействию со скептиками. Хорошо найти подкованного «скептика», например, коллегу SM и проводить с ним упражнения: попросить его саботировать scrum, а SM должен парировать. Нужно быть готовым отвечать на вопросы, зачем мы проводим scrum события, что плохого, если мы пропустим одно из событий, зачем мне (члену команды) делать что-то. Если SM сам не знает ответов, то стоит обратиться к сообществу, посетить тренинг, почитать литературу.
Симптом: SM выдает распоряжения членам команды, ведет себя как директивный руководитель. Такое может случаться, если роль SM отдали бывшему линейному руководителю, при этом не объяснив, что должно измениться в работе, подходах, коммуникациях.
Чем плохо: Когда SM ощущает власть и начинает вести себя как директивный руководитель (распределение задач, вещание на собраниях и т.д.), это убивает командность, демотивирует людей, и это уже не scrum. Можно ставить крест на самоорганизации.
Как лечим: хороший вариант — это отправить такого SM на тренинг, где ему расскажут об agile культуре, дадут новые инструменты работы с командой. Другой более сложный вариант — самой команде пытаться менять коммуникации с SM: строить диалог, брать на себя ответственность при принятии локальных решений, предлагать альтернативы решениям SM. Еще можно подумать о переходе роли к другому члену команды.
Взаимодействие с компанией
Симптом: Scrum master не разделяет ценностей agile. Это культура ему не близка, сам он придерживается других взглядов. Так бывает если SM назначили человека, а не сам он проявлял желание выполнять эту роль.
Чем плохо: Если человек не верит в культуру agile, не разделяет ценности, но при этом он SM, то скорее всего он преследуют весьма корыстные цели, и вряд ли сможет принести в этих условиях пользу команде, продукту, компании.
Как лечим: Ищем / воспитываем / обучаем SM, понимающего и разделяющего ценности agile, и осознавшего scrum: что и для чего делается. Ставим ему задачу запустить scrum, даем команду, PO, продукт. Важно осознать, какие задачи стоят перед scrum в организации. Нужно сразу определить, как мы поймем, что scrum работает, как мы будем это оценивать, с помощью каких метрик.
Симптом: SM не занимается организацией обмена опытом между командами. Не транслирует успехи команды на уровень компании. Не обеспечивает прозрачность результатов и процессов его команды для всей организации.
Чем плохо: команда существует внутри компании, она обладает высокой степенью автономности, но тем не менее тесно связана с компанией. Если команда замкнута на себе, то она может оторваться от реалий компании, может стать ненужной или неактуальной, могут возникать неоправданные ожидания в обоих направлениях и т.д.
Как лечим: Все зависит от уровня agile в компании и задач, стоящих перед командой. В целом, это очень большой спектр вариантов, но рассмотрим упрощенные случаи:
- Пилотная команда в компании, думающей о применений scrum: Это настоящий вызов для SM. Его команда под пристальным взглядом всей компании. Как можно поступить:
- Выяснить (возможно разработать совместно с инициаторами изменений) какая задача стоит перед scrum в компании? Для чего запускается «пилот»? Какая гипотеза проверяется? Как будет оцениваться результат? Договорится о длительности эксперимента и о точке принятия решения о судьбе scrum в компании.
- Донести эту информация до команды. Разработать визуализацию индикаторов, за которыми собирается следить компания. Регулярно актуализировать визуальные индикаторы.
- Максимально открыто вести работу. Давать возможность работникам компании наблюдать за новыми для компании процессами, только не в ущерб команде. Регулярно информировать о ходе работы всю компанию.
- К назначенному сроку подготовить данные о результатах, полученных во время проведения эксперимента (работы пилотной команды). Провести обширную ретроспективу по решению судьбы scrum в компании.
- Одна из команд в компании, где часть сотрудников работают по scrum, а часть нет: Скорее всего компания находится в процессе перехода. И SM должен помогать переходу всей компании на scrum. Что можно делать в таком случае:
- Поддерживать прозрачность относительно процессов и результатов команды, распространять эту информацию внутри компании (открытые sprint review, информационные рассылки и т.п.).
- Организовать лигу SM, где «опылять» друг друга свежими идеями, практиками. Делиться опытом и оказывать друг другу поддержку.
- Совместно с другими SM бороться с организационными дисфункциями.
- Принимать участие в работе «не scrum» сотрудников, обучать их scrum, предлагать изменения в их процессах (если изменение может привести к улучшению).
- Команда в компании полностью работающей по Scrum и применяющей различные способы масштабирования scrum: LeSS, SAFe, Nexus и т.д.: Тут на плечи SM ложится вопрос синхронизации команд. У меня нет реального опыта работы в подобных компаниях, поэтому воздержусь от предложений. Но было бы очень интересно почитать про ваш опыт — пишите в комментариях.
Заключение
Еще раз кратко напомню (см. заключение первой части) что делать с полученной информацией:
- выбираем самый актуальный для себя симптом;
- обсуждаем с командой его негативное влияние, как отправная точка к рассуждениям берите мои тезисы;
- командой придумываете способы снять симптом;
- делаете то, что придумали;
- анализируете полученные результаты;
- повторите с первого пункта.
За три статьи мне удалось описать самые очевидные симптомы ролей в scrum. При этом описание ролей в scrum guide занимает 3 из 19 страниц. Scrum guide говорит «что» нужно делать, но оставляет на усмотрение команд «как делать», потому что это сильно зависит от конкретной ситуации. Мне кажется, важно делиться своими опытом и практиками того, «как» именно вы делаете. Хочется верить, что материал оказался полезным и вы взяли на вооружение «медицинские» карточки, описанные в этой серии статей.
За иллюстрации огромное спасибо Sai Kin!
Комментарии (30)
Fengol
08.07.2018 18:05Самое главное на чем стоит сфокусировать все свое внимание при разработке ПО, это программисты!
Всем руководителям к программистам нужно относится, как к летчикам самолета, на борту которого они находятся. Чуть Вы их напрягете, сразу же почувствуете крен или тряску.
Поэтому не понятно зачем программистам растолковывать основы scrum идеологии и тем самым попросту захламлять их рассудок. Если управленец считает, что посвятив в тонкости своей работы программистов сделает команду эффективнее, то он просто дурак. На самом деле этот поступок, скорее попытка переложить ответственность с себя на команду. А для самой команды, это лишний гул в голове + кому-то может показаться, что их отчитывают. Чтобы управленец подумал, если бы программисты, кадждые пять минут пытались посвятить его в тонкости того, как те инструменты, которыми они пользуются, путаются всяческими багами и несовершенствами воткнуть им палки в колеса? Такой подход и есть начало конфликта.
Команда состоит из профессионалов и нуждается лишь в мотивации. А для этого нужно понимать самих программистов. Не программист не способен их понять. Или способен, если он талантливый психолог + очень долго с ними работает. А одно желание со стороны руководителей неминуемо приведет к созданию напряженности.maksim_ms
09.07.2018 19:08+1А програмисты знают куда лететь? Или главное процесс?
PO — это штурман, подсказывает ключевые точки маршрута раз в спринт.
А пилоты сами принимают все решения и ни кто им не говорит на каком самолете и как лететь.
Без Scrum — это когда к пиломат свободно ходят все пассажиры из салона и каждый говорит куда только ему хочется чтобы летел самолет.
Demetrikl Автор
08.07.2018 19:09Поэтому не понятно зачем программистам растолковывать основы scrum идеологии и тем самым попросту захламлять их рассудок. Если управленец считает, что посвятив в тонкости своей работы программистов сделает команду эффективнее, то он просто дурак.
Программист работая в компании, вынужден соблюдать правила, установленные в компании. И он может либо соблюдать эти правила как карго-культ, либо соблюдать их с пониманием того, зачем они введены (И если, например, он с ними не согласен, то может поднимать вопрос об изменении правил). Если мы говорим о scrum, то задача Scrum мастера объяснять и рассказывать участникам процесса, в том числе и программистам, об устройстве фреймворка. Это он делает из уважения к участникам процесса, ведь одна из ценностей scrum — это Transparency. И раскрывая, например, суть событий scrum для программистов, SM повышает прозрачность процессов. Если, например, SM навязывает (т.е. насильственно обучает) программистам знания об основах фасилитации, то это уже странно.
кому-то может показаться, что их отчитывают. Чтобы управленец подумал, если бы программисты, кадждые пять минут пытались посвятить его в тонкости того, как те инструменты, которыми они пользуются, путаются всяческими багами и несовершенствами воткнуть им палки в колеса? Такой подход и есть начало конфликта.
Похоже на личный негативный опыт. То что вы описываете — это конечно же неправильно. Собственно этот вопрос и хотелось поднять. Что часто могут быть поступки и решения, которые вызывают негатив, а идут из-за непонимания.Fengol
08.07.2018 19:46+1Какие ещё правила? scrum, это методология для тех уровней, которые не имеют отношения к разработке.
То есть, это уровень управления. Это доказывает даже тот факт, что повысить уровень продуктивности работы команды пытаются с помощью посвящения в идеологию scrum. Для программиста это и есть культ, о котором Вы говорите не реже, чем посылаете на конференции.
Программист, это ребенок, который живет в футуристическом мире созданным им самим на основе книг, игр и кино. Накой ему Ваш scrum? Ежедневно программисту нужно только комфортное рабочее место, столько еды, сколько ему нужно чтобы не возникло повода задуматься о голоде и интересные темы не относящиеся к рутине трудовых будней, с помощью которых можно развеяться. Только так можно поддерживать хрупкое чувство комфорта, отсутствие которого просто как бур в голове мешает сконцентрироваться на задаче.
Об этом нет ни слова, зато есть постоянные встречи и упоминание о правилах. Такое ощущение, что речь идет не о it компании, а о галере, на которой даже отхлыстать кнутом могут. К галере можно ещё отнести треш-компании, которые занимаются разработкой дешевых приложений и в которых очень важен именно тем, а о рабочих думают в последнюю очередь.
Все крутые it-лэйблы в самом начале ставили интересы своих сотрудников, чуть ли не выше всего. Им давали доли, проценты, возможность самореализации. Это мотивация. А все остальное это галера, где главное выжить как можно соков до того, как кто-то остынет.
И ещё раз — scrum это методология управления, что доказывает даже Ваши статьи, в которых упор сделан только на управление. Но it это прежде всего программисты. Вот у слесарей главный прораб, а у it — программисты. Если какая-либо методология это не понимает, то у нее нет будущего.funca
08.07.2018 22:06с точки зрения компании сотрудник должен быть управляем. scrum это фреймворк для управления. в случае программистов он зарекомендовал себя эффективным.
программист, приученный к scrum, это как ребенок приученный к горшку. в современных условиях это база.
«it это прежде всего программисты». это миф времен коммунизма (колхоз это колхозники, завод это рабочие и т.п.). при капитализме все не так. можете легко проверить, подняв в очередной раз вопрос о своей зарплате.
Demetrikl Автор
08.07.2018 23:23Какие ещё правила? scrum, это методология для тех уровней, которые не имеют отношения к разработке.
В первоисточнике немного не так: Scrum is a framework for developing, delivering, and sustaining complex products.
Возможно у нас терминологическая путаница. В моем понимании «разработка» — это общее понятие, по сути от идеи до появления продукта на рынке (т.е. включает в себя анализ, ui/ux, написание кода, тестирование, интеграцию и т.д.). И вот scrum как раз про организацию процесса этой самой разработки.
Это доказывает даже тот факт, что повысить уровень продуктивности работы команды пытаются с помощью посвящения в идеологию scrum.
Это действительно дико, если решают задачу «повысить уровень продуктивности команды» при помощи «посвящения в идеологию». Я уже несколько раз писал, что первое что нужно сделать — это понять для чего нужен scrum? Какая стоит перед ним задача? Это всегда очень индивидуально — нет серебряной пули. Часто scrum внедряют не там, или не для того. Вот отличная статья когда не надо. Например, scrum можно внедрять, чтобы повысить прозрачность: когда бизнес не понимает что там происходит в it департаменте, но очень хочет понять.
культ, о котором Вы говорите не реже, чем посылаете на конференции.
Классный и справедливый подкол! Да, действительно, я постоянно советую scrum master-у учиться. Это очень коррелирует с вашей мыслью, что программисты любят технологии и любят пробовать новое. Без этого ты можешь остаться за бортом профессии. Точно также scrum master должен постоянно учиться и развиваться. Возможно в этом есть одна из бед scrum, что еще нет культуры непрерывного обучения SM.
Программист, это ребенок, который живет в футуристическом мире созданным им самим на основе книг, игр и кино. Накой ему Ваш scrum? Ежедневно программисту нужно только комфортное рабочее место, столько еды, сколько ему нужно чтобы не возникло повода задуматься о голоде и интересные темы не относящиеся к рутине трудовых будней, с помощью которых можно развеяться. Только так можно поддерживать хрупкое чувство комфорта, отсутствие которого просто как бур в голове мешает сконцентрироваться на задаче.
Мне кажется, программисты все-таки сложнее. ИМХО так себе представляют программиста некоторые HR, поэтому часто в описаниях вакансий «печеньки в офисе» представляются как великое благо (на эту тему тоже есть статьи на хабре). Мне кажется, что программист, как и любой человек хочет заниматься чем то важным, делать мир лучше, приносить реальную пользу. Когда ты пишешь код по ТЗ из Jira, то нужна хорошая фантазия, чтобы ощущать силу влияния на мир своей работой. Часто получая ТЗ программист думает: «Ну что за ...? Люди, что вы делаете? Остановитесь!». Scrum помогает такому прекрасному порыву. В scrum программист и конечный пользователь очень сильно приближаются друг к другу (между ними лишь PO). Программист может понять, что хочет пользователь. Он может придумать, как это сделать. Сделать, отдать пользователю и получить обратную связь. И это очень ценно. Ты понимаешь что, для чего и для кого ты делаешь. И ты быстро понимаешь насколько хорошо ты это делаешь. В scrum программист может максимально раскрыться, ведь над ним нет менеджера, который говорит ему «что делать».
Об этом нет ни слова, зато есть постоянные встречи и упоминание о правилах. Такое ощущение, что речь идет не о it компании, а о галере, на которой даже отхлыстать кнутом могут.
Очень жаль, что у вас такое ощущение от прочтения, я хотел противоположного. Не могли бы вы подробнее раскрыть эту мысль с цитатами. Чтобы я мог провести работу над ошибками.
Все крутые it-лэйблы в самом начале ставили интересы своих сотрудников, чуть ли не выше всего. Им давали доли, проценты, возможность самореализации. Это мотивация. А все остальное это галера, где главное выжить как можно соков до того, как кто-то остынет.
Недавно на хабре появилась статья, где разбираются реалии нашего рынка. К сожалению, опционы пока больше приняты на западе. Хочется верить в улучшение ситуации. Но scrum немножко в другой плоскости от опционов.funca
09.07.2018 01:16Возможно у нас терминологическая путаница. В моем понимании «разработка» — это общее понятие, по сути от идеи до появления продукта на рынке (т.е. включает в себя анализ, ui/ux, написание кода, тестирование, интеграцию и т.д.). И вот scrum как раз про организацию процесса этой самой разработки.
Программисты чаще воспринимают разработку с точки зрения инженерных практик, технологий и операций, выстроенных в определенную последовательность (технологический процесс). Scrum абстрагирует все это до той степени, что снаружи остается видна лишь аккуратная очередь задач, управлять которой может кто угодно.
В обратную сторону такой трюк автоматом не работает. Максимум, что дает scrum при выстраивании технологического процесса это то, что в результате процесс будет иметь достаточно «ручек» для управления в таком стиле. Основная же часть работы — обычная инженерия и менеджмент. При этом маркетинг от scrum стремиться присваивать вообще все достижения себе. Думаю это одна из причин, почему его недолюбливают.ApeCoder
09.07.2018 10:19аккуратная очередь задач, управлять которой может кто угодно.
Вообще высяснение состава и очередности задач это по-моему весьма важно и тут легко ошибиться.
"XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work."
Demetrikl Автор
09.07.2018 11:04При этом маркетинг от scrum стремиться присваивать вообще все достижения себе. Думаю это одна из причин, почему его недолюбливают.
Вы можете поделиться своим опытом? Вы рассказываете жуткие вещи.
Вроде как при scrum на sprint review команда разработки встречается со стейкхолдерами, где они смотрят инкремент и дают обратную связь. Откуда у вас маркетинг? Как и чьи достижения они забирают?funca
09.07.2018 11:37вы хотите сказать, что идея встречаться со стейкхолдерами где они смотрят инкремент и дают обратную связь это чисто заслуга Scrum?
из своего опыта, мы регулярно встречаемся и у нас не scrum.ApeCoder
09.07.2018 11:48Demetrikl подумал, что идет речь про ваш собственный маркетинг.
Вы говорите про «Маркетинг SCRUM». Мне интересно, где вы слышали, чтобы они присваивали все заслуги себе? Вы можете подтвердить это цитатой? Они вроде ничего такого не говорят. Возможно, они не упоминают разные другие практики откуда что взяли и скомпоновали в свой фреймворк, но это вроде не делает никакой другой маркетинг.Demetrikl Автор
09.07.2018 11:58Demetrikl подумал, что идет речь про ваш собственный маркетинг.
ApeCoder несколько раз прочитал ваше сообщение. Но так и не понял вашего вопроса ко мне. Не могли бы вы перефразировать?
Вы говорите про «Маркетинг SCRUM». Мне интересно, где вы слышали, чтобы они присваивали все заслуги себе? Вы можете подтвердить это цитатой? Они вроде ничего такого не говорят. Возможно, они не упоминают разные другие практики откуда что взяли и скомпоновали в свой фреймворк, но это вроде не делает никакой другой маркетинг.
Вы говорите про «Маркетинг SCRUM».
Про маркетинг первый заговорил funca, я пытаюсь выяснить ситуацию где он сталкивался с таким коварным маркетингом, который:При этом маркетинг от scrum стремиться присваивать вообще все достижения себе.
Demetrikl Автор
09.07.2018 12:46ApeCoder Я посидел, подумал, понял.
Если funca действительно говорит о «продавцах Scrum, которые всю славу у команд забирают», то я подписываюсь под вопросами. Я не видел таких адептов scrum, которые бы говорили, что «если бы не scrum, то никуда бы ваша команда не побежала.» В agile: «Individuals and interactions over processes and tools»
Правда хочется увидеть пруфы того, что заслуги команд приписываются инструменту.
Demetrikl Автор
09.07.2018 11:53вы хотите сказать, что идея встречаться со стейкхолдерами где они смотрят инкремент и дают обратную связь это чисто заслуга Scrum?
Я хочу сказать обратное. Если в конце спринта команда не проводит sprint review и не получает от стейкхолдеров обратную связь, то это не скрам. И отсюда мой вопрос к вам: Как при таких условиях маркетинг может забирать чужие достижения?
Практика регулярно встречаться со стейкхоледрами прекрасна при любом подходе. Вы молодцы, что так делаете.
Fengol
08.07.2018 19:54Я не говорю что scrum, это ерунда. Это методология, которая реально поможет новичкам сразу встать на правильный путь, в вопросах управления разработкой. Но именно эта часть у Вас изобилует ну очень спорными утверждениями. Было бы круто увидеть ту статью, которую Вы не планировали, но которая была бы последний и исчерпывающе описывала то, что должны делать те или иные роли. Она была бы более полезна, чем эти, которые очень похожи на запугивание, с целью посещения конференций.
Demetrikl Автор
09.07.2018 00:03Что должны делать роли описывает scrum guide (официальный перевод)
Но часто непонятно «как» это делать. Мне кажется, что единого и подходящего всем «как» нет. Всегда есть разные особенности у организации и команды, плюс, что более важно, разные задачи ставят перед scrum.
Но вот ошибки на моей практике часто повторяются, поэтому я и стал писывать через эту призму.
ganqqwerty
09.07.2018 00:30Пункт про то, что SM не разделяет ценностей Agile достоин более подробного описания, в моей практике это была самая частая проблема.
Например, SM не понимает, что agile — это про то, чтобы почаще показывать то, что команда наваяла — тем, кто будет наваянным пользоваться. Или же он не понимает, что требования к продукту меняются и уточняются по ходу разработки продукта — и это нормально и ожидаемо.
funca
09.07.2018 01:27Scrum это фреймворк. Поэтому конкретные процессы свободно подгоняются под заданные условия. Он хоть и появился рядом с Agile, но вполне может использоваться и сам по себе, в отрыве от этих ценностей. Например, Scrum органично вписывается как практика для цикла разработки в DSDM, хотя «снаружи» там голимый водопад и ни каких пользователей даже близко не видно.
Demetrikl Автор
09.07.2018 10:40Scrum это фреймворк
Это правда, scrum можно просто использовать как тактический инструмент в разработки. И часто scrum без agile отлично решает поставленные перед ним задачи.
Просто мой тезис в том, что когда scrum и agile идут за руку, то такая команда может давать лучшие результаты.funca
09.07.2018 11:50как вы определяете критерии и возможный предел для этих улучшений?
Demetrikl Автор
11.07.2018 12:21Предела конечно же нет, мир изменчив, и желание адаптироваться под изменения открывает команде новые горизонты для улучшений.
как вы определяете критерии для улучшений?
Опять же нет чего-то универсального, критерии определяются задачей. Важно сравнивать команду саму с собой, следить за динамикой.
Критерием и метриками можно брать, например, TTM или размер тех.долга (который может посчитать в Sonar)
Но важно чтобы эти показатели:
- Были бизнес ориентированы, т.е. они были как разработке, так и бизнесу. Критерий — как коммуникационный мост для большего взаимопонимания.
- Имели чисто информационный характер. Нельзя завязывать мотивацию на такие показатели (Потому что правда будет скрываться от бизнеса, а команда будет работать на показатель в ущерб остальному. В проигрыше все.)
- Были прозрачными для всех, т.е. все понимали о чем речь, зачем это нужно и как данные собираются и анализируются.
Demetrikl Автор
09.07.2018 10:37Да это правда проблема. Но не знаю куда подробнее. Agile невозможно насильственно привить. Понимание появляется через обучение. Можно попытаться объяснить и научить. И очень легко в работе понять, разделяет человек эти ценности или нет (поступки нагляднее слов). По-моему мнению, нужно просто дать человеку выбор (Морфиус, Нео, все дела), но предварительно объяснив, что такое agile. Agile — это же не серебряная пуля, более того он не всегда полезен.
ganqqwerty
11.07.2018 11:38Надо бы как-нибудь прийти на конференцию по разработке ПО с докладом, где пятнадцать минут подряд талдычить им принцип Agile: «Show your shit to your users! Show your shit to your users! Show your shit to your users!»
maxxannik
часто в компаниях очень плохо понимают суть Scrum Master. и если хорошие PO и хорошие команды мне встречались, то вот внятных и хороших Scrum-мастеров в живую еще не видел.
можно ли сказать следующее?
— PO — ратует за результаты, за продукт, за доходы и прибыль (руководитель производственник в понятии Ицхака Адизеса)
— SM — ратует за процесс, за культуру, взаимопонимание, за комфортную атмосферу (руководитель интегратор в понятии Ицхака Адизеса)
Demetrikl Автор
Звучит грустно, но легко в это верится.
Что касается Адизеса, то к сожалению его книги не читал (но записал в то что стоит прочесть). Но ваше описание очень похоже на роли заложенные в scrum guide.
funca
часто в компаниях SM как трактуется scrum manager — лицо, которое по иерархии выше команды и наделено полномочиями давать прямые распоряжения.
Demetrikl Автор
К сожалению, такое встречается. Хотя в scrum guide очень хорошо сказано:
Busla
методист
funca
а потом чиновник — слуга народа.