От 1 часа до 2,5 длинных скрамов каждый день — это безумие?

Ничто из того, что вы описали, не является скрамом.

1. В Scrum нет описанных вами ролей.

2. Кажется, у вас нет двух основных ролей для Scrum — владельца продукта и Scrum-мастера.

3. В Scrum все не может быть главным приоритетом. Владелец продукта создает упорядоченный список. Команда разработчиков работает над ними именно в таком порядке.

4. В Scrum нет статусных совещаний. Ежедневный Скрам — это 15-минутное мероприятие, организованное Командой Разработки для координации своей работы.

Непонятно, почему вы пометили его Scrum. Пожалуйста, обратитесь к Руководству по Scrum .

Какие звонки вы бы сделали? Какие решения вы бы приняли?

Однако, если вы хотите практиковать Scrum, вы можете начать с отправки нескольких человек на обучение Scrum. Ваша команда слишком велика, чтобы быть одной Scrum-командой. Вы можете разделить его на две Scrum-команды. Вы можете назначить Scrum Master и Product Owner для команд. При необходимости команды могут использовать одного и того же Скрам-мастера и/или владельца продукта.

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

Это не Scrum... как бы вы лучше всего это улучшили?

Я бы предпринял два немедленных шага, чтобы улучшить это:

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

2. Найдите способ расставить приоритеты в проектах : если руководство говорит, что «все является главным приоритетом», на самом деле они говорят, что ничто не является приоритетным. Когда вы назначаете один из проектов «высшим приоритетом», вы говорите: «Сначала назначьте ресурсы этому проекту, а если какие-либо ресурсы останутся, назначьте их другим проектам». Если «все является главным приоритетом», то все проекты будут испытывать нехватку ресурсов. На самом деле больше ресурсов будет потрачено впустую при переключении контекста.

Я думаю, что дилемма Scrum против не Scrum - это проблема второго этапа, вы должны сначала заняться самыми важными вещами, которые, ИМХО, таковы:

1. Все является высшим приоритетом, что также означает, что ничто не имеет приоритета, что также означает, что у вас нет никакого приоритета (или, что более вероятно, ваши приоритеты являются результатом антагонистических факторов/интересов, что затрудняет управление). Это первое, что вы должны решить, если у вас нет идеи о том, куда вы должны инвестировать, будет очень трудно узнать, как это сделать .
2. Вы получили 8 проектов на 10 человек + 3 менеджера. Я не знаю, как вы оказались в такой конфигурации, но, возможно, вы (как компания, я имею в виду) можете изучить другие способы управления вашей системой разработки. Я могу ошибаться, но, может быть, 1 час * 5 дней * 13 человек = 65 часов в неделю, потраченных на координацию для такой маленькой команды, это слишком много...

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

Как отмечали другие, это ни в коей мере не Скрам.

Как это исправить?

Я нашел самый простой способ сократить количество ненужных совещаний, подобных этим, — количественно оценить их стоимость.

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

Используйте получившееся БОЛЬШОЕ ЧИСЛО, чтобы взять назад и сказать, что эти встречи стоят X долларов в неделю, XX долларов в месяц, XXX долларов в год в виде прямых затрат, не говоря уже о потерях производительности, связанных с другими делами. Используйте это как оправдание для сокращения продолжительности, частоты и посещаемости собраний.

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

От 1 часа до 2,5 длинных скрамов каждый день — это безумие?

Это не просто сумасшествие, это неправильно. Именно такую ​​ситуацию и призван предотвратить Scrum. Если вы проводите 1-часовую (не говоря уже о 2,5) ежедневную встречу, вы делаете это неправильно.

Менеджмент требует, чтобы вся команда оставалась и слушала.

Первым шагом в решении проблемы является признание проблемы. Обсудите это с менеджером — один на один, вероятно, лучше всего здесь, чтобы вы могли свободно говорить, и ему не нужно было отвечать перед всей командой. Если вы укажете на стоимость этих долгих совещаний (от 65 до 160 человеко-часов в неделю) и потенциал повышения производительности и морального духа, вы, вероятно, получите много согласия.

Какие решения вы бы приняли?

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

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

• Что они закончили?
• Что они ожидают закончить к следующему ежедневному собранию?
• Что, если что, мешает им что-то сделать?

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

Еще одна цель должна заключаться в том, чтобы каждый спринт был немного лучше предыдущего. Чтобы способствовать этому, Scrum включает «ретроспективу спринта». Это возможность для любого члена команды предложить улучшения процесса, но это не бесплатный способ выразить разочарование. У собрания должна быть повестка дня, в которую может внести свой вклад любой член команды — для этого хорошо подходит вики-страница — и лицо, ведущее собрание (не менеджер), должно придерживаться повестки дня и следить за ходом дела. После объяснения каждого предложенного изменения позвольте команде проголосовать за то, пробовать его или нет, и сделать пометку для следующей ретроспективной встречи, чтобы обсудить, помогло ли изменение и следует ли его продолжить.

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

