{"id":14262,"url":"\/distributions\/14262\/click?bit=1&hash=8ff33b918bfe3f5206b0198c93dd25bdafcdc76b2eaa61d9664863bd76247e56","title":"\u041f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u0442\u0435 \u041c\u043e\u0441\u043a\u0432\u0435 \u0438\u043d\u043d\u043e\u0432\u0430\u0446\u0438\u044e \u0438 \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u0435 \u0434\u043e 1,5 \u043c\u043b\u043d \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"\u041f\u043e\u0434\u0440\u043e\u0431\u043d\u0435\u0435","imageUuid":"726c984a-5b07-5c75-81f7-6664571134e6"}

Завершение спринта в Scrum – демо и ретро

В этой, тринадцатой статье из серии «Менеджмент цифрового мира» я продолжу рассмотрение схемы скрам и буду говорить про завершение спринта – Демо, оно же Sprint Review и Ретроспективу. Она продолжает предыдущие статьи «Итерации Scrum – целостная схема, а не прикольная картинка», где мы рассмотрели переход к итеративной работе и планирование, и «Схема Scrum – ежедневная работа внутри спринта».

​Схема Scrum. Из моих презентаций. 

Демо – оцениваем результат

Назначение Демо – показ результатов, достигнутых командой, и их оценка стейкхолдерами. Именно получение оценки от стейкхолдеров является основной функцией демо: соответствует ли это их ожиданиям, решает ли поставленные задачи и приносит ли ценность. И официальное название в Scrum Guide – Sprint Review это подчеркивает. Но термин «Демо» является устоявшимся в сообществе, гораздо более коротким и я предпочитаю использовать именно его, тем более, что исторически именно это название я узнал первым, прочитав в 2007 книгу Хенрика Книберга «Скрам и XP: заметки с передовой», которую уже упоминал в предыдущей статье.

Возникает вопрос: а почему, собственно нужна такая обратная связь? Ведь задачи в процессе исполнения перемещались по доске, каждая смена статуса имела свой чек-лист завершения, о чем я писал в статье «Доска - визуализация текущего состояния работы», включая, естественно, критерий сделанной задачи, Definition of Done (DoD)? Разве этого недостаточно? Ответ: нет, этого недостаточно.

Если бы ценность задачи можно было бы обеспечить выполнением чек-листа, то никакой бы Agile был не нужен, с организацией IT-проектов хорошо бы справились методы классического менеджмента. Проблема состоит в высокой сложности социотехнических систем, в результате чего все представления о необходимых функциях и о работе пользователей – не более чем гипотезы, подлежащие проверки. А на бытовом уровне эта ситуация хорошо описывается словами «заказчик сам не знает, чего он хочет». Именно поэтому разработанный софт требует постоянной проверки: несет ли он ценность пользователям. Впрочем, тоже самое можно сказать о любых других продуктах – проверить, полезен ли продукт потребителям, нужен ли им можно только экспериментально.

Обычно Демо проводится в виде встречи, на которой присутствует команда и все заинтересованные стейкхолдеры: члены команды демонстрируют созданную ценность и получают обратную связь. Именно такую форму рекомендует Scrum Guide. Процедура кажется простой, однако практически с таким способом связано несколько проблем, которые мы обсудим далее.

Проблемы получения релевантной обратной связи

Итак, какие же проблемы могут быть связаны с простой демонстрацией?

Во-первых, далеко не всегда на Демо удается обеспечить присутствие необходимых стейкхолдеров, среди них часто встречаются реально занятые люди.

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

Да и при заказной разработке софта случается, что заказчиком является руководитель бизнес-подразделения, который приносит проблему не эффективного выполнения каких-либо операций, которую должен решить новый функционал, и, не выполняя операционную работу непосредственно, он часто не может оценить реализацию, а пользователям, которые могут это сделать, надо для оценки самим попробовать функционал на реальных данных…

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

Отметим, что далеко не всегда эти проблему могут быть в конкретно вашем проекте. Наоборот, в большинстве проектов демонстрации стейкхолдерам достаточно, иначе бы в Scrum Guide не было бы рекомендованного способа. Ну или так было, когда Scrum формировался. Отметим, кстати, что переход от функциональных требований к user story отчасти проблемы демонстрации решал: мы вместо выполнения функций описывали цели пользователей, и демонстрация, как пользователи будут их достигать, работая используя разработанный софт, должна быть достаточна.

Однако, что делать, если проблема в вашем проекте существует? Правильный способ решения этих проблем – придумать альтернативные механизмы получения релевантной обратной связи и встроить в процесс именно их, чтобы обеспечить выполнение основной функции демо. Например, в цикл выполнения задачи может быть включено не только тестирование, но выкатка на боевые сервера и A/B тестирование на пользователях. Или установка его на тестовые сервера заказчика с приближенными к боевым данными, и проведение обучения и демонстрации конечным пользователям. Таким образом, есть различные варианты.

Но на практике вместо разработки механизмов часто просто назначают формального ответственного «ты будешь смотреть и оценишь результат». И в результате команда идет по неверному пути, а выясняется это только на внедрении функционала. Я слышал истории, когда эти проблемы возникали даже когда таким ответственным стейкхолдером был руководитель проекта от заказчика: он был на демо, был очень доволен, команда была вдохновленной. А потом оказалось, что он не слишком давно работает у заказчика, и его представления о процессе были основаны на опыте работы в другом месте. Поэтому, когда функционал принесли конечным пользователям, то выяснили его слабую пригодность для реального процесса. Заметим, что техническая выкатка изменений на боевые сервера не спасает, так как пользователи, не зная о новых функциях им просто не пользуются. А вот изменение работы пользователей в любом случае надо отдельно организовывать.

Отмечу, что примерно те же проблемы возникают и при применении Scrum для не IT-проектов: новые продукты или новые материалы недостаточно просто сделать и предъявить, могут быть необходимы испытания, тестирование на пользователях или у заказчиков. Типичный пример – маркетинг, конечным результатом маркетинговой компании тут являются привлеченные пользователи или покупатели, а вовсе не публикация рекламы, и именно по ним можно определить ценность.

Что делать с долгой обратной связью?

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

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

Другой вариант – вынести получение обратной связи от пользователей за пределы Scrum в отдельный Kanban-процесс. Он целесообразен в том случае, если с ним связаны длительные временные лаги, не укладывающиеся в короткий Scrum-цикл.

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

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

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

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

Другие задачи демо

Помимо описанной выше задачи получения обратной связи от стейкхолдеров о ценности созданного продукта, Демо решает еще пару задач.

Во-первых, на демо идет оценка достижения целей спринта со стороны стейкхолдеров. И связанное с этим позиционирование достигнутого результата как часть более крупных циклов планирования или целеполагания: вклад спринта в разработку релиза, в продвижение к квартальным или годовым целям. Подробнее о цикле релизного планирования я буду говорить в следующей статье, рассказывая полную схему Scrum. А вот работа с квартальными и годовыми целями находится за пределами обеспечиваемого Scrum, для этого можно применять OKR (Objectives and Key Results). До OKR я тоже доберусь в будущих статьях, хотя, наверное, без подробностей. Но независимо от метода, в демо полезно включить оценку продвижения к целям по мнению стейкхолдеров.

Во-вторых, на Демо стоит получить обратную связь от стейкхолдеров по работе и восприятию команды в целом. Не по созданной ценности, а по характеру коммуникаций и другим аспектам взаимодействия.

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

Однако, как и в случае оценки ценности, если эти виды обратной связи на Демо получить нельзя, необходимо обеспечить другие механизмы ее получения. Ответственным за получение и донесение до команды обратной связи по целям является Product Owner, а по взаимодействию – они делят эту ответственность со скрам-мастером. Почему делят? Потому что к части стейкхолдеров Product Owner все равно пойдет по первому вопросу, и может заодно выяснить второй, нет смысла в двойной коммуникации. В то же время, взаимодействие Команды со стейкхолдерами может не ограничиваться теми, кто получает ценность от созданного продукта, это могут быть смежные и обслуживающие подразделения и команды, и задача взаимодействия с ними в целом лежит на скрам-мастере.

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

Что делать, если сильно не успели?

И в заключении стоит поговорить о том, что происходит, когда спринт окончился неудачно, и команда сильно не успела сделать запланированные работы. Тут следует явно сформулировать принцип, который я в свое время услышал от Хенрика Книберга: не бывает медленной скорости, бывает неверное планирование.

В моменте необходимо решить, что делать с задачами незавершенного спринта. Вернее, необходимо сделать заранее, когда Product Owner явно увидит из Burndown Chart и доски, что в спринте не будет завершено существенное количество задач. Это может быть видно уже в середине спринта, и точно становится явным за два-три дня до окончания. Product Owner должен оценить масштаб проблемы, и провести коммуникацию со стейкхолдерами и командой, выработать решение – на каких задачах делаем фокус, а какие – оставляем на будущие спринты. В некоторых случаях спринт может быть продлен на один-два дня, если такое решение может существенно повысить создаваемую ценность за целостности набора решенных задач.

Но в целом это – исключительная ситуация. О том, как проводить планирование и оценку, что именно поместится в спринт я буду говорить в следующей статье.

Ретро – улучшаем процесс

А в заключении этой статьи я буду говорить про Ретроспективу – встречу, на которой команда сама оценивает прошедший спринт и достижение целей и работает над улучшением процесса. Непрерывный процесс улучшений – неотъемлемая часть любого Agile-метода. Отсутствие реального ретро часто означает, что команда погрязла в самодовольстве. О проведении ретроспективы есть достаточно много книг и докладов, но в ней, наверное, наиболее сильно проявляются особенности культуры команды и компании, а я никогда на ней не фокусировался, поэтому я не готов рекомендовать конкретные книги и доклады.

Однако, я немного расскажу о полезных практиках, которые, на мой взгляд, не являются тривиальными.

Первое – это позитивное мышление им нацеленность на улучшения. Не «что было хорошо, а что плохо», а «что было хорошо, что нам мешало и как это устранить, и что можно улучшить».

Второе – вовлеченность всех членов команды. Но не стоит побуждать всех высказаться, или директивно требовать этого, люди стесняются, у них могут быть разные другие причины молчать. Так что лучше применять косвенные методы. Можно предложить каждому написать тезисы о том, что было хорошо, препятствия и идеи улучшений на стикерах и вывесить. Стикеры можно использовать разных цветов, в зависимости от вида тезиса и эмоционального отношения к ней: для позитива оценивать его вид – счастье, сюрприз и так далее; для препятствий – силу возмущения, для улучшений – накал желания. А уже потом объединить близкие идеи и обсудить по порядку: что хорошо, какие препятствия и как можно устранить, что можно улучшить. Обсуждение тоже можно начать не всем вместе, а в парах – это стимулировать высказаться всем, а не самым активным.

Третье – в результате должен быть план улучшений, в котором выделены те, которые считаем наиболее важными и берем в работу на следующий спринт. Важность стоит определять не в обсуждении, а голосованием точками. Можно оценивать не только рациональную важность, но и эмоциональное отношение к идеям, тоже какими-то смайликами.

Четвертое – идея изменений может быть сложной, и предполагать несколько шагов, как и в любой задаче, в том числе включать взаимодействие со стейкхолдерами для получения одобрения действий. А реализация может быть достаточно длительной. Их можно включать в общий список задач, или вести на отдельной Kanban-доске со своими фазами.

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

Ретроспектива требует выйти из основного потока работ и перейти из позиции специалиста, который делает работу, в позицию наблюдателя, который эту работу оценивает. И это – отдельное мыслительное усилие и действие.

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

В IT частным случаем работы с препятствиями является работа с техническим долгом. Очень часто при реализации принимаются решение о том, что необходимо быстрое частичное решение по ситуации (костыль), а полноценное будет сделано позднее. А потом сделать хорошо забывают. Об этом есть даже сленговая шутка «IT- единственное место, где на костылях быстрее, чем без них». И полноценные решения не делают, но скрытые в коде костыли несут риск. И важно уметь донести проблемы стейкхолдерам в том виде, в котором они покажутся нестерпимыми. То же относится и к другим идеям.

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

Однако, несмотря на то, что на ретро есть только члены команды, не все вопросы могут быть подняты. Если какие-то претензии и препятствия носят личный характер, люди могут их не высказывать. И вот тут начинается ответственность скрам-мастера: поговорить с людьми индивидуально, выявить проблему, а потом решить, что делать – выносить ли в какой-либо форме на ретро, или работать через индивидуальную коммуникацию.

На этом я завершаю очередную статью про схему Scrum, продолжение следует…

0
10 комментариев
Написать комментарий...
Алексей из LOADING.express

Всё отлично, но этот жирны мелькающий шрифт. Ребят, кто вас этому научил? Неудобно читать, глаз начинает дергаться.
Где скриншоты, полотно текста. 
Так хотел прочитать про Scrum, но это почти не реально. 

Поставлю в закладки и создам задачу на понедельник.))

