Tagged: Scrum

Фреймворк SOAP для организационных изменений

Часто у начинающих Скрам-мастеров и Agile-коучей возникает вопрос: как мне организовать взаимодействие с командой или организацией, с которыми я работаю, чтобы не упустить ничего важного. Один из возможных ответов на этот вопрос я позаимствовал в медицине.

Фреймворк SOAP используется в рамках проблемно-ориентированного подхода к медицинским записям. Это удобный способ структурирования работы с пациентами, предложенный доктором Лоуренсом Уидом в 1970х. Он может применяться как при первичном осмотре для сбора анамнеза, так и при последующих осмотрах чтобы уточнить диагноз, проверить эффективность лечения и, при необходимости, скорректировать лечение. В медицине этот фреймворк содержит следующие компоненты:

Subjective – ObjectiveAssessment – Plan. Таким образом собирая анамнез и делая медицинские записи, врач последовательно проходит по 4 элементам:

  • Субъективные данные. Здесь собирается максимум информации о том, как больной оценивает своё состояние, историю развития этого состояние и т.п. Дополнительную структуру этой части опроса создаёт мнемоника OLDCHARTS (Onset, Location, Duration, Character, Aggravating / Alleviating factors, Radiation, Timing, Severity), описывающая ключевые элементы субъективной картины болезни: Возникновение, Локализация, Длительность, Характер, Усиливающие/Смягчающие факторы, Распространение, Тайминг, Серьёзность.
  • Объективные данные. Сюда входит изменение различных жизненных показателей (кровяное давление, пульс, температура и т.д.), результаты осмотра и инструментальных тестов (рентгенография, УЗИ и т.п.)
  • Оценка. В последнее время assessment всё чаще заменяют на Hypothesis так что мнемоника превращается в SOHP, чтобы сделать акцент на использовании доказательных подходов (этот вариант мнемоники был предложен клиническим психологом Барбарой Л. Инграм в её книге о клинической концептуализации), но принципиально суть этого элемента не меняется: в этой части врач описывает свои предположения о том, каков диагноз пациента на основе данных, полученных в предыдущих элементах. Оценка состоит из собственно диагноза и обоснования его постановки.
  • План. Собственно тут описывается план терапии с учётом полученных данных и диагностической гипотезы.

 

Безусловно, у этого подхода есть определённые недостатки, в частности, есть предположение, что он поощряет последовательный анализ частей проблемы вместо интегративного подхода, и скорее фокусируется на сборе данных, чем на собственно оценке и анализе. Однако на сегодня это наиболее широко распространённый подход, и он позволяет не забыть обо всех ключевых аспектах.

 

Здесь нужно сделать важное замечание. Структура SOAP/SOHP не описывает весь процесс взаимодействия с пациентом, она вложена в общую структуру сессии, которая меняется в зависимости от того, является ли эта встреча первой, или повторной встречей с пациентом. Важно, что любое действие, в том числе сбор данных, анализ и планирование с помощью фреймворка SOHP начинается с того, что терапевт объясняет, что он сейчас будет делать, для чего, и получает согласие пациента с этим планом. Помимо того, что принцип информированного согласия закреплён в законодательстве большинства стран, это важно ещё и для того, чтобы управлять ожиданиями пациента, а создать взаимное доверие – фактор, существенно влияющий на результаты интервенции.

 

