Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!
Хочешь читать реальные кейсы про российский бизнес? Жми сюда!

Большоеинтервьюо фиче-командахв ДодоПицце

Антон Бевзюк, Chief Agile Officer и Скрам-мастер Додо Пиццы, рассказал о том, как в компании создавали фиче-команды, какие были сложности и что из этого вышло.

Расскажите, в Додо Пицце сразу использовались гибкие подходы к работе или сначала более традиционные?

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

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

Примерно два года назад наша компания Smart Step Group присоединилась к Додо, появилось несколько команд, и мы начали устанавливать формальный процесс, опираясь на Скрам и Экстремальное Программирование. Сейчас у нас более десяти команд и мы используем LeSS — Скрам для нескольких команд. Дальше будем развиваться к LeSS Huge.

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

Кто в компании принял решение о необходимости изменений?

Идея моя. Она родилась не на пустом месте: мы достаточно выросли, появилось 3-4 команды и стало понятно, что обычный Скрам нам больше не подходит. Я сходил на тренинг Сезарио Рамоса по LeSS, и у меня сложилась картинка, я понял, куда надо двигаться. На тренинге в том числе рассказывали о фиче-командах, с этой идеей я пришел в компанию и продвигал ее. Не все в Додо Пицце восприняли это с восторгом, однако нашлись согласные попробовать и поставить эксперимент на себе.

Не все были готовы к изменениям. Расскажите подробнее, как это выражалось и как вы с этим справились?

Люди так устроены, они всегда встречают новое с осторожностью и опасениями, потому что не понимают, какую пользу это может дать. Приходишь с тренинга, и все думают, что ты принес пустую теорию, которая не соответствует нашей специфике, к нам не относится и неприменима. А я верил, что это нам подходит. На тренинге меня убедили приведенные там примеры и люди, которые сами применяют Скрам и LeSS.

Тогда наш Владелец Продукта не имел опыта работы с Аджайлом, придерживался  классического менеджмента. Его приходилось убеждать, что команда должна быть гибкой. Сработал стереотип, что люди, которые сфокусированы на какой-то одной технологии или компоненте системы, становятся экспертами. А мы говорили, что команды могут работать с любой частью продукта и с любым кодом.

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

Фрагмент презентации Антона о фиче-командах для конференции #AgileDays.

Это значит, что каждый может взять задачи каждого?

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

Сколько ушло времени на налаживание работы команды? Дальше было легче, или каждая новая команда требует тех же усилий?

Со Скрамом внутри одной команды было все понятно, мы его давно построили. А вот организовать работу нескольких команд над одним продуктом — это действительно сложная задача. Начали с одной команды, сделали из нее фиче-команду за 3-4 месяца. Я работал внутри команды как коуч, сидел с разработчиками, программировали в паре, бизнесу помогал декомпозировать задачи. Когда понял, что первая команда может работать самостоятельно, ушел в другую.

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

С чем было связано то, что команда не сложилась?

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

Человеческий фактор повлиял?

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

Какие у вас были эмоции во время изменений?

Сначала было волнующее предвкушение. Я понимал, что в России мы одни из первых, кто наладил качественный аджайловый процесс. У нас был не просто Скрам — хотя и таких пока мало — мы строили LeSS. Я чувствовал, что мы пионеры, и это вдохновляло.

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

Отзыв Андрея Толмачева (PST, Unusual Concepts) о Спринт Ревью в Додо Пицце.

Потом пришло равновесие и уверенность — мы все делаем правильно. В последнее время мы уверены в себе, приглашаем гостей на Спринт Ревью, и они нас благодарят. Это заряжает энергией и дает силы идти дальше. Наш путь в LeSS вдохновляет другие компании, это здорово.

Сначала вдохновиться самим, потом вдохновлять других 🙂 Расскажите, когда появились первые результаты от использования фреймворка?

Первые результаты были уже через два месяца, еще в процессе формирования первой команды. Вначале ребята не верили, что успеют за три месяца сделать фичу, а это было необходимо — открывалась новая пиццерия в Штатах с рестораном, там люди привыкли к возможности кастомизации пиццы и ожидали такой функции от нас. Когда ребята через два месяца запустили MVP функционала в Америке, они поверили в себя. Главным результатом можно считать то, что всем стало понятно: мы реально приносим ценность бизнесу, это работает! Мы ежедневно общались с Аленой, нашим американским партнером: показывали промежуточные варианты, переделывали. И первая «своя» пицца для Алены была сделана уже через два месяца. А еще через месяц был полностью готов весь функционал для пиццерии.