То, что вы описываете, очень далеко от Scrum. Тем не менее, среда Scrum предлагает вам некоторые рекомендации, которые могут вам помочь.

В Scrum мы ограничиваем размер команды до 9 человек. Это сделано потому, что есть много исследований, которые показывают, что общение в команде больше 9 человек становится слишком накладным.

Scrum также ограничивает ежедневные стендапы Scrum максимум 15 минутами. Причина, по которой команда выступает на собрании, заключается в том, что это способствует целенаправленному и эффективному разговору. Стоит отметить, что ежедневный Scrum — это синхронизация внутри команды, а не отчет о прогрессе. Если подумать, собрать всю команду на совещании стоит много потерянного рабочего времени. Поэтому важно, чтобы ежедневный Scrum был эффективным и охватывал темы, затрагивающие всю команду. Когда поднимается тема, которая не касается всех, она должна быть вынесена за пределы ежедневного Scrum и обсуждаться только теми, на кого она влияет.

Scrum также подчеркивает важность расстановки приоритетов. Исследования показали, что чем больше задач выполняет человек параллельно, тем менее эффективен он. Хорошая расстановка приоритетов позволит членам команды работать целенаправленно и эффективно.

Как бы вы посоветовали подходящие альтернативы, чтобы убедиться, что задачи спринта не отпадают на второй план?

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

Вы допустили одну ошибку в организации с командой.

На мой взгляд, вам нужны следующие вещи:

• должны разбить требования, создать задачу, оценить и распределить их. Другими словами, это означает, что вы должны создать Бэклог Спринта (с владельцем продукта и инвестором).

• должны выполнить короткую ежедневную встречу спринта.

• должны гарантировать, что в конце Спринта будет реализована потенциально поставляемая функциональность.

• должны обновить статус и оставшиеся усилия для своих задач, чтобы можно было создать диаграмму выгорания спринта (диаграмма выгорания спринта очень важна)

Похоже, вы описываете встречи, а не схватки.

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

Менее 10 минут с подведением итогов выполненных дел/обновлений и фиксацией задач текущего дня; выполняется каждым человеком в команде.

Я думаю, что, возможно, встречи по планированию и встречи по обзору историй — это ваши одночасовые встречи.

Я использовал следующий документ «Четырнадцать наблюдений за хорошей практикой Scrum» с успехом, надеюсь, вы сделаете также: http://lookforwardconsulting.com/wp-content/uploads/2011/01/ScrumObservations.pdf

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

Наблюдение-1: Спринт принадлежит команде разработчиков, и SM должен обеспечить защиту команды во время спринта от вмешательства руководства, которое может негативно повлиять на спринт.

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

Наблюдение-3: Бэклог продукта принадлежит и ранжируется владельцем продукта. Другой член команды может предлагать функции для добавления, но последнее слово остается за PO.

Наблюдение-4: Команда несет ответственность за свои собственные обязательства и должна брать на себя только те обязательства, которые, по их мнению, они действительно собираются выполнить.

Наблюдение-5: PO может установить приоритеты для команды.

Наблюдение-6: Мастер Scrum не имеет власти над деятельностью команды. SM — это тот, кто обладает экспертными знаниями о структуре Scrum.

Наблюдение-7: Планирование спринта — это то, какую PBI команда создаст и как команда собирается ее построить.

Наблюдение-8: Бэклог спринта, которым владеет и обслуживает команда разработчиков.

Наблюдение-9: Ежедневное собрание по схватке — это встреча с ограничением по времени максимум до 15 минут, на которой команда разработчиков пользуется возможностью, чтобы синхронизировать свою деятельность и ответить на три вопроса: что вы делали вчера, что вы будете делать сегодня и любые препятствия, которые могут возникнуть. другие члены команды могут решить. SM будет способствовать встрече.

Наблюдение-10: обзор спринта, настало время для команды проявить себя и представить PO инкремент спринта. Может быть продемонстрирован только демонстрационный прирост.

Наблюдение-11: Ретроспектива — это время, когда команда может подумать о том, как они могут улучшить свою работу.

Наблюдение-12: заинтересованные стороны не имеют прямой власти над командой, и SM должен защищать команду, если взаимодействие с заинтересованными сторонами считается отвлекающим фактором.

Наблюдение-13: если PO решит завершить спринт, он должен организовать совещание по завершению с командой, чтобы сообщить команде, что стоит за отменой, и команда должна выработать ключевые моменты, которые должны быть доведены до сведения заинтересованных сторон.

Пожалуйста, проверьте файл pdf для получения дополнительной информации.