{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Kanban.club: posts tagged scrum-case", "_rss_description": "Кратко и по делу о Kanban, Scrum, LeSS, SAFe и все, что может пригодиться в работе менеджеру", "_rss_language": "en", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/www.kanban.club\/?go=tags\/scrum-case\/", "feed_url": "https:\/\/www.kanban.club\/?go=tags%2Fscrum-case%2Fjson%2F", "icon": false, "authors": [ { "name": "Роман Петров", "url": "https:\/\/www.kanban.club\/", "avatar": false } ], "items": [ { "id": "84", "url": "https:\/\/www.kanban.club\/?go=all\/keys-scrum-posle-3-mesyacev-raboty\/", "title": "Кейс. Scrum после 3 месяцев работы", "content_html": "

Что было выявлено по итогу присутствия на ретроспективе, у команды, которая уже около 3 месяцев работает по Scrum. Команда из 7 человек, причем ВП и СМ находятся в одной локации, а вся остальная команда в другой.<\/p>\n

Что имеем из фактуры, над которой можно поработать:<\/b><\/p>\n

    \n
  1. Цель спринта состоит из 8 пунктов, в формате что надо сделать. (причина – задачи не связаны друг с другом, а раз так, то и разные цели)<\/li>\n
  2. Запланированный на спринт объем работы, команда не выполняет (команда хочет лучше оценивать задачи в человеко-часах и просит СМ дать им инструменты, чтобы трекать это Jira)<\/li>\n
  3. Команда не довольна оценкой результативности от ВП по результатам обзора, в прошлый раз было 4.5 из 10, в этот раз 3.5 из 10, команда не довольна и хочет лучше планировать<\/li>\n
  4. На ревью пользователи не приходят, так как им нечего показывать<\/li>\n<\/ol>\n
    \n\"\"\n<\/div>\n

    Варианты, что можно улучшить Скрам-мастеру в его команде:<\/b><\/p>\n

      \n
    1. Сейчас ВП и команда по разные стороны баррикад, так как на обзоре никого кроме ВП и команды нету, то это походит на отчетную встречу. По этому команда спрашивает у ВП, как хорошо она поработала, на что получает низкую оценку, так как ВП смотрит на разницу между что планировали и что сделали. Поэтому команда хочет защититься от этого, хочет начать мерить свое время, чтобы узнать что она молодец, но реальная причина не в этом. Результат – демотивация команды. СМ нужно вернуть команду и ВП на одну сторону и направить их к единой цели. Еще раз сформировать общее видение того, что делает команда (см. цель спринта). Цель сформулировать по SMART.<\/li>\n<\/ol>\n
        \n
      1. Обратную связь получать от Пользователей, так она будет объективной и команда должна мочь сама оценить свою результативность без интерпретации ВП. Объективность можно достичь тем, что это будет какая-то измеримая цель: количество денег, пользователей и т.д.<\/li>\n<\/ol>\n
          \n
        1. Признаться, что ниодна задача не сделана до конца и поставить самим себе за результат 0. Еще раз вернуться к теме, что такое DoD и чем он отличается от AC. СМ нужно запустить активность с командой по генерации DoD и посмотреть на свой бэклог спринта с тем, что вся команда уверена, что сможет сделать все запланированное с учетом согласованного DoD<\/li>\n<\/ol>\n
            \n
          1. Команда формирует много целей спринта, так как видит элементы бэклога разными, но у нас же это команда и она делает общие цели. Для этого нужно посмотреть на нашу цель, на наших пользователей и постараться найти какую-то объединяющую метрику для всех элементов бэклога, так называемую единую линейку, по которой можно мерить все элементы. Если такой общей линейки найти не удается, то тут нужно остановиться и признать, что у нас это не команда и сделать перезапуск.<\/li>\n<\/ol>\n
              \n
            1. Еще раз с командой проговорить цикл, что когда мы берем задачу в спринт, то обсуждаем АС (критерии приемки), все задачи обязательно проходят DoD. АС – для каждой задачи свой, DoD общий и его можно менять на ретроспективе. Команда получает ОС от пользователей напрямую, и это являются экологичным источником положительных или отрицательных эмоций, где ВП может подбодрить команду и прийти на планирование с новым задором.<\/li>\n<\/ol>\n

              Обязательно не забывать об экологичной обратной связи между всеми участниками процесса, чтобы не получить проблему на пустом месте.<\/i><\/p>\n

              После такого разбора, за такой период, СМ сказал: “Ааа.... я все сломал, ничего не работает, я почти убил команду” :)<\/p>\n

              И здесь лежит ловушка в том, что Scrum всегда не работает – и в этом и была задумка. В этом и есть источник улучшений команды для СМ. Включайте режим Коломбо, экспериментируйте, сначала сделайте все события скрам, потом улучшайтесь.<\/p>\n

              Реально убить команду СМ может только специально и это тоже надо уметь. Нельзя все сразу предусмотреть, каждая команда идет своим путем, ему нужно только помогать.<\/p>\n

              Автор Роман Петров<\/p>\n", "date_published": "2019-06-28T19:10:23+03:00", "date_modified": "2019-06-28T19:10:09+03:00", "tags": [ "DoD", "scrum", "scrum-case" ], "image": "https:\/\/www.kanban.club\/pictures\/Scrum-case-1.jpg", "_date_published_rfc2822": "Fri, 28 Jun 2019 19:10:23 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "84", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.kanban.club\/pictures\/Scrum-case-1.jpg" ] } } ], "_e2_version": 4134, "_e2_ua_string": "Aegea 11.3 (v4134)" }