Еще немного про команды. Получается, вы сначала участвовали как коуч, затем оставался Скрам-мастер и команда на самоуправлении?

Да. Я считаю, что критерий успеха коуча — самостоятельность команды. Если при нем все работает, а без него разваливается — это плохой коуч. А если после моего ухода команда работает и развивается, значит, все сделано правильно, это успех. Хотя я ушел из команды, иногда заглядываю в гости, чтобы узнать, что новенького они придумали. Например, они решили, что в команде нужна ротация фасилитаторов. В другой раз они определили, каких инженерных практик им не хватает, и начали прокачивать свои навыки. Команда растет сама. Мы в контакте со Скрам-мастером, но больших вмешательств уже не требуется.

Большие планы Додо Пиццы

Расскажите о ваших планах на будущее

У нас план вырасти за два года в пять раз. С 50 разработчиков до 250. Это будет уже LeSS Huge, порядка 50 команд. Это сложная задача, я думаю, мы будем первыми, кто это сделает в России.

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

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

Если бы вы сейчас вернулись в начало своего пути, каким бы стал ваш совет для самого себя — тогда?

Я бы точно сказал себе: «Ты веришь в то, что ты делаешь? Продолжай это делать». Уверенность заражает и заряжает других людей. Еще сказал бы: «Отдавайся своему делу полностью,  на 100%». Я сейчас понимаю, что были моменты расфокуса, когда я слишком многого хотел. Лучше брать одну задачу и решать ее, а не пытаться сделать все и сразу правильно, на всех фронтах и на всех уровнях. Сначала убедись, что получилось сделать команду на 100%,  и только тогда переходи к следующей.

Автор текста: Марина Сухова

Люба Мамаева Редактор Unusual Concepts

Поделиться
Вотсапнуть
Отправить
Ещё по теме
Студент Unusual Concepts делится ценными советами по сдаче экзамена PSM и PSPO 1. Цена попытки — 200$, но лучше сходить на тренинг Unusual Concepts. Рекомендую! Выйдет в четыре раза дороже, но оно того стоит. 2. Внимательно и вдумчиво изучить scrum guide на английском (!) языке. Что угодно делайте, чтобы понять и запомнить всё, что там написано. Мне лично помогло рисовать mind maps. Кому-то помогает внимательно прочесть 3 раза. 3. Пройти open assessments на сайте scrum.org (open, product owner, developer). Nexus не надо. Здесь задача в том, чтобы понять логику того, кто эти тесты делал (эта же самая логика используется и в сертификационном экзамене). Проходить советую вдумчиво, читая то, что написано. Не советую тупо запоминать вопросы и ответы на них, т.к. хотя в экзамене и есть copy-paste из open assessment, их, во-первых, всего лишь около половины, а во-вторых, это вам только помешает понять суть. Из этих же соображений советую тренироваться по одной попытке на каждый open assessment и потом перерыв. Потом опять по одной на каждый и опять перерыв. Идеально, если чередовать с изучением scrum guide. Обязательно читаем результаты теста! Там годные комментарии к ответам. Добивайтесь устойчивого 100% результата. 4. Если у вас с английским языком проблемы — то советую подтянуть. Лучший способ, на мой взгляд, делать всё, что я тут описал, но со словарём. Добиваемся, чтобы весь scrum guide и все open assessments были понятны без словаря. Во время экзамена словарь держите под рукой — попадаются непонятные слова, но целиком полагаться на него не стоит (один товарищ пытался загонять все вопросы в он-лайн переводчик, и в результате получил 53% правильных ответов). 5. Сертификационный экзамен сдаётся на сайте scrum.org, где другой интерфейс, чем у тестовых экзаменов. Это может добавить мандража, если станет неожиданностью. Но существенных отличий там нет. Разве только можно закладки ставить. 6. Перед сдачей самого экзамена убеждаемся, что у нас есть час времени, когда точно никто не будет отвлекать и интернет точно не отвалится. Я перестраховывался 3g модемом, но, слава Богу, не пришлось. 7. Во время экзамена ни в коем случае не надо париться над сложными вопросами! Если вопрос сложный, то выбирайте то, что вам кажется верным, ставьте на вопрос закладку (bookmark) и идите дальше. Большинство вопросов (около 60 из 80), при условии что всё вышеописанное вами сделано добросовестно, вы отобъёте за 30 минут. Оставшиеся 30 минут можно потратить, чтобы внимательно и вдумчиво разобрать все закладки. У меня даже получалось в интернете поискать варианты в это время. 8. Не надо ставить закладку на все вопросы, в которых у вас есть сомнения. Ставьте закладку только там, где вы вообще не уверены. Иначе получится неприятная картинка, когда сначала вы закладки ставили на средне-сложные вопросы, а потом стали ставить только на очень сложные, и в результате под конец теста у вас не 20 закладок, а 40, и времени в обрез. 9. Помните — это экзамен. Не надо быть самоуверенным, а то завалить его проще простого. Но и мандражить сильно не надо. Просто тщательно подготовьтесь, и всё будет хорошо. Оригинал поста в Фейсбуке
Андрей Толмачев рассказывает, как разрешить взаимное недовольство Владельца Продукта и Команды Разработки.