При некоторой адаптации этот фреймворк хорошо подходит для работы с организационными изменениями, особенно для первичного знакомства с клиентом/командой и для планирования изменений. Начинаю я сессию с информирования клиента о том, как будет проходить наша работа (рассказ о структуре SOHP и о том, почему мне важна вся эта информация), получаю его согласие на эту работу, а далее использую адаптированный для agile-коучинга SOHP фреймворк:

  • Субъективные данные. Задача – собрать максимум информации о том, как клиент оценивает существующие проблемы организации и каковы его ожидания от привлечения Agile-коуча. Мнемонику OLDCHARTS  я немного расширил, так как, в отличии от медицины, где существуют объективные показатели здоровья, в организационных изменениях определение успеха может сильно отличаться у разных клиентов. Я использую OLDCHARTERS (Onset, Location, Duration, Character, Aggravating / Alleviating factors, Radiation, Timing, Expectations, Results at success/failure, Severity): Возникновение, Локализация, Длительность, Характер, Усиливающие/Смягчающие факторы, Распространение, Тайминг, Ожидания, Результаты в случае успеха и неудачи, Серьёзность. Для уточнения субъективной картины я использую такие вопросы:
    • Что побудило вас обратиться за помощью? (Так же как и с пациентом, я рекомендую начинать с максимально открытого вопроса и дать возможность клиенту высказаться, чтобы получить общее представление о том, как клиент воспринимает текущую ситуацию. Следом за этим можно задать вопрос, побуждающий к более детальному описанию проблемы: А что ещё?)
    • Как давно у вас существует эта проблема? Были ли у вас подобные ситуации в прошлом? Если да, то что именно и что вы делали в прошлый раз, чтобы улучшить ситуацию? (Возникновение / Длительность)
    • На сколько сильно вас беспокоит эта проблема? Мешает ли она вашим нормальной работе организации? Какую метафору бы вы использовали для описания проблемы? Как бы вы оценили интенсивность проблемы от 1 до 10? Как изменялась проблема с течением времени? (Серьёзность / Характер)
    • Описанная проблема характерна для всей организации, или какой-то её части?  Как локализация проблемы распространялась со временем? (Локализация/Распространение)
    • Что вы уже пробовали, чтобы изменить ситуацию? Как это повлияло на ситуацию? (Усиливающие/Смягчающие факторы)
    • Становится ли проблема со временем хуже, лучше или не меняется? Если есть изменения, с какой скоростью они происходят? (Тайминг / Длительность)
    • Есть ли какие-то ещё связанные проблемы? (Помогает выявить проблемы, которые клиент считает отдельными, но которые могут быть связаны с основным запросом)
    • Чем по вашему вызвана проблема? Чего вы опасаетесь в связи с этой проблемой? (эти вопросы помогают выявить предположения клиента о том, в чём причина и к чему может привести проблема, если её не решить)
    • Почему вы решили именно сейчас обратиться за помощью? Что изменилось по сравнению с тем, как эта проблема проявляется обычно? (Это может быть связано с тем, что проблема или ситуация ухудшилась, или, возможно, у клиента изменилось восприятие важности проблемы. Последнее часто происходит после посещения тренингов или наблюдения каких-то изменений в дружественной организации).
    • Чего вы ожидаете от меня в рамках нашего взаимодействия? Что, по вашим ожиданиям, я буду делать? Что, по вашим ожиданиям, я не буду делать? (Это очень важные вопросы, нацеленные на прояснение, чего ожидает клиент от вас и можете ли вы работать в соответствии с его ожиданиями, или вам нужно обсудить и выровнять ожидания.)
    • Как вы поймёте, что наша работа по изменениям привела к успеху? Что вы увидите в своей организации через полгода(год, три и т.п.) если мы вместе сможем решить проблему? (этот вопрос позволяет выявить, как клиент видит успех, а также оценить реалистичность ожиданий клиента)
    • Как вы поймёте, что наша работа стала полным фиаско? Что вы увидите в своей организации через полгода(год, три и т.п.) если наши усилия будут неудачными? (этот вопрос помогает выявить, что для клиента является критериями неуспеха, а также выявить возможные сценарии, при которых организационные изменения могут ухудшить ситуацию)
  • Объективные данные. На этом этапе проводится сбор имеющихся метрик, связанных с проблемой, которые помогут в дальнейшем оценить эффект от тех или иных изменений, сбор и систематизация результатом наблюдений за работой организации, качественная и количественная оценка текущего состояния. Здесь же можно предложить начать сбор дополнительных метрик, которые могут быть полезными для того, чтобы оценить эффект от изменений.
  • Гипотеза. Следующим шагом я строю гипотезу об источниках проблемы и обосновываю своё предположение. Чтобы эта часть была по-настоящему гипотезой, я не просто описываю, что я считаю причиной и почему я так думаю, но и описываю то, как я смогу проверить, что моё предположение верно, и какие эксперименты я могу провести, чтобы подтвердить или опровергнуть своё предположение, и какие результаты этих экспериментов я буду считать подтверждением.
  • План. Здесь я описываю план экспериментов по организационным изменениям с учётом полученных данных и гипотезы.

