Обновленный отчет: испытание методологии Basecamp «Shape Up»

В прошлом году я попытался перевести свою продуктовую команду с классического подхода SCRUM на методологию Basecamp Shape Up. Это был невероятный опыт; Я многому научился благодаря этому и решил поделиться с вами некоторыми из своих выводов.

Если вы сами экспериментировали с этим, мне бы хотелось услышать, как все прошло. Если нет, мне бы хотелось услышать, почему вы остались в стороне.

Часть 1: Зачем совершенствоваться?

Моя команда всегда работала по SCRUM. В дни нашего стартапа мы жили по классическим технологическим циклам: работайте быстро, отправляйте продукт и не слишком много думайте о процессах. Затем нас приобрели.

Когда у меня появилось немного больше времени на обдумывание вариантов методологии нашего продукта, я решил попробовать Shape Up. Причин было несколько:

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

   
   

2. Команда чувствовала себя кодовыми обезьянами. Выбрать билет. Рабочий билет. Доставить билет.

   
   

3. Поскольку мы никогда не завершали спринт, задачи всегда переносились на следующий. В конце концов плотину прорывает.

   
   

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

   
   

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

   
   

6. Почти никакого понимания клиента. Разработчики получали назначенные билеты, выполняли их и понятия не имели, почему/кто/что.

После перечитывания Формирование Basecamp Я подумал, что попробую, поскольку он утверждает, что решает большинство этих проблем.

Часть 2: Внутренняя питчинг

Одной из самых сложных частей перехода в Shape Up было внутреннее продвижение идеи.

Я потратил дополнительное время на усвоение большинства концепций Shape Up, чтобы быть готовым к любым вопросам. Неудивительно, что разработчикам понравилась идея этого нового подхода (больше времени, больше внимания, больше сотрудничества; почему бы и нет!).

Также неудивительно, что иерархия была более сдержанной. В конечном итоге мне удалось убедить их:

1. Убедившись, что это было всего лишь испытание. Если что-то пойдёт не так, мы вернёмся к «нормальному состоянию».

   
   

2. Убедившись, что я останусь таким же доступным, как всегда, чтобы помочь им. Разработчики были бы сосредоточены и непрерывны, но я — нет.

   
   

3. Подчеркивая «Shape Up», мы можем решать более серьезные проблемы, а это означает большие возможности.

   
   

4. Настаивающие о боли, которую испытывает в данный момент продукт, и о том, как она влияет на каждую команду.

Я подготовил очень четкую презентацию и провел ее по каждому руководителю отдела (обслуживание клиентов, продажи и высшее руководство).

Часть 3: Страхи и опасения

Мой опыт основателя, маркетолога и менеджера по продукту научил меня, что всегда стоит записывать проблемы, прежде чем начинать эксперимент. У меня было несколько с Shape Up:

• Как мы справляемся с отвлекающими факторами? Я знаю, что должен сказать «нет». 'Были заняты.' «В следующем цикле мы сможем заняться этим». Это теория, и она работает, если вся компания придерживается этой методологии. Во время моего первого испытания на цикле я боялся, что может возникнуть чрезвычайная ситуация.

• Отставания? Shape Up рекомендует избегать отставаний (глава 7). Поскольку мы только тестировали это, я, очевидно, не пошел и не удалил наш отставание с помощью cmd+a+delete, но все же. Если бы мы приняли эту методологию, я бы чувствовал себя несколько потерянным без отставания.

• 'Практически завершенный.' Это меня действительно напугало. Что произойдет, если мы достигнем конца 6-недельного цикла и приблизимся к нему, но не совсем? Basecamp говорит: «Начни заново» (если только вы не очень близки). Я боялся, что мы промахнемся в раздражающем диапазоне 20–30%.

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

Часть 4: Цикл

И мы поехали!

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

• Неделя 1 : Начало и... тишина. Оставить команду в покое, дать ей возможность исследовать код и погрузиться в код в свободное время — это основная часть этой методологии. В ту первую неделю мне было невероятно трудно расслабиться и не спрашивать обновлений. Я держался крепко!

• Неделя 2 : Команда наконец вышла из своей скорлупы. Связь наладилась. Начал появляться дизайн для работы, осталось дать отзыв и поработать вместе.

• Неделя 3 : Теоретически третья неделя должна быть вершиной кривой цикла. К концу у команды должно быть очень хорошее представление о том, как они собираются построить то, что нужно построить. Мы создали специальный канал Slack для каждого цикла, когда общение стало набирать обороты. К концу недели мы увидели прототипы, проекты, фрагменты кода и многое другое. Мы были на правильном пути!

• Неделя 4 : Снова тихо. Вся эта неделя, начиная с третьей недели, привела к целенаправленной неделе, когда каждый выполнял свою работу. Мы начали пятничное шоу «покажи и расскажи».

• Неделя 5 : Неделя Curveball. Один из прицелов начал издавать довольно много шума. Быстро стало ясно, что сфера применения недостаточно ясна. Я не был достаточно точен в своих требованиях, и то, что поначалу казалось красивым и простым, оказалось сложным. Мне пришлось принять трудное решение сократить этот объем.

• Неделя 6 : Остальные прицелы работали хорошо. Интенсивность резко возросла на шестой неделе, когда я повсюду проводил контроль качества, а разработчики невероятно быстро обрабатывали мои отзывы; мы все объединились, чтобы достичь цели.

  
  

В итоге мы попали в цель. Мы сделали это! Это было очень напряженно, и я был опустошен, что нам пришлось отрезать один из прицелов, но мы справились.

В следующий понедельник в 10 утра мы приступили к производству.

Часть 5: Несколько уроков

Вот несколько уроков и рекомендаций в произвольном порядке:

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

   
   

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

   
   

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

   
   

4. Интенсивность распределена неравномерно . Будь то между членами команды или на протяжении всего цикла, интенсивность работы будет сильно различаться. Ваша роль как премьер-министра — выявлять эти очаги напряженности и уделять особое внимание людям, которые через них проходят.

   
   

5. Создайте отдельный канал Slack . Это сделало общение намного проще, но и намного веселее. Команда цикла быстро разработала общий язык, мемы, связанные с работой, над которой мы работали, и так далее. По сути, это было похоже на стартап внутри команды.

   
   

6. Проводите встречи «покажи и расскажи» с первой недели . Мы слишком долго ждали, чтобы сделать это. К концу первой недели должно быть достаточно вещей, которые можно показать или обсудить. Это также возможность встретиться, обсудить, поучиться и т. д.

   
   

7. Период восстановления оказался намного сложнее, чем сам цикл . Вся «остальная работа» накопилась за 6 недель; мне казалось, что я снова возвращаюсь к SCRUM. Это то, над чем я все еще работаю.

Как вы, наверное, заметили, этот суд меня подкупил.

Внедрение Shape Up и принятие его особенностей — это, конечно, не однодневное дело. Я подозреваю, что это будет долгий процесс обучения. Я особенно ценю сдвиг в мышлении, который позволил нам это испытание. Мы (и, надеюсь, другие команды) научились видеть работу такой, какая она есть: захватывающая задача, которую мы преодолеем вместе.

Если вы пробовали это (или нет), мне бы хотелось прочитать несколько историй или отзывов!

Если вам понравился этот пост, возможно, вам понравится моя рассылка . Я пишу об управлении продуктами, делюсь практическими идеями и ради развлечения решаю реальные задачи, связанные с продуктом (я знаю, верно?).