Условия задачи

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

Что происходит

Для каждого элемента Бэклога Продукта аналитика, разработка и тестирование попадают в отдельные Спринты — это означает, что элемент будет готов к выпуску только через три Спринта. В таком случае истинная длина Спринта равна шести неделям — это больше, чем допускает Руководство по Скраму.
Максимальная продолжительность Спринта — один календарный месяц. При большем сроке планирования возможны изменения целей, увеличение сложности и рост рисков.
Руководство по Скраму Когда Команда редко поставляет готовый Инкремент, то редко получает обратную связь от стейкхолдеров и клиентов. В результате:
  • возрастает риск сделать не то, что надо. Способность реагировать на изменения падает;
  • стабильность процесса падает, прогнозировать работу сложно. Например, тестирование выявляет дефекты через недели после разработки. Баги обнаруживаются поздно, поэтому объём «поддержки» будет меняться от Спринта к Спринту;
  • рабочий процесс перестаёт быть прозрачным.
По этим причинам Команда Разработки теряет доверие Владельца Продукта и стейкхолдеров, следовательно, давление возрастает и начинаются конфликты.

Решение

Скрам-мастер не может решить проблему самостоятельно, но может помочь своей Команде следующим образом:
  • объяснить описанную выше системную динамику и её вредные последствия. Скрам-команда должна понимать, что правило Скрама про Done Increment каждый Спринт — это естественное системное решение их проблемы;
  • помочь сформулировать или пересмотреть минимальный DoD, который может быть выполнен в течение Спринта и который обеспечит готовность Инкремента к релизу;
  • научить Команду Разработки правильно декомпозировать элементы Бэклога. Небольшие элементы в Бэклоге Продукта способствуют ранней поставке, оптимизации ценности Продукта и улучшению потока работы;
  • помочь договориться взять в следующий Спринт хотя бы один небольшой элемент Бэклога, но довести его до состояния Done;
  • визуализировать поток работы. Прозрачность — залог успеха;
  • устранить простои в работе. Для этого Скрам-мастер обучает Команду хорошим инженерным практикам, например, общему владению кодом, стимулирует развитие T-shaped или E-shaped людей в Команде, заключает командные соглашения;
  • объяснить Владельцу Продукта, что причина задержек — технический долг и убедить его выплатить.
Используйте Ретроспективу, чтобы найти лучшие решения по устранению препятствий. Помните, что эти решения — эксперименты, не факт, что они принесут ожидаемый эффект. Поэтому инспектируйте результаты прошлых решений и адаптируйте решения на следующих Ретроспективах.

Итоги

Готовый Инкремент в конце Спринта — это важнейшие правило Скрама, которое помогает избежать роста рисков, потери предсказуемости и гибкости. Описанные причинно-следственные связи полезно знать, чтобы понимать, почему Скрам требует соответствующий DoD, готовый к релизу Инкремент каждый Спринт. Следующие действия могут помочь в достижении этой цели:
  • декомпозиция работы на небольшие PBI;
  • визуализация потока работы в Спринте и поиск основных узких мест;
  • устранение «простоев» работы с помощью командных соглашений, хороших инженерных практик и развития T-shaped или Е-shaped людей;
  • планомерная ликвидация технического долга.
Комментарии
Подпишитесь на нас:
Телеграм Группа в фейсбуке