При интервью с клиентом я не использую точь в точь эту последовательность и формулировки вопросов. Скорее, они служат как руководство, а конкретная структура беседы возникает во время самого интервью, а формулировки вопросов я адаптирую с учётом языка клиента. Так, например, во многих организациях избегают использовать слово “проблема” применительно к тому, что происходит в организации, в этом случае я использую слова “ситуация”, “особенности” или какой-то ещё термин, характерный для конкретной беседы.

 

Ниже я привёл пример записей по результатам первоначальной встречи с руководителем отдела разработки (чтобы не раскрывать конфиденциальной информации, этот пример создан на основе комбинации нескольких реальных коучинговых проектов):

Контекст:

Команда, работающая над новым продуктом в крупной организации. В команде 5 человек, три разработчика и два тестировщика, используют Скрам-фреймворк. Команда подчиняется руководителю отдела разработки. Результаты первого интервью с руководителем

Subjective:

Команда новая, собрана из сотрудников, оставшихся от более крупного проекта по созданию информационной системы. В предыдущем проекте было несколько команд, работающих по Скраму, однако в течении долгого времени проект не мог поставить готовый продукт, и был закрыт из-за того, что заказчики со стороны бизнеса потеряли интерес. Сейчас команда работает над маленьким, но стратегически важным продуктом, которым интересуются топ-менеджеры компании. Скрам-мастер команды самостоятельно изучал Скрам, но, как и остальные члены команды, не проходил никаких тренингов по Agile и Скрам. Скрам-мастер попросил пригласить Agile-коуча чтобы убедиться, что они не делают явных ошибок в применение Скрама, которые могут привести к проблемам с продуктом или в команде. Я ожидаю, что ты понаблюдаешь за тем. как они работают, посмотришь на их артефакты и дашь рекомендации о том, что они могут улучшить, чтобы повысить их шансы на успешную поставку продукта в соответствии с ожиданиями заказчика. Я буду считать коучинг успешным, если Скрам-мастер и Заказчик скажут, что твои рекомендации помогли им лучше понимать друг друга. Идеальный успех – если команда сможет поставить что-то, что заказчик сможет пощупать в ближайшие 4 недели.

Objective:

Команда использует все элементы фреймворка Скрам. На текущий момент команда проработала 2 двухнедельных спринта, но пока не поставила ни одного инкремента продукта. Видение продукта явно не определено, хотя члены команды могут в целом описать, что они делают и кто их конечные пользователи. В бэклоге команды присутствует 12 элементов в формате User Story, ни у одного элемента не определены критерии приёмки.  Владелец продукта представитель бизнес-подразделения, транслирующий пожелания руководителя подразделения-заказчика. Владелец продукта затрудняется ответить, какой из элементов бэклога наиболее ценен с точки зрения бизнеса. Команда распределённая: Команда Разработки и Скрам-мастер сидят в одной комнате, владелец продукта находится в здании, расположенном в другой части города. Пока никаких метрик не собирается, кроме скорости работы команды (в Сторипоинтах). В течении первых двух спринтов команда поставляла около 50% от того, что было запланировано.

Hypothesis:

Низкая согласованность и слабые коммуникации между командой и бизнес-заказчиком ввиду того, что в роли Владельца продукта выступает человек, не имеющий ни полномочий для принятия решений, и не обладающий видением продукта. в результате чего роль сводится к транспортировке информации между командой и заказчиком, что замедляет принятия решений. Отсутствие явно определённого видения продукта не позволяет команде принимать решения, опираясь на ожидания бизнес-заказчиков. Обзор Спринта не выполняет основного предназначения – получения обратной связи от стейкхолдеров (ввиду отсутствия последних на обзоре спринта). Для проверки этих гипотез нужно сопоставить видение продукта и приоритеты с точки зрения руководителя подразделения-заказчика и с точки зрения членов команды разработки.

