Стратегия изменений. Часть 1

Очень вдохновилась тут заметками от Unusual Concept с интервью практикующих agile-коучей и scrum-мастеров. Особенно понравилось интервью с Лешей Пикулевым, и ответ на вопрос:

пикулев
Часть интервью с Лешей

Пытаюсь анализировать, как двигаюсь я. Многие шаги, которые они перечисляют в ответе на вопрос “Вас закинули к новой команде, ваши действия в первый месяц?“, я совершаю сама. Поэтому кажется, что на верном пути, ну и помню, что единственного верного пути нет 🙂

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

Как мы живем сейчас

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

6f81eda2-f26f-4984-b74a-c875487f8d89

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

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

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

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

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

Часть 1.

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

И вводим профессионального скрам-мастера – это я, конечно же, про себя 🙂

6f81eda2-f26f-4984-b74a-c875487f8d89

Теперь:

  • владелец продукта всегда с командой и знает ответы на все вопросы, а ребята, в свою очередь, могут начинать задавать вопросы
  • у ребят остается больше времени на свою работу, а больше работы, значит больше проблем, ведь команда то огромная
  • скрам мастер помогает двигаться команде вперед

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

Но об этом в следующих сериях…

Daily Standup Quest

У одной моей команды, которая только в прошлом месяце встала на рельсы Kanban, начались небольшие трудости. А именно, ребята саботируют ежедневные стендапы. Не специально, но все же не собираются, задачки не заводят, задачки по доске не прокатывают.

Мы долго думали с ними на ретро, как изменить отношение к этому процессу, что он полезный и нужно себя пересилить, и придумали:

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

CfjEzQNUEAAHIYJ[1]
Все уже, наверное, знают про такой способ 🙂
После ретро у меня мысль разогналась настолько, что я решила сама устроить ребятам веселые стендапы. Так как с командой я не сижу, а являюсь сторонним консультантом, то решено за несколько минут до события отправлять им стендап квесты. Они будут занимать от нескольких секунд до пары минут, но зато разбавят рутину и сделуют жизнь веселея! А главное, каждый раз будут разными 🙂

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

Понедельник: прийти на стендап с кофе/чаем, сказать крутой тост и поднять кружки за свой новый продукт

Вторник: хлопнуть-топнуть 3 раза, и крикнуть хором “Мы команда!”

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

Четверг: встать в круг и сказать человеку справа комплимент

Пятница: сыграть в крокодила -изобразить зебру и тому, кто угадал, выдать настольную игрушку маленькую зебру

Скоро мы с ними снова встречаемся и я получу от них обратную связь. Думаю что им понравится 🙂

Такой небольшой инструмент, а куча позитива и пользы!

Agile development

Когда весь мир уже говорит об Agile, Scrum, Kanban, что это новые и эффективные подходы к организации работ, как-то глупо оставаться в стороне и не попытаться узнать, что это такое. Когда становится понятно, что Agile это всего-лишь 4 ценности и 12 принципов, которых стоит придерживаться, чтобы быть другим, а Scrum – 23 страница текста, возникает первый вопрос: “А как тогда это правильно готовить?”.

Если представить пару Agile и Scrum, как новое блюдо, которое должно получиться, то после двух прочтенных документов у нас с вами есть только набор ингредиентов, их описание и совсем нет рецепта. И это главный вопрос! Давайте поговорим о рецепте.

Здесь начинается самое интересное. Эти 2 модных слова могут существовать раздельно, но в этом практически нет смысла, как секс и любовь. Секс это, конечно, хорошо, а когда же любовью будем заниматься? 🙂 Поэтому эффективней всего Agile и любой другой гибкий фреймворк идут рука об руку. И первым шагом вам надо начинать с ценностей.

С понедельника новая жизнь

Так как же стать обладателем новой философии и изменить всю компанию? Прежде всего хочется сказать, что это не внедряется, как 1C и любой другой инструмент. Потому что это не инструмент 🙂 Нельзя просто взять и поменять философию, веру. Это как буддизм – его нельзя внедрить, им можно только заразить.

Ну а что такое философия, согласно которой существует компания? Это ваша корпоративная культура, которая, на самом деле, является отражением ваших действий, это ваша тень. То как вы ведете себя ежедневно, как собственник, как топ-менеджер затем отражается на всей компании. Если у вас модно идти и кому-то и жаловаться на кого-то вместо того, чтобы пойти к этому человеку и все решить самостоятельно, это станет нормой во всей компании.

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

principles[1]

Создайте заповедник

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

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

Не советую переходить сразу всем продуктам на новые рельсы, потому что бизнес либо умрет, либо очень быстро скатится на старые рельсы, ведь это привычно и просто. А потом будете говорить “scrum не взлетел” 🙂

no_entry[1]

 Посейте культуру

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

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

82c739614d2e4aa5ab9aa150b744dbe4[1]

Вообще, scrum team предполагает от 3 до 9 человек, то есть кол-во связей между членами команды будет от 3 до 36. Но мне нравится другое оптимальное количество, которое звучит, как “two pizzas”. Это правило, когда команду можно накормить 2-мя пиццами, где кол-во кусков равно количеству связей между членами команды, то есть равное примерно 16. Получается где-то 6 человек. Сейчас у меня одна команда 7 человек, считая меня и овнера, больше уже перебор, по личным ощущениям.

photo_2017-03-29_15-58-10

Команда должна быть кроссфункциональной, то есть в ней должны быть все компетенции для вывода вашего продукта на рынок. Если вы разрабатываете приложение под Android и iOS, ваша команда должна не только уметь это делать, но и желательно, чтобы два человека знали одновременно две эти технологии. Иначе у вас будет не такая высокая скорость и возможен внезапный bus-фактор. А если вы еще их научите XP, то будет вообще огонь 🙂

Это самые первые шаги, с которых стоит начать:

  1. Начни изменение с себя
  2. Организуй заповедник
  3. Выбери команду и продукт

Еще отлично про Agile трансформацию написано в блоге Scrumtrek. Ну что, попробуем?!