Ответить
Развернуть ветку
Максим Цепков
Автор

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

Ответить
Развернуть ветку
Alex Agile

есть пара вопросов.

1. Agile - разве это метод ?
2. Вы пишите про то, кто участвует в демо, но полной картины так и не дали. А это очень важное мероприятие.
3. Не раскрыты полностью цели ретро, на основе чего оно строится, каки вопросы обсуждаются, из вашего изложения не понятно.

Ответить
Развернуть ветку
Максим Цепков
Автор

Отвечаю по пунктам.
1. Agile - это не метод, это зонтичная констркуция, в которой есть манифест с ценностями и принципами, и дальше семейство разных методов. Я это описывал https://vc.ru/u/364500-maksim-cepkov/96264-agile-otvet-it-na-vyzovy-cifrovogo-mira а дальше перешел к описанию Scrum. И стараюсь везде это корректно оговаривать, используя название конкретных методов, или обобщенное указание Agile-методы, или просто Agile если имею ввиду полную конструкцию. Хотя понятно, где-то могло проскочить не аккуратное употребление слова.

2. Про демо. Наверное, с моей точки зрения упущение, что я не описал подробно, что именно пишет Scrum Guide - 4-часовая встреча для одномесячного спринта и повестку дня. Но именно это люди могут там прочитать. Штука в том. что в гайде описан весьма жесткий сценарий, с повесткой дня, в который, в том числе описана подготовка бэклога к следующему этапу и жесткая договоренность о нем. А действительность оказывается гораздо более разнообразна, это не всегда можно упаковать в одну встречу. Поэтому здесь я сосредоточился на функции демо как получению обратной связи, а работа с бэклогом - следующая статья. и это - отдельная активность. И такое разделение соответствует тому, что я читал в книгах Сазерленда и Книберга, и слышал от Книберга на тренинге. Так что если бы я цитировал Scrum Guide, то я бы его еще и критиковал. А в статье для широкого ознакомления это неуместно.