Plan:

  • Провести сессию по формированию Видения продукта и сессию улучшения бэклога продукта с привлечением бизнес-заказчика (руководителя подразделения на стороне бизнеса).
  • Рекомендовать пригласить руководителя подразделения-заказчика на Обзоры Спринта.
  • Наблюдение за событиями Скрама и коучинг Скрам-мастера по улучшению событий.
  • Персональный коучинг Скрам-мастера.

Эпизод 6. Иерархия в Скрам-команде

Эпизод 6. Иерархия в Скрам-команде
Трансформаторная

 
 
00:00 / 12:17
 
1X
 

Говорят, то в Agile и иерархии несовместимы. И что в Скрам команде нет иерархии. И в Команде Разработки внутри Скрам-команды все равны. Вот что я думаю…

Музыка для заставки: Our Only Lark, любезно опубликованная Blue Dot Sessions под лицензией Creative Commons Attribution-NonCommercial License.

Как я сдавал PSM-III

Недавно в обдом из обсуждений на Facebook несколько человек попросили поделиться опытом сдачи экзамена Professional Scrum Master III on scrum.org. Экзамен этот сложный (о чём недвусмысленно свидетельствует сравнение числа обладателей PMS-I, II и III: 153 702, 1 734 и 550 сооветственно). Я недавно его успешно сдал (дважды, 89% и 90,6% при проходном балле 85%), и я подумал, что будет интересно описать мой опыт в статье, чтобы, так сказать, за один раз поделиться со всеми интересующимися. (Как я вообще решился сдавать этот экзамен , и почему я сдавал его дважды— тема отдельной статьи. Которую я, может быть, когда-то тоже напишу). На scrum.org есть статья о подготовке к PSM-III, и я надеюсь и мой опус окажется полезен кому-то 🙂

Подготовка

Сдавал я не сразу PSM-III — сначала я сдал PSM-I и PSM-II. Я думаю, что это, хоть и наиболее затратный, но оптимальный подход. Я мог постепенно подготовить себя к возрастающей сложности вопросов, углубить и систематизировать свои познания, да и просто привыкнуть к самому процессу экзамена.

Готовясь к каждому из PSM-экзаменов я перечитывал Руководство по Скраму (также известное как Scrum Guide). Много раз. Здесь важно, во-первых, читать именно последню версию — экзамен отражает все изменения в Руководстве по Скраму на текущий момент. Во-вторых, важно то, как его читать. Я последовал совету Славы Москаленко: в первом чтении фокусироваться на общем понимании, во втором — на ключевых элементах, а в тертьем — задаться вопросом, почему каждый элемент описан именно так. Так я читал его перед первым и вторым PSM, но и перед третьим прочитал 2 раза, ища взаимосвязи между частями Скрама. Важно не выучить Руководство наизусть — это просто, важно понять, как оно описывает Скарм, и почему выбран именно такой а не какой-то иной способ изложения.

Перед третьим PSM лучше читать Scrum guide на английском. Сам экзамен сдаётся на этом языке, и всем нам — тем, для кого английский не родной язык — дополнительную сложность представляет именно языковой барьер (как минимум один ответ у меня был засчитан как неправильный потому, что я неверно подобрал слова, и лингвистические тонкости оказались весьма существенными).

На scrum.org есть список рекомендуемой литературы. Из рекомендуемой литературы я читал Ленциони 5 пороков команды, скрам покет гайд (его я читал прямо перед сдачей — не скажу, что там было что-то новое, но думаю, это тоже сыграло роль в систематизации знаний).

