Комментарии 35
Пока что не удалось увидеть примеров успешного внедрения скрама. Если члены команды изначально не разделяют ценностей аджайла и не видят преимуществ использования скрам -практик, то все это превращается в двигание кроватей в борделе =(
И вот честно не знаю что делать в таких ситуациях и надо ли вообще что то делать.
И вот честно не знаю что делать в таких ситуациях и надо ли вообще что то делать.
Изначально нужно исходить из проблематики: для чего внедряется scrum? И уже из ответа рассуждать об эффективности внедрения. Я тоже никогда не видел кристально чистого Scrum. Но Scrum, решающий поставленные перед ним задачи, встречается довольно часто. Дальше вопрос риторики — как называть получившийся процесс.
Что касается изначального скептицизма команды, то это абсолютно нормально. Люди не любят перемен. И чтобы они с ними смирились или даже захотели, нужно показывать в чем собственно преимущества. Это и есть работа Scrum Master-а. Дело это не простое, но увлекательное (я об этом в следующих частях буду писать). Вспоминаем теорию скрама и строим эмпирический процесс демонстрации сильных сторон SCRUM для скептически настроенной команды.
Что касается изначального скептицизма команды, то это абсолютно нормально. Люди не любят перемен. И чтобы они с ними смирились или даже захотели, нужно показывать в чем собственно преимущества. Это и есть работа Scrum Master-а. Дело это не простое, но увлекательное (я об этом в следующих частях буду писать). Вспоминаем теорию скрама и строим эмпирический процесс демонстрации сильных сторон SCRUM для скептически настроенной команды.
Ну вот и получается, что или в команде есть общий взгляд на проблемы и тогда не надо ничего «внедрять» все делается естественно и само собой.
Или такого взгляда нет и тогда это выглядит как «ок, вам нужны спринты? вот вам спринты! Вам нужны дейлики? вот вам дейлики!» и все это делается исключительно механически и для галочки. Этакий карго-скрам. И как побороть именно вот такой подход я пока не знаю. По моему оно не лечится. Проще или уволить людей или отказаться от попыток наладить какие то процессы.
Или такого взгляда нет и тогда это выглядит как «ок, вам нужны спринты? вот вам спринты! Вам нужны дейлики? вот вам дейлики!» и все это делается исключительно механически и для галочки. Этакий карго-скрам. И как побороть именно вот такой подход я пока не знаю. По моему оно не лечится. Проще или уволить людей или отказаться от попыток наладить какие то процессы.
Ну собственно я и хочу попытаться помочь в такой ситуации этой серией статей. Вторую часть про команду, готовим к публикации. И следом пойдет про Scrum Master-а
На самом деле очень сложно объяснить, что такое команда. Я работал в крутой компании, где был очень крутой скрам
Теперь на новом месте люди вообще понятия не имеют что это такое, никто не видел вживую и никто не верит в это. Я даже не могу объяснить что такое «доверие» в команде. Сразу заваливают вопросами — «А что, если Вася Пупкин будет тормозить, почему я должен страдать?»
Теперь на новом месте люди вообще понятия не имеют что это такое, никто не видел вживую и никто не верит в это. Я даже не могу объяснить что такое «доверие» в команде. Сразу заваливают вопросами — «А что, если Вася Пупкин будет тормозить, почему я должен страдать?»
Scrum guide учит нас, что сила в эмпирическом процессе (прозрачность, инспекция, адаптация.). Чтобы «объяснить» про доверие, проводите эксперимент: отмените индивидуальную оценку сотрудников снаружи команды; введите командную оценку и ответственность; дайте команде общую цель и помогите им сфокусироваться на ней. Задайте условия эксперимента — срок, критерии оценки и т.д. — это прозрачность. Проводите ежедневную синхронизацию членов команды и проведите ретроспективу по завершению эксперимента — инспекция. В случаи препятствий ищите варианты выхода — адаптация.
Главное человеку (по-идее это scrum master), который будет проводить этот эксперимент, заранее подготовиться к нему: понять для чего он это делает? куда он хочет привести команду? чему хочет её научить? Поставив цель, надо разработать план, а дальше действовать.
Главное человеку (по-идее это scrum master), который будет проводить этот эксперимент, заранее подготовиться к нему: понять для чего он это делает? куда он хочет привести команду? чему хочет её научить? Поставив цель, надо разработать план, а дальше действовать.
Кстати, ещё один большой вопрос — какова роль классического Тим Лида в скраме?
Я так понял, его вообще нет, потому что решения принимаются коллективно и все равнозначны
В классическом waterfall есть тимлид, который каждому говорит как и что делать
В итоге, если такой тим лид будет в скрам команде, то для конечного разработчика это ничем от waterfall-а не отличается
Я так понял, его вообще нет, потому что решения принимаются коллективно и все равнозначны
В классическом waterfall есть тимлид, который каждому говорит как и что делать
В итоге, если такой тим лид будет в скрам команде, то для конечного разработчика это ничем от waterfall-а не отличается
О про тимлида — это очень большой вопрос. На прошедшем весной Codefest в Новосибирске был отдельный поток про это. У Жени bunopus был классный доклад про ТимЛидство — 2018.codefest.ru/lecture/1316 очень советую посмотреть.
Так же мы устраивали дисскусию на эту тему — 2018.codefest.ru/lecture/1337
Так же мы устраивали дисскусию на эту тему — 2018.codefest.ru/lecture/1337
В базовой комплектации в скраме нет такой роли
Но никто не запрещает его назначить =)
Но никто не запрещает его назначить =)
Ну я вот эту часть читаю про ПО, типа
«PO почти не коммуницирует с командой. Например, он доступен только в рамках обязательных встреч (планирование, sprint review)»
было такое да. Вот не хочет ПО общаться с командой. Не интересно ему что она делает. И стори расписывать не хочет ( ну то есть вообще, у стори есть только название и TBD в дескрипшне). У него лапки. Потом на демо правда удивляется и говорит «я это не так себе представлял». А в день релиза он уходит в отпуск и вырубает телефон и все мессенджеры.
Говоришь об этом начальству «ну да, вот такой вот он у нас человек» зато «мы успешно внедрили скрам во всех командах».
Ну можно конечно заставить его ходить на ретро, но как сделать его реально заинтересованным в продукте? я не знаю. И для себя ответа в статье не нашел, извините =(
Но конечно подожду что вы дальше напишите, может что полезное и будет.
«PO почти не коммуницирует с командой. Например, он доступен только в рамках обязательных встреч (планирование, sprint review)»
было такое да. Вот не хочет ПО общаться с командой. Не интересно ему что она делает. И стори расписывать не хочет ( ну то есть вообще, у стори есть только название и TBD в дескрипшне). У него лапки. Потом на демо правда удивляется и говорит «я это не так себе представлял». А в день релиза он уходит в отпуск и вырубает телефон и все мессенджеры.
Говоришь об этом начальству «ну да, вот такой вот он у нас человек» зато «мы успешно внедрили скрам во всех командах».
Ну можно конечно заставить его ходить на ретро, но как сделать его реально заинтересованным в продукте? я не знаю. И для себя ответа в статье не нашел, извините =(
Но конечно подожду что вы дальше напишите, может что полезное и будет.
Отличный кейс! Странно, что PO надо заинтересовывать в продукте. Если продукт не нужен PO, то кому он вообще тогда нужен?
Из описания очень похоже, что ваш PO — это «прокси». И возможно есть настоящий PO — заинтересованный в продукте, который реально принимает решения: что делать и в какой последовательности. Возможно это сверх-занятой человек и у него просто нет времени заниматься бэклогом, тогда он может создать небольшую команду (discovery team — куда например могут входить аналитики и ui/ux специалисты), которая бы помогала ему в этом. Но важно донести до него, что наличие «прокси» с одной стороны искажает информацию в оба направления, с другой стороны коммуникации становятся дольше.
Соберитесь командой и сформулируйте свои ожидания от взаимодействия с PO. Затем позовите реального PO и озвучьте ему ваше ожидания. Совместно выработайте схему работы, где и PO не дергают неожиданно для него и команда получает нужную ей информацию.
А в день релиза он уходит в отпуск и вырубает телефон и все мессенджеры.Ну это просто не профессионализм независимо от позиции в компании. Детский сад. Зачем такой человек компании в принципе? Какие задачи он решает?
зато «мы успешно внедрили скрам во всех командах».Если есть доступ к руководству, задайте прямой вопрос: «а для чего? Зачем мы внедрили Scrum?»
Из описания очень похоже, что ваш PO — это «прокси». И возможно есть настоящий PO — заинтересованный в продукте, который реально принимает решения: что делать и в какой последовательности. Возможно это сверх-занятой человек и у него просто нет времени заниматься бэклогом, тогда он может создать небольшую команду (discovery team — куда например могут входить аналитики и ui/ux специалисты), которая бы помогала ему в этом. Но важно донести до него, что наличие «прокси» с одной стороны искажает информацию в оба направления, с другой стороны коммуникации становятся дольше.
Соберитесь командой и сформулируйте свои ожидания от взаимодействия с PO. Затем позовите реального PO и озвучьте ему ваше ожидания. Совместно выработайте схему работы, где и PO не дергают неожиданно для него и команда получает нужную ей информацию.
Странно, что PO надо заинтересовывать в продукте.
«раз у нас теперь скрам, то теперь ты будешь зваться ПО»
Если есть доступ к руководству, задайте прямой вопрос: «а для чего? Зачем мы внедрили Scrum?»
Уже задавал неоднократно =), реально у людей непонимание что и зачем они делают и это не на одном проекте или в одной команде.
Но если подытожить, мне кажется аджайл невозможно насадить, он должен быть в сердце. Попытки делать скрам в отсутствии «команды мотивированных профессионалов нацеленных на качество продукта» приводит лишь к страданиям для всех. Типа если у вас нет такой команды, то дальше статьи вроде вашей можно не читать не потому что они плохие, а потому что смысла не будет все равно. Сугубо имхо конечно, но пока мой опыт такой. Но буду ждать что вы напишите дальше =)
В целом вы правы, если нет понимания для чего внедрять Scrum и какие стоят перед ним задачи, то ничего хорошего из этого не выйдет. Чудо само по себе не случится. Карго-Scrum действительно дает больше боли, чем пользы.
Но важно понимать, что команда / кадры тут скорее всего не при чем (человеческая природа — искать состояние покоя). Нужны Агенты Изменений, который понимают, что они хотят сделать и зачем. Организация и её культура должны быть готовы к agile и тогда всё получится: можно построить из группы людей — «команду мотивированных профессионалов нацеленных на качество продукта». Но для этого нужно честно ответить себе на вопросы: «Для чего мы это делаем? Готовы ли мы меняться?».
Запустить Scrum сама по себе задача непростая, а делать это в партизанских условиях — это просто героизм. ИМХО сперва нужно, чтобы «наверху» осознали и приняли, а дальше уже народ потянется.
Ну и конечно «насадить» нельзя, но научить можно.
Но важно понимать, что команда / кадры тут скорее всего не при чем (человеческая природа — искать состояние покоя). Нужны Агенты Изменений, который понимают, что они хотят сделать и зачем. Организация и её культура должны быть готовы к agile и тогда всё получится: можно построить из группы людей — «команду мотивированных профессионалов нацеленных на качество продукта». Но для этого нужно честно ответить себе на вопросы: «Для чего мы это делаем? Готовы ли мы меняться?».
Запустить Scrum сама по себе задача непростая, а делать это в партизанских условиях — это просто героизм. ИМХО сперва нужно, чтобы «наверху» осознали и приняли, а дальше уже народ потянется.
Ну и конечно «насадить» нельзя, но научить можно.
А в день релиза он уходит в отпуск и вырубает телефон и все мессенджеры.
Ну это просто не профессионализм независимо от позиции в компании. Детский сад. Зачем такой человек компании в принципе? Какие задачи он решает?
Непонятно. Почему вы отказываете профессионалу в отдыхе? Все эти скрамы с аджайлами — это не цель всей жизни, и не новая форма крепостничества.
очень понравилось
жду продолжения
жду продолжения
Готова вторая часть — habr.com/company/wrike/blog/415563
Часть 3 — habr.com/company/wrike/blog/416189
Отличная статья!
Особый восторг вызвало наличие методических рекомендаций по применению поданного материала в заключении. Спасибо.
Извините за уход немного в сторону.
Два года пользуюсь на работе вашим сервисом, читаю этот блог… и всё никак не могу понять, как все эти высокие слова сочетаются с тем, что ваша браузерная версия (для десктопов) открыто построена с тяжёлыми неудобствами для клиента?
Открываешь тикет, в заголовке страницы — заголовок тикета. OK. При перезагрузке страницы (например, при рестарте браузера) там почему-то написано Inbox. При этом в странице остаётся тот же тикет.
Открыл несколько тикетов из, например, почты? Перезагрузил — вижу 4 страницы «Inbox».
Разумеется, кнопка Inbox при этом не работает: вы решили её отключить. Рядом есть всякие My Work, Dashboards, и так далее. Но они не ссылки, они только скриптовые реакции. Я хочу открыть My Work в соседней вкладке, почему я не могу это сделать? Вы не умеете делать элемент, что работает и как ссылка (например, по правой кнопке даёт open in new tab) и как реакция? Почему это работает в некоторых других местах?
Знак «три горизонтальные полоски» у всех нормальных людей уже давно означает меню действий/опций (см. тот же Firefox). У вас он почему-то вызывает удаление или появление подокна иерархии задач. Нельзя было сделать "" / ""?
Список по My Work. Задачи в списке есть, реакция на нажатие есть, ссылка запрещена, открыть в новом табе не могу. Приходится нажимать, чтобы оно открылось в правой части (операция не быстрая даже при идеальных каналах, ваши сервера обычно пригружены), вызывать постоянную ссылку на задачу и открывать уже её в новом табе. Иногда есть при этом «open as separate tab» в меню страницы (три точки в правом верхнем углу — а почему горизонтальные? стандарт де факто — вертикальная линия точек или три горизонтальные полоски, размещённые вертикально), иногда нет (почему так — выяснить невозможно, это логика серверной стороны).
Это, наверно, меньше половины проблем — не записывал. В сочетании с постоянным торможением за счёт зверски перегруженных скриптами страниц и выкачиванием этого всего с удалённых серверов — все подобные вроде бы мелочи становятся критичными и через несколько минут хочется убивать авторов.
Вероятно, вы вложили 100% в оптимизацию для телефонов/планшетов, а браузерная версия делается в лучшем случае по остаточному принципу?
Вне UI: Невозможно получать почтовые оповещения о собственных действиях в задачах: таких пунктов в настройках просто нет. О том, что бывает важно иметь _полную_ историю в почте, вы не думаете.
(Ну да, плачу́ не я, поэтому всем пофиг.)
Два года пользуюсь на работе вашим сервисом, читаю этот блог… и всё никак не могу понять, как все эти высокие слова сочетаются с тем, что ваша браузерная версия (для десктопов) открыто построена с тяжёлыми неудобствами для клиента?
Открываешь тикет, в заголовке страницы — заголовок тикета. OK. При перезагрузке страницы (например, при рестарте браузера) там почему-то написано Inbox. При этом в странице остаётся тот же тикет.
Открыл несколько тикетов из, например, почты? Перезагрузил — вижу 4 страницы «Inbox».
Разумеется, кнопка Inbox при этом не работает: вы решили её отключить. Рядом есть всякие My Work, Dashboards, и так далее. Но они не ссылки, они только скриптовые реакции. Я хочу открыть My Work в соседней вкладке, почему я не могу это сделать? Вы не умеете делать элемент, что работает и как ссылка (например, по правой кнопке даёт open in new tab) и как реакция? Почему это работает в некоторых других местах?
Знак «три горизонтальные полоски» у всех нормальных людей уже давно означает меню действий/опций (см. тот же Firefox). У вас он почему-то вызывает удаление или появление подокна иерархии задач. Нельзя было сделать "" / ""?
Список по My Work. Задачи в списке есть, реакция на нажатие есть, ссылка запрещена, открыть в новом табе не могу. Приходится нажимать, чтобы оно открылось в правой части (операция не быстрая даже при идеальных каналах, ваши сервера обычно пригружены), вызывать постоянную ссылку на задачу и открывать уже её в новом табе. Иногда есть при этом «open as separate tab» в меню страницы (три точки в правом верхнем углу — а почему горизонтальные? стандарт де факто — вертикальная линия точек или три горизонтальные полоски, размещённые вертикально), иногда нет (почему так — выяснить невозможно, это логика серверной стороны).
Это, наверно, меньше половины проблем — не записывал. В сочетании с постоянным торможением за счёт зверски перегруженных скриптами страниц и выкачиванием этого всего с удалённых серверов — все подобные вроде бы мелочи становятся критичными и через несколько минут хочется убивать авторов.
Вероятно, вы вложили 100% в оптимизацию для телефонов/планшетов, а браузерная версия делается в лучшем случае по остаточному принципу?
Вне UI: Невозможно получать почтовые оповещения о собственных действиях в задачах: таких пунктов в настройках просто нет. О том, что бывает важно иметь _полную_ историю в почте, вы не думаете.
(Ну да, плачу́ не я, поэтому всем пофиг.)
Спасибо за столь подробный фидбек о продукте. Он здесь действительно оффтопик. Если вы хотите поговорить о юзабельности, заходите в гости, мы всегда открыты к фидбеку. Возможно, мы подскажем, как ваши юзкейсы решать с помощью Райка более продуктивно. Также 24/7 у нас доступен саппорт — ребята всегда готовы объяснить нюансы продукта, логику той или иной функциональности и помочь настроить флоу именно под особенности вашей работы: support@team.wrike.com
Интересная статья. А есть какие-нибудь мысли по поводу применения SCRUM для проектов в других отраслях. Например не в IT, маркетинге или финансах, а в например в производстве: добывающих отраслях, металлургии, машиностроении и т.д.
Есть ли информация по применению Agile SCRUM на проектах по внедрению Lean и 6 Sigma? В первом приближении и там и там проекты, и там и там сложный продукт в меняющейся среде и условиях.
Есть ли информация по применению Agile SCRUM на проектах по внедрению Lean и 6 Sigma? В первом приближении и там и там проекты, и там и там сложный продукт в меняющейся среде и условиях.
насколько я знаю, lean родился в 50-х годах прошлого веках в стенах тойоты, и именно они стали двигателем всего этого направления. потом подтянулись другие отрасли и страны. в книжке бережливое производство описывается как раз разные практики разных отраслей, компаний и стран
Тема: что, где и как зародилось — холиварная, вот пример bobemiliani.com/comparing-tps-and-lean (историю пишут победители)
Я сторонник работающих практик, изучать опыт других — это хорошо.
Я сторонник работающих практик, изучать опыт других — это хорошо.
Нет. Я про применение фреймворка SCRUM для проекта по внедрению Lean. Lean — не проектная методология, это набор инструментов, и в данном случае просто продукт проекта. А вот организовать проект по Agile/Scrum — вполне возможно. У меня просто есть определенный опыт и интересно было бы найти людей с похожим опытом. Поэтому поинтересовался
Повторюсь, что подобного реального опыта у меня нет. Вообще слабо даже в теории представляю как scrum использовать для проведения изменений. Вот годное видео про то как через канбан метод это делать youtu.be/-CQOb7e-6sg
Если опишите свой опыт про внедрение Lean через Kanban, то с большим удовольствием почитаю.
Если опишите свой опыт про внедрение Lean через Kanban, то с большим удовольствием почитаю.
Спасибо. Интересное видео.
«Вообще слабо даже в теории представляю как scrum использовать для проведения изменений. „
На самом деле абсолютно просто. Более того, и Agile и Scrum могут применяться вообще отдельно от IT, потому что по сути это не об IT, а об управлению проектами. Точнее Scrum об управлении проектами, а Agile — вообще о любом взаимодействии людей в рамках рабочих отношений.
То есть если абстрагироваться от разработки ПО. Берём любой проект. Например строительство дома. Легко реализуемо в Scrum формате. Ваш объём работ — это ваш бэклог. Ваши будущие владельцы дома, плюс владельцы вашей компании (ваши боссы)+надзорные органы = ваши клиенты.
Ваши каменщики, электрики, сантехники, маляры — ваша кроссфункциональная команда (Если коллектив небольшой, то очень часто они вообще мастера на все руки, так что взаимозаменяемы).
Дальше вешаете КАНБАН или лучше СКРАМБАН доску и вперёд — ежедневный чекин поможет всем быть в курсе происходящего, вовремя заказывать материалы, не штукатурить стены, которые предстоит штробить и т.д.)
Все точно также можно распланировать на спринты, точно также можно воспитывать самоорганизацию в командах и т.д. Плюс применять lean production 6 сигма и другие вещи где надо.
В принципе мы точно также делаем Scrum проекты по внедрению Lean — для внедрения есть некоторый набор действий (провести интервью с руководством, напечатать раздаточную инфу, проводить семинары, обучения, практические занятия и т.д.) — все эти вещи по сути ничем не отличаются от “создать страницу, разработать фичу для сайта, подправить шапку на главной и т.д.) то есть без разницы какие действия вы производите — для Scrum это вообще пофиг.
Но правда мы кроме проектов в виде Scrum идём дальше и внедряем Agile management на уровне организации. То есть ломаем „колодцы“, создаем кроссфункциональный Скрам ов Скрамс для внедрения решений по операционным улучшениям, которые влияют на всю цепочку создания ценности компании.
Так что чем больше работаю, тем больше убеждаюсь — Agile/Scrum — это вообще не про IT. Просто IT первые взяли их на вооружение, учитывая специфические требования в скорости к этой отрасли и её свободную культуру, которая изначально склонна к такому гибкому типу взаимодействия.
«Вообще слабо даже в теории представляю как scrum использовать для проведения изменений. „
На самом деле абсолютно просто. Более того, и Agile и Scrum могут применяться вообще отдельно от IT, потому что по сути это не об IT, а об управлению проектами. Точнее Scrum об управлении проектами, а Agile — вообще о любом взаимодействии людей в рамках рабочих отношений.
То есть если абстрагироваться от разработки ПО. Берём любой проект. Например строительство дома. Легко реализуемо в Scrum формате. Ваш объём работ — это ваш бэклог. Ваши будущие владельцы дома, плюс владельцы вашей компании (ваши боссы)+надзорные органы = ваши клиенты.
Ваши каменщики, электрики, сантехники, маляры — ваша кроссфункциональная команда (Если коллектив небольшой, то очень часто они вообще мастера на все руки, так что взаимозаменяемы).
Дальше вешаете КАНБАН или лучше СКРАМБАН доску и вперёд — ежедневный чекин поможет всем быть в курсе происходящего, вовремя заказывать материалы, не штукатурить стены, которые предстоит штробить и т.д.)
Все точно также можно распланировать на спринты, точно также можно воспитывать самоорганизацию в командах и т.д. Плюс применять lean production 6 сигма и другие вещи где надо.
В принципе мы точно также делаем Scrum проекты по внедрению Lean — для внедрения есть некоторый набор действий (провести интервью с руководством, напечатать раздаточную инфу, проводить семинары, обучения, практические занятия и т.д.) — все эти вещи по сути ничем не отличаются от “создать страницу, разработать фичу для сайта, подправить шапку на главной и т.д.) то есть без разницы какие действия вы производите — для Scrum это вообще пофиг.
Но правда мы кроме проектов в виде Scrum идём дальше и внедряем Agile management на уровне организации. То есть ломаем „колодцы“, создаем кроссфункциональный Скрам ов Скрамс для внедрения решений по операционным улучшениям, которые влияют на всю цепочку создания ценности компании.
Так что чем больше работаю, тем больше убеждаюсь — Agile/Scrum — это вообще не про IT. Просто IT первые взяли их на вооружение, учитывая специфические требования в скорости к этой отрасли и её свободную культуру, которая изначально склонна к такому гибкому типу взаимодействия.
В целом я верю, что эффективный Scrum может быть за пределами IT. Например, я был на экскурсии в NPM, где scrum в производстве (Вот тут Сергей Чирва рассказывает, как они это сделали — youtu.be/kj-hyR4-MK8)
Вот этот вопрос не совсем понял. Если это про мой опыт, то: нет, сам не делал таких внедрений. Со стороны наблюдал за попытками внедрить Lean. Или в чем вопрос?
Есть ли информация по применению Agile SCRUM на проектах по внедрению Lean и 6 Sigma?
Вот этот вопрос не совсем понял. Если это про мой опыт, то: нет, сам не делал таких внедрений. Со стороны наблюдал за попытками внедрить Lean. Или в чем вопрос?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Лечение «механического» Scrum. Часть 1. Работа PO