Comments 49
Очень жаль, что у вас сложилось такое впечатление о скрам-мастерах и надеюсь, на вашем пути когда-нибудь встретится достойный скрам-мастер:))
100% )) Хорошо, когда эти "мастера" и "подмастерья " не сильно мешают реальной работе. Но когда этот коммуникационный обвес желает продемонстрировать свою мнимую полезность - всё начинает реально буксовать
Ага. А потом ты тратить день, чтоб передвинуть задачку из статуса "в разработке" В статус "сделано", а оказывается, что задачки критичного уровня непривязанные к сторе релизного эпика, может двигать только автор эпика по чётным четвергам релизного цикла, если он овен. А там ещё в конце 4 статуса " Завершено", "сделано", " Закончено", "закрыто". И ты долго думаешь, завершил ты её или сделал, а потом звони скрам мастер и говорит, и ругается что баги закрываются, стори заканчиваются,а в статус сделано разработчик передвигать не имеет права, только течтировщик, а завершено передвигает бизнес-оунер и всём жто понятно, а ты единственный идиот не допер.
Это очень смешно, честно:))
просто, к сожалению, суровый российский энтерпрайз превратил скрам-мастеров в секретарей jira, а ведь это совсем не так) мы в своем центре за ролевую модель берем Теда Лассо и на разных уровнях зрелости команд применяем разные техники и инструменты.
На вводной встрече с командой моей первой фразой было: "Мы с вами вместе постараемся создать комфортную среду для работы", что тогда не очень понравилось, как мне кажется, руководству, но что в итоге сыграло всем на руку. Главное, не забывать о здравом смысле везде.
Два абзаца и нифига не понятно! На байта полезной информации! Божечки! Это шедевр канцелярщины! Жгите ещё!
Я думаю, что вы согласитесь, что правила нужны. Другой вопрос в том, что их количество должно быть минимальным. Ваш пример про 4 статуса - классический, только вот задача хорошего скрам мастера не звонить/ругаться (это один из антипаттернов его работы), а помочь с устранением препятствий, мешающих эффективной работе команды. В вашем случае - разобраться, зачем нужны эти 4 статуса и помочь с упрощением workflow.
Проблема в том, что большинство скрам-зависимых пришли в этот мир не из разработчиков или тестеров. Зачастую у них и образования технического нет. У моей упомянутой ранее CMMI-инженершы было образование учителя английского языка. Так вот люди, ни дня не проработавшие в реальном IT, могут стать лишь жрецами культа, в который, собственно, скрам быстро и превращается при таком подходе. Общение начинается на языке, близком к старославянскому и латыни: одна лишь "фасилитация" чего стоит (я ее поначалу прочитал как "фалиситация", очень удивился). И да, скрам-тарарамы начинают жизнь разработчиков фасилицировать, а не упрощать, тем же остается лишь обреченно вздохнуть.
"Причем доступ к задачам есть у любого сотрудника департамента, каждый может посмотреть прогресс", но никто не смотрел, потому что это никому не вперлось, потому что ничерта непонятно, итак затрахали своими совещаниям по "метамоделям архитектурного цикла". Когда ж я уже стану старый буду ходить по тупым совещаниям кивать и улыбаться и нести ерунду и зарабатывать много денег.
Автор, пишите ещё! Каждый абзац - это шедевр дикой бюрократизации и эффективного менеджмента.
Дорогой комментатор, спасибо) непременно еще напишу:)
Может можно познакомиться с эффективным процессом работы, который выстроили вы в очень успешной команде? Было бы очень полезно почитать)
Скрам мастер рассказывает о том нужен ли Скрам мастер... похоже на job security. Надо просить минимум коллег, чтобы они написали нужен ли им Скрам мастер, а в идеале команды, которые обходятся без них в принципе ;)
"Жандарм – это порядок, а порядок никто не любит". В разных компаниях реальные функции и полномочия скрам-мастера сильно разнятся, поэтому без знания местных особенностей обсуждение нужен/не нужен это холивар. Кроме того, как у любых руководителей, многое определяется сугубо личными качествами и опытом.
Ну если повышение надежности продукта или уход с нецелевых технологий - это дичь, то да.
Если у команды есть реальных 25% времени чтобы внедрить хорошую технологию «с понятной ценностью» то никто не будет бодаться, а с радостью за это возьмутся.
Здесь как с уборкой - в теории всем нравится когда удобно и красиво как в пятизвёздочном отеле, но в реальности менять своих привычки бросать носки куда попало и разгребать авгиевы конюшни за другими ни кто не стремится.
У меня по опыту внедрение новых технологий и полезных инженерных практик, по большому счету это всегда боль. Причем менеджмент с их сроками и бюджетами здесь полбеды. Много отрицания идёт от самих же инженеров - людям удобнее и кажется безопаснее работать так, как они привыкли.
Для того, чтобы изменить что-то технически, сперва приходится менять самих людей: либо учить и воспитывать пока новые подходы не войдут в привычку, либо в прямом смысле. Банальный пример - кодстайл. На одном из проектов внедрение заняло больше года, т.к. взрослые дядьки на серьезных щщах ни как не могли договориться относительно отступов: табы или пробелы.
Мне бы тоже хотелось видеть конкретные примеры, чем они занимаются. Хотя фокус статьи на другом, поэтому не вижу смысла критиковать автора, она рассказала про свой кусочек работы.
полезные изменения многим были интересны, некоторым безразлично, но чтобы противиться — то только на задачи типа "дичь".
"Дичь" это субъективная оценка. Во многом она зависит от прошлого опыта и текущих скиллов. Люди совершенно разные. Кто-то понимает и готов с радостью подхватывать изменения, другие наоборот - не понимают, или не видят для себя лично пользы, или видят угрозу и тормозят. Со всем этим приходится работать.
Если брать конкретные примеры, то это задачи, связанные с переходом на целевые экосистемные платформы, переходом на cloud native архитектуру, повышением скорости поставки, обеспечением надежности и т.п.. При этом во главе угла ставятся текущие показатели конкретного продукта (в том числе его технологическая зрелость) и каждый продукт сам принимает решение, какие из задач запланировать на ближайщий квартал. Что касается КПЭ, то в них учитываются не только бизнес, но и ИТ составляющая.
Про порядок это обобщение, мне нравится порядок и я не скрам мастер :). Зависит от команды в целом.
В разных компаниях реальные функции и полномочия скрам-мастера сильно разнятся, поэтому без знания местных особенностей обсуждение нужен/не нужен это холивар
Есть правда в Ваших словах
Порядок - это здорово. Но включать в проектную работу очередного административного паразита вредителя - не решение. Вы безусловно правы: руководитель решает. Может кому-то и хочется иметь своего карманного ИБД-мастера, чтобы рисовал релаксирующие метрики. Цена вопроса
Мы этого конкретного обсуждаем. Она свои обязанности описала.
Про порядок я сам двумя руками. Но опять же, для меня порядок это системность. А у ней про системность речи не идёт вообще. Дашборжов накрутила, совещаний насобирала, чо сделала непонятно.
Тем более, что ком зависимостей и проблем во взаимодействии копился все это время во всем департаменте. Очень много работы зависело от смежных центров/платформ/отделов
Надо было просто провести тренинг по эскалации и разруливанию конфликтов
Итак, встреча проходила ровно 1 день в офлайн формате. Собрать всех в одном месте стало тем еще приключением. Мы долго прорабатывали адженду, обсуждали, как настроить эффективную работу в группах, артефакты и образ конечного результата. Встреча была проведена, многие зависимости были проговорены вообще впервые. Но уже к обеду опрос показал, что очень многие смогли договориться
А еще было потрачено куча денег компании, потому что наличие большого количества человек на митинге в большинстве случаев не слишком то эффективная штука. Почитайте "Death by Meeting: A Leadership Fable"
Сегодня, как мне кажется, мы стали более продуктивными и адаптивными к изменениям, более открытыми для общения и сотрудничества в команде, непрерывно улучшаем наши метрики, процессы и инструменты
Какие были метрики ДО прихода скрам мастера, "как мне кажется" это такой себе показатель эффективности. Возможно до Вашего прихода всё было лучше, хоть и менее организовано.
Если про производственные метрики, то lead time снизился более чем в в 2 раза. План/факт увеличился с 30% до 80%.
Об улучшении метрик упоминается в блоге)
Синтетические показатели(
у меня тоже по лидтайму метрики есть, доп геморрой, вместо того чтоб сформулированную задачку положить в бэклог, её держат в текстом файлике и кладут прям перед реализацией, или в процессе. Ну и толку?
План/факт достигается снижением плана(
Вы на людей надавили, они стали часть времени тратить на подтасовку метрик, а толку?
Тупой вопрос: а по аджайлу можно давить на людей, требуя выполнения плана? Или по скраму хз в чем разница
Я вот не пойму, у вас какая-то личная обида на скрам-мастеров?
Вы со мной никогда не работали, вы не видели, как работает моя команда. У нас с ребятами очень доверительные дружеские отношения и после всех тех циклов налаживания инструментов и процессов, я еще ни разу не слышала негатива в сторону agile практик от команды, даже наоборот ребята постоянно сами просят помощи, например, в фасилитации, медиации конфликтов. Более того, есть центры, которые увидев то, что мы делаем приходят и сами просят скрам-мастеров «включиться» в их работу.
Если для вас так невыносимо существование скрам-мастеров, может каждый останется при своем мнении?
В моем опыте было два диаметрально противоположных подхода у скрам-мастеров.
С одним из них мы этих дашбордов и метрик в глаза не видели - хотя они были(их обсуждали пару раз на встречах с ПМ, необязательных для разрабов). Работа работалась, спринты закрывались с 90% выполненных задач, код фриз и релизы за редким исключением в срок.
Другой мастер: куча непонятных затянутых совещаний, разные дашборды и метрики. Итог: постоянные переносы релизов и неоттестированный код в проде. Постоянные попытки "усилить команду" не показывали никаких значимых результатов. Зато этот мастер обладал очень хорошо подвешенным языком и все озвучиваемые на ретро проблемы закидывал позитивным словесным мусором. Внешне все было очень дружелюбно, но большая часть команды со временем просто перестала озвучивать реально существующие проблемы, потому что бесполезно.
Я понимаю, что вы, возможно, хороший скрам-мастер. Но, может быть, на самом деле вам просто перестали озвучивать проблемы?
Я же могу делать вывод о вас на основе ваших статей?
Ну если, вы напишите, что поддерживаете расизм например, а я напишу, что вы отвратительны, это будет справедливо?
В ответ, я слышу: "просто поверьте у меня всё хорошо, давайте каждый останется при своём мнении")
В этом отличие науки от веры, и технологий от религии. Ведете себя, как старая бабушка перед пионером, который ей эбонитов палочку показывает: " Какое ещё электричество - гроза это кара божья". Вместо того, чтоб понять, что вам говорят, замыкаетесь в своей религии.
Большое количество участников действительно в большинстве своем не эффективно, если не использовать техники фасилитации встреч. В примере, который описан выше, в рамках этого дня участники основную часть времени работали в мини-группах до 10 человек, разбирая зависимости друг от друга. Хорошим показателем успешности встречи можно назвать значение ROTI (Return of Time Investment), который сами участники оценили более, чем в 3,5/5, где 3 - результаты полностью соответствовали ожиданием, затраченное время = полученная польза.
Идея собраться всем оффлайн и договориться - это на определенном масштабе организации прям правильная вещь. Без этого жизнь боль. Но да, это надо готовить и продумывать, а не просто загнать всех в одну комнату.
Скрам мастер конечно нужен. Вдруг штаты сокращать придется. Будет кого уволить чтобы отдел не пострадал.
Помню, как пришел к нашей QA-инженеру (дело давно было, тогда мы притворялись, что работаем по CMMI level 5) и спросил, что именно за метрики она от меня хочет (какие-то строчки кода посчитать). По тому, как было сформулировано, было неясно, и возникли разные интерпретации. Чтобы лучше понять их потребности, я стал допытываться, что именно они с нашими метриками потом делают. Ответ убил. "Не знаю, я просто в Excel таблицу эти метрики записываю" -- было мне ответом.
бюрократия до добра не доводит, как бы ее не называли.
Вот вроде бы я тоже разработчик, должен все понимать... Но как будто про параллельный мир написано, вообще даже представить не могу что там у вас за центры практик и принятия решений. Похоже на рыбный текст
Наверное поэтому разработчики не любят вас, скрам-мастеров, потому что не понятно что за херню вы делаете, но с ужасно умным видом, клевыми словечками и огромными зарплатами
Над уровнем архитектуры приложений находится архитектура систем. Но если вы хотите, чтобы системы в вашей организации строились по каким-то общим принципам, то получается нужна архитектура архитектур, модели моделей (метамодели) и все вот это. Довольно абстрактная деятельность, которая находится на три уровня абстракции выше конечной разработки, однако может иметь там самые серьезные последствия - как в плане побед, так и ошибок. Результаты такой деятельности в разработку падают в виде спецификаций, бест практик, запросов на изменения и т.п. Часто проблемы возникают из-за того, что архитекторы коммуницируют это в виде экшен айтемов - что нужно сделать, пропуская предпосылки - для чего. В итоге разработка действительно не понимает для чего все это нужно и потом всячески сопротивляется.
Я немного слукавил в своем комментарии. На самом деле я понимаю о чем написано. Тема то здравая, идет обсуждение как управлять огромной системой!
На самом деле то, что описано в статье - зубодробительно просто. Причесать джиру, немного всех организовать. Но это все завернуто в "архитектуру архитектур" и "три слоя абстрактности". Все эти мысли - на поверхности, до них дойдет любой не дебил. Это поверхностный слой и это никого не интересует.
Расскажите в чем жыр. Почему ваша методология сработала? Почему тесное оффлайн общение решило кучу проблем? Какие сложности внедрения? Как вы работали с людьми? Какие метрики? Чего стала добиваться компания, чего раньше не могла? Начальник был на моей стороне и пропушил все в команды, где тут вызов?
Просто когда смысла особо нет, но хочется сделать посерьезнее, приходится заворачивать в умные слова и фразы. От этого смысл ускользает совсем и статья становится рыбной и не понятно
Полностью с вами согласен - зачастую архитекторы спускают в продукты/команды задачи, без объяснения их глобального смысла. На мой взгляд, задача скрам мастера в команде архитекторов (о чем идет речь в статье) стоит в том числе в том, чтобы помочь им сформулировать задачи не в конкретных action items, а наполнить их продуктовым смыслом, чтобы команды их могли "купить".
Всем привет!
Меня всегда очень радуют технические специалисты, болеющие за вольнодумие (это о творчестве и свободе в принятии решений), анархизм и махновщину, а потом сильно удивляющиеся, почему компания начала сокращения, урезает зарплату, вводит отрицательные KPI (а ещё почему кто-то работает 8 часов, а кто-то 12). Очень часто именно из-за такого бардака. Непонятно ни кто и чем занимается, ни какой результат на выходе (на языке коммерции: где деньги, Лебовски?), ни, в конечном счёте, зачем нам все эти сильно умные и опытные люди (если инкремента либо нет, либо он сильно непредсказуемый при вполне реальных и предсказуемых контрактах).
В больших компаниях (не стартап на идее и смузи) бюрократия - это всегда неизбежное зло, но зло, при грамотном и прагматичном подходе (если подход неграмотный и не особо прагматичный, то в шею гнать такого горе-управленца) приносящее большие бенефиты на уровне стратегических целей. А что такое стратегические цели на горизонте 5-10 лет? Это зарплата, грейды, ДМСы, сертификаты и прочие плюшки по всей вертикали от CEO до уборщицы (специалист по клинингу, если кому-то оскорбительно). Это сложно, не хочется, отнимает лишнее время, заставляя отвлекаться от кода, паяльника, кружки чая? ДА! Но если работа с бюрократией отнимает у технического специалиста условные 30 минут в день, и при этом даёт хорошее визибилити и прогнозирование для Менеджмента, то это хорошая сделка. Иначе чёрт его знает, то ли корабль движется к рифу, то ли мы всё ещё стоим у пристани.
Поэтому клёво видеть в комментариях концентрат негативного опыта, но это скорее привет не автору, а местному Менеджменту коллег. ;)
По статье, интересный подход. Многие вещи воспринимаются слабо по причине особенностей конкретной организации, но если смотреть хай левел (а статья именно хай левел), то определённые части концепта я бы с удовольствием пощупал. Находясь в своей компании на позиции руководителя PMO / боевого PMа, очень часто наблюдаю жесточайший провал в коммуникации (это про зависимости) между подразделениями. Пытаемся решать на стратегическом уровне, но чаще всё сводится к локальным оральным интервенциям и беготнёй PMов. И работает! То есть, на уровне исполнителей гэпов больших нет, все болеют за общее дело.
Соответственно, очень хотелось бы попросить автора немного поподробнее рассказать про Этап 2 Взаимодействие снаружи. Интересуют принципы построения встреч, подходы к эффективной фасилитации и координации табуна разъярённых и очень занятых уважаемых людей, как добиваетесь выполнения договорённостей и т.д. Сильно хочется навести суету и организовать что-то похожее, чтобы PMы сидели и разгребали препятствия для своих команд, а не тушили локальные пожары. :)
Напоследок, всем добра и больше понимания к друг другу.
в одной компании в рамках проекта с ПФР сработал следующий подход:
С уважаемым и занятыми людьми общались через согласование процессов (сквозной бизнес процесс с набором спорных вопросов. Потом была бронь от генераторов идей)))
Техническая реализация и подход к ней были на Enterprise Архитекторе (который прям про систему и вовремя раздавал "помощь" при нарушении подхода. У архитектора были полномочиями)
Для более качественно контакта с уважаемыми людьми, брали аналитику у технической поддержки (тут повезло, прям компетентные люди)
Но сложность в кейсе падает, так как уважаемые люди были достпуны и шли на контакт, при должной подготовке
Как только у нас пошел хайп на аджайл, роль скрам-мастера на кого только не навешивали, со всеми вытекающими.
Сегодня, спустя ~10-15 лет, это уже достаточно зрелая должность с вполне понятным профитом для команды. В последних трех проектах/командах(я в роли бизнес-аналитика) мне или везло, но скрам-мастер ощутимо помогал в эффективность команды.
Накоротке, например, пару спринтов - значительно эффективнее фигачить без дополнительных обременений. Вдолгую же, например, проект на пару лет, уже совсем другой подход.
Сейчас я бы рекомендовал попробовать такую схему:
берем качественного скрам-мастера, погружаем в проект/процессы/продукт/команду;
выходим с ним на некоторое стабильное плато в процессах(думаю 4-6 спринтов достаточно);
дербаним активности скрам-мастера на коллег в команде;
"живем" самодостаточной командой;
приглашаем скрам-мастера на аудит(например, на один спринт) раз в ~год.
Значительно веселее, когда надо масштабировать пул аджайл-команд. Не смотря на наличие готовых фреймворков, мне кжается тут всё не сильно радужно.
Нужен ли в архитектуре скрам-мастер: история одной команды