Лечение «механического» Scrum. Часть 1. Работа PO

    Я больше 10 лет работаю с / в / для agile в сфере web-разработки. Из них больше всего пришлось иметь дело с самым популярным agile фреймворком — scrum (по данным VersionOne). Хочу поделиться с вами накопленными наблюдениями и выводами.


    Начну с метафоры, так как иногда приходилось видеть внедрение scrum по такому сценарию:


    • До scrum: «разработка» как младенец — она целеустремленна, но не умеет нормально ходить, а очень хочет научиться, чтобы добираться до цели.
    • Внедрение: приходит учитель (scrum тренинги, курсы, agile coach и т.п.) и показывает, как ходить. Малыш счастлив, он двигается шагами! Топ-топ-топ. У нас спринты — мы ходим!
    • После внедрения: терпеливые стейкхолдеры говорят: «Окей, погнали к цели», на что получают «не давите на команду, мы ходим!». Разработка выписывает интересные траектории и получает удовольствие от процесса, но цель забыта.
    • Scrum-но: дальше пилюля правды от бизнеса, scrum «мутирует» и позволяет бизнесу получать какой-никакой продукт от разработки. И, к сожалению, формально ставится галочка «мы работаем по scrum», а реальный потенциал команды разработки так и не раскрыт, да и кругом говорят «scrum ненастоящий».



    По-моему, так происходит из-за того, что scrum часто внедряется «механически», без осознания сути фреймворка и его элементов. Хочется попытаться вскрыть симптомы «механического scrum»; разобраться, в чем недостатки подобного подхода; понять, что может быть лучше при «настоящем scrum с agile»; а также найти способы, которые помогут бороться с симптомами scrum-но. Этому я и посвящу пару-тройку статей здесь и буду рад вашим комментариям и вопросам.


    Для начала определимся, что же такое «механический scrum». С моей точки зрения, это когда формально присутствуют все роли, события и артефакты scrum, но забыты ценности и цели; когда отсутствует agile культура (т.е. высокая степень осознания и принятия agile manifesto и принципов). Когда нет понимания или даже попытки разобраться, для чего нужен тот или иной артефакт, или какая цель у событий в scrum. Все равно что робот в видео, который умеет крутить сальто, но кто назовет его гимнастом? При внедрении scrum важно донести до команды его цели и ценности, а не только механики. Agile культура усиливает scrum и делает его «настоящим». Scrum полезен для того, чтобы регулярно поставлять ценность и получать оперативную обратную связь. Scrum — это про скорость и развитие продукта. В теории звучит банально? Давайте попробуем разобраться, как работать по scrum и не растерять по дороге agile культуру и ценности scrum.


    При разборе элементов scrum в ScrumGuide одними из первых разбираются роли, мы поступим так же. Т.к. материала получилось много, то, чтобы дать возможность его осознать, он разбит на три части (Часть 2, Часть 3). Начнем анализ с Product Owner.


    Product Owner — Владелец продукта (PO):


    Product owner — это человек, отвечающий за продукт, он «владеет» продуктовым бэклогом. Главный инструмент PO — это видение развития продукта, а основная задача – максимизировать ценность продукта, выпускаемого командой. Вроде бы все просто: «Если ты смелый, ловкий и умелый...», но есть нюансы. У нас не учат на PO, зато учат на PM (project manager), и часто PM становятся PO, считая, что это просто смена названия, а подходы к работе можно оставить и старые. Но в agile так не работает. А как надо?



    Взаимодействие PO и продукта, Backlog-а


    Симптом: PO не отвечает за состав backlog, он просто работает над историями, полученными от других участников процесса. Или PO не отвечает за приоритезацию элементов backlog. Его работа доводить backlog до принятого в команде стандарта, а наполнение и приоритеты того, чем будет заниматься команда, он не определяет.
    Чем плохо: Если PO не обладает смелостью или возможностью создавать продукт (формировать backlog, расставлять приоритеты, проводить эксперименты и т.д.), это не PO, а какой-то другой вид деятельности. А без PO scrum не scrum. Не формируя Backlog, PO не может отвечать за продукт. Если за backlog отвечает не PO, то принятие продуктовых решений требует дополнительных коммуникаций — это лишнее потраченное время, что негативно влияет на скорость команды.
    Как лечим: нужно наделить PO единоличным правом принятия продуктовых решений и ответственностью за состав backlog. Если не принимающий решения PO — это установившийся порядок, то сложно в одночасье изменить ситуацию. Когда PO — это «proxy», то

    • Либо убираем его из уравнения и делаем PO реально того, кто отвечает за состав и приоритизацию backlog. Помогать PO работать над backlog-ом могут как команда разработки, так и специальная исследовательская команда (Product Discovery Team), но ответственность за состав и качество backlog должна оставаться только за одним человеком — PO.
    • Либо постепенно учим / позволяем / заставляем брать ответственность и принимать решения (состав элементов бэклога, приоритетность элементов и т.д.) текущего PO. Важны итерации: закрепление успехов, получение обратной связи.

    Симптом: У PO нет видения развития продукта, у него нет глобальной стратегии, нет цели, куда нужно привести продукт и зачем.
    Чем плохо: Главная сила PO — это видение продукта, понимание, для чего и для кого он создаётся. Этим видением он может мотивировать и «заражать» людей вокруг. Если видения нет, вряд ли продукт получится нужным и хорошим. Команда не будет «заряжена» на результат.
    Как лечим: PO важно в первую очередь сформулировать видение продукта. Он должен уметь в формате elevator pitch рассказать, какую крутую штуку он делает, для чего и для кого. Одна из agile ценностей — это прозрачность. Визуализируя различные артефакты разработки продукта, мы работаем над прозрачностью. PO может сформулировать своё видение и вывесить его перед командой. Лучше если работа по формулировке elevator pitch и видения будет делаться с некоторой периодичностью — как и другие scrum события (запланировали новую итерацию — сделали — собрали обратную связь).


    Симптом: PO не прорабатывает элементы backlog, не доводит их до принятых в команде соглашений, не занимается актуализацией элементов backlog, не вычищает его, не делает backlog grooming.
    Чем плохо: Если PO на текущий момент не уделяет достаточно внимания backlog на регулярной основе, ему все равно придется этим заниматься (спринты же надо собирать), но это будет более стрессово и затратно (например: коллективное наведение порядка в backlog на планировании спринта). Коммуникационные накладные расходы будут компенсироваться из времени, отведенного на разработку. PO начнет терять доверие команды: он не вкладывается в backlog – команда не будет вкладываться в инкремент. Плохой / неактуальный backlog уменьшает прозрачность для всех заинтересованных лиц. А scrum без прозрачности — не scrum.
    Как лечим: До PO нужно донести важность работы над backlog — статьи, книги, тренинги и т.д. Нужно выработать правила / регламент проведения Product Backlog Refinement (PBR), чтобы эти встречи были полезными и эффективными, проводя мини-ретроспективу после PBR, за несколько итераций можно качественно улучшить это мероприятие. Нужно командно совершенствовать механизм проведения PBR, достигая максимальной синергии PO и команды разработки. Backlog нуждается в регулярной чистке. Получая свежую информацию помимо добавления свежих историй в backlog, нужно не забывать убирать истории, потерявшие актуальность. Backlog должен содержать понятные команде и проработанные (в рамках договоренностей конкретной команды) элементы на 2-3 спринта, глубже проработанный бэклог может потерять актуальность. В целом, бэклог должен содержать Roadmap хотя бы на год, чтобы все заинтересованные лица чувствовали, что у продукта есть будущее. Если держать backlog, побитый на примерные инкременты, это поможет команде заранее думать про цели спринта (sprint goals).


    Симптом: PO работает над несколькими несвязанными продуктами или с несколькими командами. Как вариант – помимо основной PO занимает и другую роль в scrum процессе (или разработчик, или SM).
    Чем плохо: Быть PO – это непростая работа, требующая большой отдачи. Если роль PO совмещается с другой деятельностью, то с большой долей вероятности это плохо повлияет на качество результата. Опытные и зрелые PO могут одновременно вести несколько продуктов и работать с несколькими командами, если эти продукты «родственные» или являются близкими по функционалу частями одного большого продукта. Скорее всего только очень и очень уникальные люди могут одновременно делать, скажем, графический редактор для мобильных устройств и армейский авиатренажер. Чтобы быть эффективным, необходимо держать фокус на одной цели, прежде чем жонглировать несколькими.
    Как лечим: PO должен критично посмотреть на свои продукты: насколько проработано и сформулировано видение? Насколько команды понимают и принимают это видение? Насколько качественно проработан backlog? Прозрачен ли он для всех заинтересованных лиц? Есть ли roadmap продукта, всем ли он понятен? Команда понимает, чем будет заниматься ближайшие 2-3 спринта? Насколько хорошо известен пользователь и рынок? Какое качество взаимодействия с командой разработки? Если в каких-то из этих вопросов есть место для качественных улучшений, стоит оставить себе один продукт и сфокусироваться на нем.


    Взаимодействие PO и команды


    Симптом: PO директивно управляет командой, фактически работая по классической PM схеме. PO принимает все решения, даже самые незначительные, команда бегает к нему по любому вопросу.
    Чем плохо: Если PO занимается микроменеджментом внутри команды, принимает активное участие в разработке, то, с одной стороны, это демотивирует команду и не даёт ей развиваться (нет самоорганизации, ведь ответственность за локальные решения остается на PO), с другой стороны, это плохо для продукта, потому что усилия PO направлены внутрь процесса, и продукт может оставаться без его внимания.
    Как лечим: PO нужно убивать в себе PM, пробовать недирективные подходы в управлении и перестать воспринимать людей как ресурс. Если выстраивается директивная схема управления между PO и командой разработки, стоит привлечь внешнего или внутреннего фасилитатора, способного скорректировать взаимодействие. Нужно четко обозначить границы ответственности между PO и командой разработки — это прозрачность. Между PO и командой должны быть доверительные отношения: команда по большей части доверяет PO и его продуктовым решениям, а PO доверяет команде и тем решениям, которые команда принимает для реализации элементов backlog. У всех есть понимание того, что работа ведется для единой цели. Одним из возможных инструментов для PO может стать его «продуктовая» команда, в составе которой есть аналитики. Когда гипотезы основаны на цифрах и данных, то они вызывают больше доверия. Главное для PO не забывать делиться этими данными с командой разработки. Если команда несамостоятельная, то PO нужно учиться делегировать. Тогда команда будет вынуждена брать на себя принятие решений, как следствие ответственность, и постепенно она станет scrum командной.


    Симптом: PO и команда разработки регулярно конфликтуют, идет постоянная конфронтация, нет взаимопонимания.
    Чем плохо: PO и команда плывут в одной лодке, если между ними не налажены эффективные коммуникации, то вряд ли такая лодка сможет далеко уплыть. Много энергии будет тратится на налаживание взаимодействия, а не на разработку продукта. Цель у PO и команды одна и та же, значит, регулярных конфликтов быть не должно.
    Как лечим: Нужен опытный фасилитатор, способный выявить суть конфликта, убрать его и выстроить рабочие отношения. Если же все усилия не приводят к взаимопониманию, то возможно стоит поменять тандемы.


    Симптом: PO почти не коммуницирует с командой. Например, он доступен только в рамках обязательных встреч (планирование, sprint review).
    Чем плохо: Команда создает новый сложный продукт (Scrum is a framework for developing, delivering, and sustaining complex products.), следовательно работает в условиях большой неопределенности. Чтобы доставлять максимальную ценность им нужна информация, которая в большинстве случаев есть только у PO (это же его работа). При отсутствии информации могут делаться неправильные предположения и решения, как следствие будет теряться драгоценное время на их исправления.
    Как решать: PO должен быть доступен для команды, но команде не стоит этим злоупотреблять, иначе время PO будет расходоваться только на ad hoc вопросы. Следует выработать комфортный для всех формат взаимодействия, при котором команда своевременно получает от PO необходимую информацию и решения, которые команда действительно не может принять самостоятельно. Можно с определенной регулярностью звать на ретроспективы PO и обсуждать там вопрос частоты, инструментов и формата коммуникаций.


    Симптом: PO не прививает и не поощряет культуру обратной связи в команде. Или PO даёт однобокую обратную связь, отфильтровывая похвалу или критику.
    Чем плохо: Когда PO не дает регулярную честную обратную связь команде, это демотивирует команду. Нет синхронизации по ожиданиям и результатам. Команда не чувствует соучастия, они фактически не являются создателями продукта, они просто выполняют свою функцию. «Команда регулярно поставляет инкремент. Команда регулярно получает честную обратную связь по своей работе» — кажется, это справедливая сделка.
    Как лечим: PO конечно же не должен взваливать на команду весь тот объем информации с которым, он работает сам, все то, что он получает от пользователей и аналитиков. Он должен агрегировать и выдавать уже важную и понятную команде информацию. Хорошо придумывать различные форматы для обратной связи, а не только на базе сухих цифр (например: живые тестирования, интервью и т.п.). Команда сама должна напоминать PO о необходимости обратной связи: задавать вопросы, выстраивать регулярный процесс получения обратной связи. Если PO сделать «владельцем» события sprint review и озадачить его тем, что команда нуждается в обратной связи, это как минимум будет напоминать PO о работе над обратной связью, а может побудить к более творческому подходу в организации таковой.


    Взаимодействие PO и пользователей, рынка


    Симптом: PO не знает «своего» пользователя; продукт видит, как набор фич. PO игнорирует пользовательские запросы и информацию от существующих пользователей. Не общается с «живыми» пользователями.
    Чем плохо: В первую очередь, продукт создаётся для пользователя, у которого есть (возможно, он этого пока не знает) потребность, удовлетворяемая продуктом. И если не знать и не понимать пользователя, то невозможно «нести ответственность за достижение максимальной ценности продукта», как этого требует scrum guide.
    Как лечим: Есть много различных инструментов для проведения качественных исследований, например глубинные интервью, портрет пользователя, «дорожная карта» пользователя (customer journey map), инструменты для сбора качественной (vs количественной) аналитики и т.д. и т.п. Нужно пробовать различные инструменты и оставлять полезные / работающие для вашего продукта. Большинство этих инструментов на выходе имеют визуализацию результата, стоит их размещать перед командой, чтобы увеличивать прозрачность. Эти артефакты стоит время от времени актуализировать. Можно организовать исследовательскую команду (product discovery team) для помощи в проведении качественных исследований. Если PO сумеет наладить взаимодействие с пользователем, то он может этот контакт использовать, например, на sprint review: давая пользователю свежий инкремент, а команда будет исследовать, как пользователь справится с задачей, помощь в решении которой они закладывали в инкремент.


    Симптом: PO не изучает рынок / конкурентов.
    Чем плохо: Продукт живет как будто в вакууме, и оторван от реальности, нужно быть провидцем, чтобы создавать ценный продукт в таких условиях.
    Как лечим: Есть ряд практик для владельцев продуктов, как изучать и создавать рынки, стоит пробовать различные из них и оставлять приносящие пользу. В этой деятельности PO могут помогать аналитики или команда. Полезно время от времени искать "голубые океаны". Ну и конечно же, стоит черпать вдохновения на тренингах, продуктовых митапах и конференциях.


    Заключение


    Разбор остальных ролей появится в следующих частях. А сейчас давайте разберемся, чем вам эта информация может пригодиться. Мы рассмотрели некоторые возможные симптомы, говорящие, что в scrum что-то идет не так, и варианты изменения ситуации. Если хотите, чек-лист напоследок:


    1. Читая почти каждый из пунктов, вы узнавали себя (свою команду / организацию), т.е. у вас scrum с неканоническим пониманием. Тогда стоит задаться вопросами: нужен ли вообще вам scrum? Для чего вам scrum? Какие перед ним вы ставите задачи? Корпоративная культура готова к ценностям и принципам agile? Если у вас есть ответы и понимание, для чего нужен scrum, и вы действительно делаете на него ставку, то переходите ко второму варианту. Если нет, то перестаньте заниматься самообманом.
    2. Читая некоторые пункты вы подумали, что это не про вас. Некоторые пункты натолкнули вас на рассуждения и вы вспомнили свою ситуацию. Если это так, то выберите те пункты, которые могут быть применимы к вашей ситуации. Распечатайте их в виде карточек. Обсудите с командой симптомы: справедливы ли они для вас? Обсудите риски, согласны вы с ними, или, может быть, вы видите более опасные последствия от симптомов. Затем возьмите карточку, которая больше всего волнует команду, самый опасный симптом в настоящий момент. Рассмотрите предложенный вариант решения, подходит ли он вам? Придумайте коллективно, как можно улучшить ситуацию, как снять симптом. И действуйте! Разобравшись с одним симптомом, переходите к следующему, периодически возвращаясь к общему обзору, чтобы быть уверенными, что не просели уже достигнутые вами результаты.
    3. Если вы прочитали все и не узнали в этих ситуациях свои реалии, у нас все правильно. Неужели есть такие организации? Вы большие молодцы, обязательно поделитесь в комментариях тем, как вы этого достигли!

    P.S. Надеюсь, что статья даст рабочий инструмент scrum командам для самосовершенствования.


    P.P.S. За иллюстрации огромное спасибо Sai Kin


    UPD. Часть 2 и Часть 3.

    Wrike
    121.60
    Wrike делает совместную работу над проектами проще
    Share post

    Comments 35

      +3
      Пока что не удалось увидеть примеров успешного внедрения скрама. Если члены команды изначально не разделяют ценностей аджайла и не видят преимуществ использования скрам -практик, то все это превращается в двигание кроватей в борделе =(

      И вот честно не знаю что делать в таких ситуациях и надо ли вообще что то делать.
        0
        Изначально нужно исходить из проблематики: для чего внедряется scrum? И уже из ответа рассуждать об эффективности внедрения. Я тоже никогда не видел кристально чистого Scrum. Но Scrum, решающий поставленные перед ним задачи, встречается довольно часто. Дальше вопрос риторики — как называть получившийся процесс.

        Что касается изначального скептицизма команды, то это абсолютно нормально. Люди не любят перемен. И чтобы они с ними смирились или даже захотели, нужно показывать в чем собственно преимущества. Это и есть работа Scrum Master-а. Дело это не простое, но увлекательное (я об этом в следующих частях буду писать). Вспоминаем теорию скрама и строим эмпирический процесс демонстрации сильных сторон SCRUM для скептически настроенной команды.
          0
          Ну вот и получается, что или в команде есть общий взгляд на проблемы и тогда не надо ничего «внедрять» все делается естественно и само собой.

          Или такого взгляда нет и тогда это выглядит как «ок, вам нужны спринты? вот вам спринты! Вам нужны дейлики? вот вам дейлики!» и все это делается исключительно механически и для галочки. Этакий карго-скрам. И как побороть именно вот такой подход я пока не знаю. По моему оно не лечится. Проще или уволить людей или отказаться от попыток наладить какие то процессы.
            +1
            Ну собственно я и хочу попытаться помочь в такой ситуации этой серией статей. Вторую часть про команду, готовим к публикации. И следом пойдет про Scrum Master-а
              0
              На самом деле очень сложно объяснить, что такое команда. Я работал в крутой компании, где был очень крутой скрам
              Теперь на новом месте люди вообще понятия не имеют что это такое, никто не видел вживую и никто не верит в это. Я даже не могу объяснить что такое «доверие» в команде. Сразу заваливают вопросами — «А что, если Вася Пупкин будет тормозить, почему я должен страдать?»
                0
                Scrum guide учит нас, что сила в эмпирическом процессе (прозрачность, инспекция, адаптация.). Чтобы «объяснить» про доверие, проводите эксперимент: отмените индивидуальную оценку сотрудников снаружи команды; введите командную оценку и ответственность; дайте команде общую цель и помогите им сфокусироваться на ней. Задайте условия эксперимента — срок, критерии оценки и т.д. — это прозрачность. Проводите ежедневную синхронизацию членов команды и проведите ретроспективу по завершению эксперимента — инспекция. В случаи препятствий ищите варианты выхода — адаптация.

                Главное человеку (по-идее это scrum master), который будет проводить этот эксперимент, заранее подготовиться к нему: понять для чего он это делает? куда он хочет привести команду? чему хочет её научить? Поставив цель, надо разработать план, а дальше действовать.
                0
                Кстати, ещё один большой вопрос — какова роль классического Тим Лида в скраме?
                Я так понял, его вообще нет, потому что решения принимаются коллективно и все равнозначны
                В классическом waterfall есть тимлид, который каждому говорит как и что делать
                В итоге, если такой тим лид будет в скрам команде, то для конечного разработчика это ничем от waterfall-а не отличается
                  0
                  О про тимлида — это очень большой вопрос. На прошедшем весной Codefest в Новосибирске был отдельный поток про это. У Жени bunopus был классный доклад про ТимЛидство — 2018.codefest.ru/lecture/1316 очень советую посмотреть.
                  Так же мы устраивали дисскусию на эту тему — 2018.codefest.ru/lecture/1337
                    0
                    В базовой комплектации в скраме нет такой роли

                    Но никто не запрещает его назначить =)
                      0
                      Нужно аккуратно использовать вместе слова «scrum» и «назначить». Все-таки мы говорим об самоорганизации, как о ключевой характеристике scrum команды.
                      Лид может быть, вопрос в том какие задачи и как он решает.
            0
            Ну я вот эту часть читаю про ПО, типа

            «PO почти не коммуницирует с командой. Например, он доступен только в рамках обязательных встреч (планирование, sprint review)»

            было такое да. Вот не хочет ПО общаться с командой. Не интересно ему что она делает. И стори расписывать не хочет ( ну то есть вообще, у стори есть только название и TBD в дескрипшне). У него лапки. Потом на демо правда удивляется и говорит «я это не так себе представлял». А в день релиза он уходит в отпуск и вырубает телефон и все мессенджеры.

            Говоришь об этом начальству «ну да, вот такой вот он у нас человек» зато «мы успешно внедрили скрам во всех командах».

            Ну можно конечно заставить его ходить на ретро, но как сделать его реально заинтересованным в продукте? я не знаю. И для себя ответа в статье не нашел, извините =(
            Но конечно подожду что вы дальше напишите, может что полезное и будет.
              0
              Отличный кейс! Странно, что PO надо заинтересовывать в продукте. Если продукт не нужен PO, то кому он вообще тогда нужен?

              А в день релиза он уходит в отпуск и вырубает телефон и все мессенджеры.
              Ну это просто не профессионализм независимо от позиции в компании. Детский сад. Зачем такой человек компании в принципе? Какие задачи он решает?

              зато «мы успешно внедрили скрам во всех командах».
              Если есть доступ к руководству, задайте прямой вопрос: «а для чего? Зачем мы внедрили Scrum?»

              Из описания очень похоже, что ваш PO — это «прокси». И возможно есть настоящий PO — заинтересованный в продукте, который реально принимает решения: что делать и в какой последовательности. Возможно это сверх-занятой человек и у него просто нет времени заниматься бэклогом, тогда он может создать небольшую команду (discovery team — куда например могут входить аналитики и ui/ux специалисты), которая бы помогала ему в этом. Но важно донести до него, что наличие «прокси» с одной стороны искажает информацию в оба направления, с другой стороны коммуникации становятся дольше.

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


                «раз у нас теперь скрам, то теперь ты будешь зваться ПО»

                Если есть доступ к руководству, задайте прямой вопрос: «а для чего? Зачем мы внедрили Scrum?»


                Уже задавал неоднократно =), реально у людей непонимание что и зачем они делают и это не на одном проекте или в одной команде.

                Но если подытожить, мне кажется аджайл невозможно насадить, он должен быть в сердце. Попытки делать скрам в отсутствии «команды мотивированных профессионалов нацеленных на качество продукта» приводит лишь к страданиям для всех. Типа если у вас нет такой команды, то дальше статьи вроде вашей можно не читать не потому что они плохие, а потому что смысла не будет все равно. Сугубо имхо конечно, но пока мой опыт такой. Но буду ждать что вы напишите дальше =)
                  0
                  В целом вы правы, если нет понимания для чего внедрять Scrum и какие стоят перед ним задачи, то ничего хорошего из этого не выйдет. Чудо само по себе не случится. Карго-Scrum действительно дает больше боли, чем пользы.

                  Но важно понимать, что команда / кадры тут скорее всего не при чем (человеческая природа — искать состояние покоя). Нужны Агенты Изменений, который понимают, что они хотят сделать и зачем. Организация и её культура должны быть готовы к agile и тогда всё получится: можно построить из группы людей — «команду мотивированных профессионалов нацеленных на качество продукта». Но для этого нужно честно ответить себе на вопросы: «Для чего мы это делаем? Готовы ли мы меняться?».

                  Запустить Scrum сама по себе задача непростая, а делать это в партизанских условиях — это просто героизм. ИМХО сперва нужно, чтобы «наверху» осознали и приняли, а дальше уже народ потянется.

                  Ну и конечно «насадить» нельзя, но научить можно.
                  0
                  А в день релиза он уходит в отпуск и вырубает телефон и все мессенджеры.
                  Ну это просто не профессионализм независимо от позиции в компании. Детский сад. Зачем такой человек компании в принципе? Какие задачи он решает?

                  Непонятно. Почему вы отказываете профессионалу в отдыхе? Все эти скрамы с аджайлами — это не цель всей жизни, и не новая форма крепостничества.
                    0
                    Прекрасно сказано!
                    Действительно Agile и Scrum — это про эффективность:
                    image

                    Это про то, как делать так, чтобы и работа сделана и личная жизнь в приоритете.
                +1
                очень понравилось
                жду продолжения
                  +1
                  Готова вторая часть — habr.com/company/wrike/blog/415563
                    +1
                    Ура!
                    как раз дочитываю книжку «Пять пороков команды»)
                      +1
                      прочитал, большой респект!
                      очень понравились ваши комментарии на мысли коллег
                      0
                        0
                        о, как здОрово!

                        спасибо!

                        я обязательно поделюсь своими мыслями-вопросами сразу по всем трем частям
                      +1
                      Отличная статья!
                        +2

                        Особый восторг вызвало наличие методических рекомендаций по применению поданного материала в заключении. Спасибо.

                        0
                        Извините за уход немного в сторону.
                        Два года пользуюсь на работе вашим сервисом, читаю этот блог… и всё никак не могу понять, как все эти высокие слова сочетаются с тем, что ваша браузерная версия (для десктопов) открыто построена с тяжёлыми неудобствами для клиента?

                        Открываешь тикет, в заголовке страницы — заголовок тикета. OK. При перезагрузке страницы (например, при рестарте браузера) там почему-то написано Inbox. При этом в странице остаётся тот же тикет.
                        Открыл несколько тикетов из, например, почты? Перезагрузил — вижу 4 страницы «Inbox».
                        Разумеется, кнопка Inbox при этом не работает: вы решили её отключить. Рядом есть всякие My Work, Dashboards, и так далее. Но они не ссылки, они только скриптовые реакции. Я хочу открыть My Work в соседней вкладке, почему я не могу это сделать? Вы не умеете делать элемент, что работает и как ссылка (например, по правой кнопке даёт open in new tab) и как реакция? Почему это работает в некоторых других местах?
                        Знак «три горизонтальные полоски» у всех нормальных людей уже давно означает меню действий/опций (см. тот же Firefox). У вас он почему-то вызывает удаление или появление подокна иерархии задач. Нельзя было сделать "" / ""?
                        Список по My Work. Задачи в списке есть, реакция на нажатие есть, ссылка запрещена, открыть в новом табе не могу. Приходится нажимать, чтобы оно открылось в правой части (операция не быстрая даже при идеальных каналах, ваши сервера обычно пригружены), вызывать постоянную ссылку на задачу и открывать уже её в новом табе. Иногда есть при этом «open as separate tab» в меню страницы (три точки в правом верхнем углу — а почему горизонтальные? стандарт де факто — вертикальная линия точек или три горизонтальные полоски, размещённые вертикально), иногда нет (почему так — выяснить невозможно, это логика серверной стороны).
                        Это, наверно, меньше половины проблем — не записывал. В сочетании с постоянным торможением за счёт зверски перегруженных скриптами страниц и выкачиванием этого всего с удалённых серверов — все подобные вроде бы мелочи становятся критичными и через несколько минут хочется убивать авторов.
                        Вероятно, вы вложили 100% в оптимизацию для телефонов/планшетов, а браузерная версия делается в лучшем случае по остаточному принципу?

                        Вне UI: Невозможно получать почтовые оповещения о собственных действиях в задачах: таких пунктов в настройках просто нет. О том, что бывает важно иметь _полную_ историю в почте, вы не думаете.

                        (Ну да, плачу́ не я, поэтому всем пофиг.)
                          +1
                          Спасибо за столь подробный фидбек о продукте. Он здесь действительно оффтопик. Если вы хотите поговорить о юзабельности, заходите в гости, мы всегда открыты к фидбеку. Возможно, мы подскажем, как ваши юзкейсы решать с помощью Райка более продуктивно. Также 24/7 у нас доступен саппорт — ребята всегда готовы объяснить нюансы продукта, логику той или иной функциональности и помочь настроить флоу именно под особенности вашей работы: support@team.wrike.com
                          +1
                          Интересная статья. А есть какие-нибудь мысли по поводу применения SCRUM для проектов в других отраслях. Например не в IT, маркетинге или финансах, а в например в производстве: добывающих отраслях, металлургии, машиностроении и т.д.

                          Есть ли информация по применению Agile SCRUM на проектах по внедрению Lean и 6 Sigma? В первом приближении и там и там проекты, и там и там сложный продукт в меняющейся среде и условиях.
                            0
                            насколько я знаю, lean родился в 50-х годах прошлого веках в стенах тойоты, и именно они стали двигателем всего этого направления. потом подтянулись другие отрасли и страны. в книжке бережливое производство описывается как раз разные практики разных отраслей, компаний и стран
                              0
                              Тема: что, где и как зародилось — холиварная, вот пример bobemiliani.com/comparing-tps-and-lean (историю пишут победители)

                              Я сторонник работающих практик, изучать опыт других — это хорошо.
                                0
                                Нет. Я про применение фреймворка SCRUM для проекта по внедрению Lean. Lean — не проектная методология, это набор инструментов, и в данном случае просто продукт проекта. А вот организовать проект по Agile/Scrum — вполне возможно. У меня просто есть определенный опыт и интересно было бы найти людей с похожим опытом. Поэтому поинтересовался
                                  0
                                  Повторюсь, что подобного реального опыта у меня нет. Вообще слабо даже в теории представляю как scrum использовать для проведения изменений. Вот годное видео про то как через канбан метод это делать youtu.be/-CQOb7e-6sg

                                  Если опишите свой опыт про внедрение Lean через Kanban, то с большим удовольствием почитаю.
                                    0
                                    Спасибо. Интересное видео.

                                    «Вообще слабо даже в теории представляю как scrum использовать для проведения изменений. „

                                    На самом деле абсолютно просто. Более того, и Agile и Scrum могут применяться вообще отдельно от IT, потому что по сути это не об IT, а об управлению проектами. Точнее Scrum об управлении проектами, а Agile — вообще о любом взаимодействии людей в рамках рабочих отношений.

                                    То есть если абстрагироваться от разработки ПО. Берём любой проект. Например строительство дома. Легко реализуемо в Scrum формате. Ваш объём работ — это ваш бэклог. Ваши будущие владельцы дома, плюс владельцы вашей компании (ваши боссы)+надзорные органы = ваши клиенты.

                                    Ваши каменщики, электрики, сантехники, маляры — ваша кроссфункциональная команда (Если коллектив небольшой, то очень часто они вообще мастера на все руки, так что взаимозаменяемы).

                                    Дальше вешаете КАНБАН или лучше СКРАМБАН доску и вперёд — ежедневный чекин поможет всем быть в курсе происходящего, вовремя заказывать материалы, не штукатурить стены, которые предстоит штробить и т.д.)

                                    Все точно также можно распланировать на спринты, точно также можно воспитывать самоорганизацию в командах и т.д. Плюс применять lean production 6 сигма и другие вещи где надо.

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

                                    Но правда мы кроме проектов в виде Scrum идём дальше и внедряем Agile management на уровне организации. То есть ломаем „колодцы“, создаем кроссфункциональный Скрам ов Скрамс для внедрения решений по операционным улучшениям, которые влияют на всю цепочку создания ценности компании.

                                    Так что чем больше работаю, тем больше убеждаюсь — Agile/Scrum — это вообще не про IT. Просто IT первые взяли их на вооружение, учитывая специфические требования в скорости к этой отрасли и её свободную культуру, которая изначально склонна к такому гибкому типу взаимодействия.
                                0
                                В целом я верю, что эффективный Scrum может быть за пределами IT. Например, я был на экскурсии в NPM, где scrum в производстве (Вот тут Сергей Чирва рассказывает, как они это сделали — youtu.be/kj-hyR4-MK8)

                                Есть ли информация по применению Agile SCRUM на проектах по внедрению Lean и 6 Sigma?

                                Вот этот вопрос не совсем понял. Если это про мой опыт, то: нет, сам не делал таких внедрений. Со стороны наблюдал за попытками внедрить Lean. Или в чем вопрос?
                                  0
                                  Спасибо за ссылку. Выше уточнил, что я имел в виду.

                              Only users with full accounts can post comments. Log in, please.