Я нашёл в интернете список вопросов PSM-3. Как оказалось, там не было ни одного вопроса, которые попадались мне, и, подозреваю, что этот список имеет очень отдалённое отношение к экзамену.Нно пройтись по этим вопросам и продумать ответ (как бы я ответил, и, главное, почему я бы ответил именно так) было полезно.

Суперполезным был тернинг PSM (я его проходил дважды, один раз у Славы Москаленко, второй у Саймона Рэндла) — некоторые из тем, рассматриваемых на тренинге, были довольно близки в нескольким вопросам.

В день экзамена

Важно выспаться. Куча исследований готорит о том, что недостаток сна сильно ухудшает когнитивные способности. А это не то, чего вы бы хотели в день экзамена.

Найдите место, где вас никто не будет беспокоить в течении 2 часов. Если вы сдаёте экзамен дома — придумайте, как закрыться от остальных домашних (и, конечно, объясните им важность концентрации во время экхамена). Если в офисе — подумайте, как убедиться, что вас не будут отвлекать (я зарезервировал переговорку и взял ключ, чтобы закрыться изнутри).

Сходите в туалет. Если вас припрёт во время экзамена, таймер не остановится, и вы потеряете драгоценное время.

Медитируйте. Серьёъно. Я это делаю перед каждым событем, из-за которого я волнуюсь — и это реально помогает (не верите моему опыту — обратитьесь кобширным исследованиям на эту тему). Мне помогает конфентрация на дыхании в течении 5–20 минут.

Приготовьте воды. Это сложный момент: с одной стороны, мучимые жаждой вы не сможете эффективно думать, с другой — слишком много воды приведут к потере драгоценного времени (см. пункт про туалет).

Приготовьте блокнот и ручку. В PSM 3 нет возможности отмечать вопросы, к которым вы хотите вернуться. Запишите номера этих вопросов на бумаге, чтобы проще было потом их пересмотреть (если останется время).

Не торопитесь. Но следите за временем. Из 34 вопросов, примерно, 30 — открытые (т.е. вопрос и TextBox — пиши что хочешь). Вам надо ответить максимально кратко и точно. Я прикидывал тайминг на каждые 5 вопросов, и старался оставаться в рамках того тайминга. Лучше в лёшкой спешке ответиь на все вопросы, чем в полной спешке пропустить все вопросы.

Следите за количеством вопросов в вопросе (обычно оно равно числу вопросительных знаков 🙂 Но это не точно). Убедитесь, что в ответе вы ответили на все.

Проверье, что в ответе вы учли ключевые элементы: эмпиризм, правила Скрама, роли, артефакты, события. В ответах про работу с командой помните, что Скрам-мастер — лидер-слуга (servant leader).

Не углубляйтесь в детали — дайте самый главный ответ. Понятно, что детали важны. Но тут важно показать не способность (пред)видеть и учитывать детали, а умение ясно выразить самое главное, и продемонстрировать понимание Скрама.

Коллеги из scrum.org рекомендовали отвечать в два захода. Сначала максимально быстро и кратко ответить на все вопросы, а потом (если останется время), вернуться, пересмотреть вопросы, и добавить деталей и красок там, где это необходимо.

Не парьтесь по поводу грамматики и орфорграфии. Они не оцениваются. Но убедитесь, что вы точно передали смысл и ваши ошибки не изскажают то, что вы хотели сказать.

После экзамена

Наберитесь терпения. Сразу после завершения экзамена вы получите результат failed — вопросов в выбором недостаточно для того, чтобы пройти. Но это ещё не окончателный результат — окончательный бвы получите через некоторое время, после того, как кто-то из scrum.org проверить ваши написанные вручную ответы. Обычно это занимает от 1 до 2 недель.

Инструменты для ретроспективы

Ретроспективы – один из самых важных инструментов Agile (и не только), который позволяет командам становиться лучше. А ещё это – совещание, требующе наиольшей открытости (и уязвимости) всех членов команды. По этой причине к ретроспективе следует готовиться очень тщательно. Выбор техник и инструментов для ретроспективы во многом определяет её успешность. Continue reading…