Заходя в новую компанию

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

Если большинство современных компаний уже отошли от водопада и страдают больше code and fix, то здесь его можно наблюдать в полной мере. В силу некоторых обстоятельств, называть компанию я не буду, но намекну, что это ИТ и финтех, с большой и сложной структурой команд и продуктов. Ну а кто в финтехе простой? 🙂

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

Первые шаги

  1. Познакомиться
    • С компанией. И здесь я имею ввиду не только свои команды, с которыми буду работать, а вообще со всеми, от которых у тебя могут быть внешние зависимости. Важно на первом этапе понять, сколько их может быть, кто из них более непонятный, кто идет на контакт, а кто нет. Сколько вообще здесь уровней иерархии и как ходит информация. Scrum ведь это про общение и взаимодействие.
    • С командой. Буду проводить первое ретро для них. Пока ретроспективы у них были раз в месяц и не привязаны к спринтам. Мы это исправим. На этой встрече я расскажу им о себе и чем буду заниматься. Потому что пока никто не понимает, кто я, зачем я здесь, но все уже меня так долго ждали 🙂
  2. Договориться со всеми, кто хочет завести в компании Scrum и Agile. Пока ты человек снаружи, тебе не все говорят, как есть на самом деле. Когда ты становишься человеком изнутри, делятся более охотно. Эта работа поможет мне лучше понять полный объем работ и то, как действительно обстоят дела. Историю Agile и Scrum в организации, ведь я не в первый раз слышу, что мы это уже делали 3 раза..
  3. Обучить. Рассказать об Agile, из чего состоит Scrum и в чем тонкости.

Что ждет дальше?

Помимо этого, очень хочется собрать свою команду трансформации, которая будет помогать двигать процесс вперед. Этого я никогда не делала, но видимо пора.

Сразу после обучения соберемся, обсудим как кто видит этот процесс и все вместе сделаем Impact Mapping трансформации. Подумаем над стратегией изменения.

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

Advertisements

Что для меня означает гибкость?

Некоторое время назад один знакомый в твиттере пошутил, что я знаю эту картинку наизусть 🙂

cyjbctgxcaehqi8
Полную можно посмотреть здесь

Я заинтересовалась, потому что очень люблю инфографику за ее лаконичность и наглядность. Особенно по теме, которой занимаюсь. И я нашла презентацию Chris Webb из компании Deloitte, которая разработала это изображение.

Agile landscape

Ребята хотели рассказать о всех фреймворках и инструментариях, которые находятся под зонтиком Agile и для чего они нужны. Эту развертку они назвали Agile landscape. Называется, найди здесь себя 🙂

%d0%b1%d0%b5%d0%b7%d1%8b%d0%bc%d1%8f%d0%bd%d0%bd%d1%8b%d0%b9

Doing Agile vs. Being Agile

Исследовав своих клиентов они выяснили, что только 8% из них являются жесткими приверженцами водопада, 24% используют гибридную модель, а остальные пользуются Agile инструментами. Сравнивая гибкие фреймворки по популярности выяснилось, что инструменты scrum-а используется чаще всего:

  • daily standup
  • product backlog
  • retrospectives
  • short iterations
  • planning

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

Другая проблема в том, что существует множество фреймворков. Не смотря на то, что самый известные из них пока scrum, это не отменяет того факта, что из них нужно выбирать наиболее для вас подходящий. Scrum помогает быстро доставлять ценность до потребителя. Если вам нужно навести порядок с релизами и стабилизировать их, то хорошо подойдут практики DevOps. Если проблемы с поиском новых идей и решений, то можно воспользоваться Design Thinking. Если продукт очень сложный и над ним трудятся сразу несколько больших команд, то используйте SAFe. Это лишь малый перечень того, что есть под зонтиком Agile.

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

Полная презентация:

PS: Подзадержалась я с этой заметкой. Уже 4 месяц публикую, надо уже положить этому конец 🙂

Anti agile manifesto

Недавно наткнулась на целое анти agile сообщество. Эти люди пишут статьи о том, что подобный подход погубит ваш бизнес. Обсуждают в интернетах, какой scrum несовершенный фреймворк и как на нас agile-коучи зарабатывают деньги. А где-то даже существует целый agni agile manifesto.. Причина, по которой образовалось это сообщество, понятна – начали внедрять, не получилось и все сломалось. Винят в этом, конечно же сам подход. Ниже я хочу рассмотреть несколько ошибок, которые к этому могут привести.

Применение там, где нужен waterfall

Не секрет, что scrum хорош для одного, а классический waterfall для другого. И конечно, нельзя отрицать того, что waterfall жил, жив и будет жить. Если пытаться забивать гвозди микроскопом – это тоже получится, просто не так эффективно, как молотком.

Давайте сравним эти два подхода при выпуске новых продуктов

 

Waterfall

Scrum

О чем это?

О проектах, как их выполнять в срок и бюджет

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

Когда получаешь результат и можешь окупить затраты?

 В конце проекта