3. С ретро, в общем-то тоже самое. Хотя я не цитировал дословно те три пункта, которые составляют цель ретро в Scrum Guide (Inspect how the last Sprint went with regards to people, relationships, process, and tools; Identify and order the major items that went well and potential improvements; and, Create a plan for implementing improvements to the way the Scrum Team does its work) я. с одной стороны обозначил их рамочно как "процесс непрерывных улучшений", а, с другой - раскрыл содержание важных моментов, которые часто упускают, но которые необходимы. При этом пункты из Scrum Guide туда вошли - и оценить, что плохо, а что можно улучшить, и создание плана действий. Вообще техника ретро - сложная. о ней много книг есть. и я явно оговорился, что буду говорить о практиках.

В целом я не пишу учебник, а рассказываю про Agile на практике. Учебников и так много, и они не удовлетворяют людей. Люди видят описание Sprint Review, повестку на 4-часовую встречу, понимают не реализуемость в их условиях и говорят "ну Scrum нам не подходит, и вообще он настолько жесткий, что убиться можно".

Ответить
Развернуть ветку
Alex Agile

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

Ответить
Развернуть ветку
Максим Цепков
Автор

В идеале на демо приходят стейкхолдеры и команда. Собственно, Scrum Guide примерно так и пишет: "During the Sprint Review, the Scrum Team and stakeholders collaborate ..." Дальше есть вопрос, кого считать стейкхолдерами. Я тут "по умолчанию" использую широкую трактовку: все, кого затрагивает ход проекта и потому им интересно его наблюдать и есть стейкхолдеры. И они приходят, в идеале - все или все имеющие существенное влияние.

А дальше, как вы верно замечаете, есть ситуация, когда не все существенные стейкхолдеры могут придти на демо или не могут дать фидбэк по сделанному. В этом случае необходимо создавать альтернативные механизмы, которые бы обеспечили ту же самую функцию, а не ограничиваться теми, кто есть. И это - рассматривается в статье, потому что это важно, без качественной обратной связи Scrum будет работать плохо. Механизмы могут быть разные, это зависит от конкретики проекта, и часть из них я перечислил "в цикл выполнения задачи может быть включено не только тестирование, но выкатка на боевые сервера и A/B тестирование на пользователях. Или установка его на тестовые сервера заказчика с приближенными к боевым данными, и проведение обучения и демонстрации конечным пользователям. " Если вы хотите пополнить список - замечательно. Вообще на эту тему есть много материалов и докладов...

Ответить
Развернуть ветку
Нина Агеева

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

самая важная (для меня) цель ретры - это возможность раскопать проблемы, которые, как правило, не видны, ну и, конечно, как следствие - составить список задач, осмартовать и взяться за улучшения! однако, тут есть и косяки

самый косяк этого инструмента (опять же, для меня) - это то, что из людей порой и клещами не вытянуть проблемы, и так, и эдак, и с бубном поплясал, не делятся, а потом обижаются, что менеджеры мысли не читают и не помогают)) если у коллег есть способы "разговорить" команды - поделитесь. пожалуйста!