Периодически, через равный промежуток времени

О бюджетах

Как правило, превышается

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

О скорости

Сложно спрогнозировать

Скорость ясна и прогнозируема

Заказчик доволен?

Как правило, нет

Как правило, да

Кто принимает решение, как делать продукт?

Тот, кто сверху в иерархии, например, главный архитектор или teamleader

Команда

Как добывается дополнительная информация?

Через менеджера проекта, который в свое время пообщался с заказчиком

Командой напрямую у product owner, stakeholder

Нужно ли ТЗ и документация?

 Да

 Нет

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

Если же у вас новый продукт, совершенно не ясно что зацепит пользователя и даже его потребности до конца не ясны, лучше scrum.

Команда не разделяет ценности Agile

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

Есть замечательная матрица 2*2, которая предлагает посмотреть на каждого человека с точки зрения наличия определенных компетенций и agile-ценностей. Там всего 4 состояния:img_2801

  1. Нет ценностей и нет компетенций: нужно растить таких людей и
    подавать ценности под нужным соусом. Человек переходит в пункт 2.
  2. Есть ценности, но все еще нет компетенций: продолжать растить, это происходит уже проще и быстрее, потому что команда говорить на одном языке. Человек переходит в пункт 3.
  3. Есть ценности, есть компетенции: это тот идеальный игрок команды, который нам нужен!
  4. Нет ценностей, но есть компетенции: такие люди не исправимы, не теряйте времени зря и не работайте с ними.

Не работайте с мудаками!

Завышенные ожидания

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

Многие ждали, что agile привнесет в их жизнь новые технологии и инструменты, применение которых ускорить прогресс. Но scrum нечто иное, это способ организации работы, некоторые рамки, а инструментарием наполняете его вы 🙂

Предвзятость

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

Несоблюдение framework scrum

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

Можно привести метафору с готовкой тирамису. Когда вы смешиваете взбитый яичный белок с сыром маскарпоне, важно не переборщить, иначе смесь станет очень жидкой и потеряет свою пористую структуру. Если забить на рецепт и взбивать это миксером, то результат будет плачевен. В scrum то же самое, если мы убираем daily scrum, то команда просто теряет связь друг с другом и вероятность, что все пойдет под откос повышается. Это мероприятие обязательное и оно учит нашу команду слышать друг друга, помогать друг другу и чекать, а насколько мы близки к цели и что нам мешает.

Что еще?

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

agile-v2-23-638

 

Почему я решила стать скрам мастером часть 2

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

Первое

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

Почему waterfall предполагает, что команда айтишников не способна общаться с тем, кто имеет представление о продукте? Ведь они все интроверты, им надо сидеть программировать и не отвлекаться…

Самое дорогое – это начать писать код. И особенно дорого это становится, когда вы пишете не то, что на самом деле нужно. Здесь мы приходим к главному плюсу agile подхода – прежде чем делать что-то, убедись наиболее быстрым и дешевым способом, а то ли надо делать.

Второе

Это такое глубокое погружение в предметную область, что тебе кажется ты вот-вот сам начнешь программировать под iOS или Android. Представьте, команда сидит программирует, у нее появляются вопросы и, конечно же менеджер идет всё уточнять у заказчика. Это ведь его прямые обязанности. Выясняет, приносит команде в клювике, а тут еще столько же вопросов появляется, ведь они не переставали в этот момент работать. А всем известно, чем больше ты на самом деле знаешь, тем меньше ты знаешь 🙂

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

Третье

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

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

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

Почему я решила стать скрам мастером часть 1

Вижу компанию по разработке ПО: из 34 человек, только 12 относятся к созданию продукта 😀 Остальное руководители и менеджеры.

@beshkenadze

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

Провал в основном происходил потому что люди склонны слишком оптимистично оценивать задачи, а заказчики не до конца осознают, чего хотят. Но это нормально. В срок укладывались совсем маленькие проекты, которые нужно было сделать к определенному событию, например, выставка Lamborghini в Москве. Успешные проекты никогда не длились больше 1 месяца и имели четкие границы функционала. Этот функционал практически не менялся и всегда была понятна конечная цель продукта.
Именно это и натолкнуло нас на мысль, что маленькие проекты успешнее. “А давайте бить большие проекты на короткие итерации, чтобы показывать результат заказчику как можно раньше и как можно раньше сдавать проект!” – решили мы. Но проекты все-равно не становились успешными.

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

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

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

  • Команда стала общаться уже не с менеджером, а с владельцем продукта. Это стало происходить чаще, а не только в начале и в конце каждой итерации.
  • У нас появился баклог и стали вырисовываться цели спринтов.
  • У команды появилась ретроспектива, где мы обсуждали, как нам увеличить свою эффективность. Не регулярная, но уже хорошо.
  • Команда стала мыслить в терминах результата, брать на себя ответственность и бешеная нагрузка на PM снижалась. Высвобождалось время на проектирование UX, которым я тогда увлеклась.

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