спасибо за статью!

Ответить
Развернуть ветку
Максим Цепков
Автор

Я слышал несколько интересных приемчиков, которые укладываются в общую схему: сначала приводишь к признанию, что проблем нет, а потом ставишь вызов. И или команда его принимает, или начинает выкладывать проблемы. Например, "а, вот есть у нас фича, очень нужная заказчику, хоть и прилетела в середине спринта - что надо изменить, чтобы мы срочные вещи могли брать?" или "а вот у нас же косяк вылез из-за нестандартного использования софта, которое мы не закрыли, и мы его много часов разгребали - что надо сделать, чтобы мы гарантировали, что такое не повторилось"? Примеры надо подбирать соответствующие тому, куда мы хотим команду сдвинуть, то есть если проблема в скорости - то одни, а если в качестве - то другие. 

Вообще в идеальном agile менеджеры - не должны помогать, команда сама организуется и решает проблемы. Все, и внешние и внутренние. И поэтому ретро считается внутренним мероприятием.

Дальше есть два направления.

1) Можно посмотреть доклады про ретро (я слушал много на AgileDays, SQAdays, AnalystDays и других), и в части из них еще и список литературы хороший. Про ретро много книг (я знаю, но сам - не читал, увы). Или, кстати, из смежных областей, потому что ретро - частный случай post mortem analysis, это одна из практик управления знаниями.

2) Можно копать методы выяснения проблем с погружением по системным уровням. Для начала берем статистику, каждый конкретный случай - случайность, но надо менять систему. И дальше - root cause analysis или системный анализ с погружением на уровни. А со статистикой есть интересная работа в Канбан - строишь спектральную диаграмму выполнения задач и, например, видишь длинный хвост (в среднем с багом справляемся за пару часов, максимум день, но есть которые неделю требуют) - и именно с ними разбираешься, анализ применяется не только к багам.

Очень рад, что статья вызвала отклик, пишите!

Ответить
Развернуть ветку
Нина Агеева

Максим, привет! довольно редко встречаются чистые и идеальные модели и техники) вы говорите, менеджеры не должны помогать, но большинство людей не готовы самостоятельно признать, раскопать и придумать пути решения проблем, куда проще умолчать, авось и так сойдет)
спасибо за рекомендации!

Ответить
Развернуть ветку
Максим Цепков
Автор

Нина, привет! Да, чистое следование модели действительно встречается редко. Но на то это и идеал, чтобы мерить дистанцию и понимать, чем за нее платим. В идеальном Scrum взяли коучинговую практику - Agile-коуч помогает решать проблемы, но действует только по запросу, и должен постепенно уменьшать действия по своей инициативе, и работает через проблематизацию, а не через предложение решения. А чтобы усилить проблематизацию и инициировать обращение внутри команды есть Scrum master. И все это может замедлять непосредственное решение проблем, зато способствует росту самостоятельности и самоорганизации команды, что вдолгую является более выигрышным.

Чистый Scrum встречается редко, но с ним интересно сопоставлять свою модель, смотреть различия и понимать всякие компенсаторные механизмы (так не делаем, зато делаем это). И на практике каждый раз идет поиск баланса между коучингом и прямой помощью, это понятно..

Ответить
Развернуть ветку
7 комментариев
Раскрывать всегда