Agile process experiments: silent hours

Еще одна небольшая история в продолжении темы процессных экспериментов в команде. 

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

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

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

Определенное переосмысление подходов к решению этой проблемы произошло в моей голове во время выступления Андрея Бибичева "Гики против менеджеров" на Agile Base Camp в январе этого года.

И вот, на одной из ретроспектив была вброшена идея silent hours. 

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

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

Так вот, идея silent hours заключается в том, что команда вводит определенные "часы тишины", когда никто из команды не обязан отвечать на письма, телефонные звонки и все стараются не тревожить друг друга персональными вопросами. При этом если кто-то хочет ответить на письмо или звонок, он может это сделать. Также оговорены особые обстоятельства, при которых правило silent hours перестает действовать, например, падение системы на production.

Идея и не новая, и не оригинальная. И идея потока, и идея silent hours описаны, например, в классическом труде Тома Демарко и Тимоти Листера "Человеческий фактор: успешные проекты и команды" - Глава 10 "Работа ума и тела". Но я ни разу не видел воплощения этих идей в реальной жизни.

А тут мы решили попробовать. Сейчас это выглядит как один "silent" час с 17 до 18, который у всех членов проектной команды зашит в календарь повторяющимся ежедневным событием с обязательным ремайндером (напоминалкой).

Живем с этим уже четвертую неделю. И команда дает позитивныей фидбэк. Некоторые используют этот час, чтобы поиграть в настольный теннис, некоторые - чтобы погулять в парке рядом с офисом и подумать над сложными архитектурными задачами, некоторые, возможно, просто могут ничего и никого не стесняясь, посерфить в интернете. Некоторые, кстати, в это время сидят и работают как обычно. Это по настроению. Главное, что появился официальные повод (и экскьюз) переключить мозги с рутины на что-то более глобальное или отвлеченное от работы. И либо действительно подумать над сложной проблемой по работе, либо просто дать своему мозгу возможность переключиться с рабочих проблем на что-то другое и отдохнуть от бесконечных прерываний в виде звонков, писем и вопросов коллег.

На прошедшей ретроспективе эксперимент признали успешным и договорились продолжать. Причем на мой провокационный вопрос - а не мало ли одного часа, ответили, что нет, не мало. А то ведь нужно еще и фичи делать... ))

Agile process experiments: Personal Technical Debt backlog

Полтора года назад мы начали полномасштабный и бесповоротный переход на Agile в одной из продуктовых команд, в которой я играл роль владельца продукта (product owner). Основной причиной перехода стала осознанная невозможность своевременной адаптации планов разработки под все более быстро изменяющиеся требования наших внутренних и внешних заказчиков. Основным из главных вызовов этого перехода стала сама команда, которая состояла из опытных людей, которые построили свои успешные карьеры в программной инженерии на проектах с традиционными подходами к разработке. За прошедшие полтора года произошло многое. Были взлеты и успехи, были падения и разочарование от несбывшихся ожиданий. О некоторых подробностях переходного периода я рассказывал год назад на AgileDays2011 ("В чем счастье заказчика? Готовые фичи вместо Гант-чарта!"):



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

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

Суть эксперимента - выделение резерва времени из рабочей загрузки команды (team work capacity) на выполнение задач, которые могут уже в ходе спринта выбрать сами сотрудники. Оказалось, что некоторые члены команды испытывают существенный дискомфорт из-за того, что связанные с их ключевыми компетенциями мелкие и не очень заметные на масштабе проекта задачи во время планирования спринта постоянно проигрывают по приоритетам другим более крупным задачам с более понятной бизнес-значимостью. И тут можно много троллить и кидать камни в чужой огород: дескать, это проблема этих специалистов, потому что они не смогли донести до команды и product owner-а важности этих пусть и мелких задач, или что это проблема product owner, который не смог разглядеть важность этих задач и помочь специалисту их пролоббировать на планировании, или того, что эти задачи не внесены правильно в technical debt бэклог и пр. и пр. 

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

Мы выделяем несколько фич-заглушек с пустым на момент планирования спринта скоупом, но с конкретной оценкой сложности/трудозатрат, и включаем эти "фичи" в скоуп спринта. Обычно это 1-3 фичи небольшого размера (менее 5% velocity команды). 

Результат эксперимента показал феноменальный результат. Испытывавшие ранее дискомфорт специалисты с такими фичами смогли почувствовать себя менеджерами. Хотя бы для самих себя. Они получили самостоятельность. Они теперь сами спокойно выбирают те задачи, которые считают нужными сделать в рамках объема этих фич-заглушек исходя из своего внутреннего понимания бизнес-значимости и приоритетности.  И сотрудникам теперь не нужно тратить много времени на объяснение команде сути этих мелких задач и убеждение всех в высокой бизнес-значимости этих работ. Задачи такие маленькие, что раньше 90% времени уходило на бесконечные объяснения и приоретизацию и планирование, и только 10% тратилось на дело. И то, только если эти задачи все-таки принимались в скоуп спринта. 

А теперь все эти потери ликвидированы.  Сотрудник самостоятельно делает выбор, чувствует себя ответственным, у него появляется время реально сделать за спринт достаточно много мелких задач из накопившихся "висяков". Фактически, у каждого сотрудника теперь есть возможность вести свой собственный бэклог технических задолжностей, и иметь гарантированный слот времени на выполнение нескольких высокоприоритетных задач из своего персонального бэклога в течение спринта. И осознания этого факта дает ощущения сильного удовлетворения и радости от хорошо сделанной работы.

Startup Weekend

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

Вечер пятницы начинается с приветственного ужина, ice-breaking игры и короткого вводного выступления главного координатора мероприятия. Затем обычно следует несколько коротких выступлений по практическим навыкам, например, "Elevator pitch: Как продать свою идею за 60 секунд" или "Принципы Lean Startup". После этого проводится сессия питчей: все, у кого есть идея для создания стартапа, могут обратиться к аудитории и за 60 секунд рассказать о себе, своей идее, о планах по ее реализации и необходимых для этого ресурсах и навыках. По окончанию сессии питчей все участники мероприятия голосуют за понравившиеся идеи, выявляя наиболее интересные из них. И затем именно вокруг этих отобранных идей  формируются стартап команды по 5-7 участников, которые тут же начинают брейнсторминг (брейндампинг, как это принято называть в startup weekends) и планирование работы на следующие 2 дня.

В субботу команды работают над своими идеями. Основная цель - оформить свою бизнес-идею, подготовить бизнес-план, реализовать MVP и получить на свой продукт или сервис первых "платящих" покупателей или клиентов.  В любой ммоент времени команды могут обратиться с вопросом к присутствующим на мероприятии менторам. Работа команд прерывается на короткое время для отдыха и приема пищи. Также обычно в течение субботы проводится еще несколько коротких выступлений для всех на тему стартапов.

В воскресенье команды продолжают работу до обеда, после чего они начинают готовить свое выступление с результатами работы. На презентацию результатов работы перед группой судей каждой команде обычно отводится 5 минут и еще 2-3 минуты на вопросы со стороны судей. После этого судьи определяют победителей, происходит награждение команд и начинается вечеринка по поводу завершения startup weekend.

Идеи и техника startup weekends описаны в одноименной книжке (http://www.amazon.com/Startup-Weekend-Company-Concept-Creation), которая уже переведена на русский язык (http://www.books.ru/books/startup-weekend-ot-idei-do-kompanii-za-54-chasa-1810702). Основные идеи и описание техники проведения startup weekend-ов также можно найти на веб-сайте движения (http://startupweekend.org/firsttimer/), там же можно найти календарь проведения startup weekend-ов в разных городах. Кстати, в конце мая очередной Startup Weekend пройдет в Москве (http://startupweekend.timepad.ru/event/21538).

Управление инновациями в стиле Lean Startup

Выступаю с темой "Управление инновациями в стиле Lean Startup" на Software People 2012 в Москве, 11 апреля.  Надеюсь, что будет запись, и ей потом со всеми можно будет поделиться. Тезисы ниже. До встречи на SWP'12!

===
Движение Lean Startup еще не приобрело в России такой популярности, которой оно пользуется в  США и других англоговорящих странах. Между тем, все мы постоянно применяем принципы Lean Startup в работе и в повседневной жизни, но практически никогда не задумываемся об этом, не применяем эти принципы осознанно. Тем самым мы только дополнительно подтверждаем мнение Запада о нас как о Емелях, раскладывающих пасьянсы из нефтедолларов и приговаривающих себе под нос: "По щучьему велению… По моему хотению… Забабахаем-ка мы МОДЕРНИЗАЦИЮ". 

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

Концепция Lean Startup-а проста как рецепт мохито, но далеко не каждому получается сделать феерический по вкусу напиток из одинакового для всех набора простых ингредиентов. Как ром в мохито, в основе Lean Startup лежит известный цикл "гипотеза"-"эксперимент"-"анализ", предложенный еще в 1620 (!) году основоположником научного подхода Френсисом Бэконом (люди помоложе также наверняка вспомнят Эдварда Деминга со ставшим всемирно известным циклом PDCA). 

Остальные ингредиенты также важны для получения превосходного результата:
  • Приятную сладость тростникового сахара обеспечивает принцип "Предпринимателем может быть каждый",
  • Мятную пикантность создает принцип "Подтвержденные знания",
  • Кислинку лайма придает принцип "Предпринимательство - это управление",
  • Ну а за ледяную прохладу отвечает принцип "Бухгалтерия инноваций". 
Итак, на сессии «Управление инновациями в стиле Lean Startup» мы кратко рассмотрим каждый из пяти основных принципов Lean Startup, а затем более подробно разберем несколько реальных примеров применения этих принципов для управления инновациями в российских компаниях.

Инвалиды офисного труда. Часть 1: Скрытая угроза

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

Но обязательно будет и продолжение, и не одно, поэтому скоро появятся и "спасалки". ))



Ссылка на презентацию, по которой ее можно посмотреть в браузере:  http://prezi.com/m1hw9ip9yj-j/death-office/.

P.S. После выступления меня спрашивали, почему я показывал иконографику смертности в Украине, а не в России. Некоторые даже усмотрели в этом какую-то особую шпильку в адрес Украины. Но нет, никакой шпильки в этом нет, причина тривиальна. Я не нашел иконографики со статистикоы по России, но нашел по Украине. А поскольку общий показатель смертности в наших двух странах очень близкий, и жизнь у нас все-таки еще пока очень похожа, я посчитал, что без потери релевантности данных ради красивой визуализации можно взять данные по Украине.

Но если кто-то интересуется данными по России, то самые свежие данные можно найти здесь: http://demoscope.ru/weekly/2012/0499/barom02.php. Они структурировны по-другому, чем данные по Украине в моей презентации, поэтому не удивляйтесь отличиям. Но общий тренд легко виден и он неизменен. Основная причина смертности - сердечно-сосудистые заболевания. 

Lean Startup в крупной организации

Мое выступление про работу принципов Lean Startup в крупных организациях на конференции AgileDays2012. Честно сказать, я был слегка шокирован:
  • на выступление пришло достаточно много слушателей (несколько десятков)
  • на вопрос "кто читал книгу Lean Startup" поднялось 3-4 руки
Удержался от провокационного вопроса на тему "зачем пришли на тему работы принципов Lean Startup в крупных организациях, если сами принципы вам неизвестны?". Думаю, это просто магическим образом сработали по отдельности два лейбла (простите, ярлыка): Lean и Startup.

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

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

Но есть и хорошая новость. 11 апреля я буду делать доклад по Lean Startup на SWP'12. И если там прочитавших книгу окажется больше, будет возможность поговорить о применении принципов Lean Startup более подробно.   

Lean Startup в крупной организации

Вчера один мой знакомый, интересующийся темой Lean Startup, посмотрев на абстракт моего выступления на AgileDays 2012 (http://msk12.agiledays.ru/reports/view/24/), задал мне вопрос, какой-такой Lean Startup может быть в крупной организации. Как мог, рассказал ему про "какой-такой" за минуту по телефону, но, понимая неочевидность ответа, особенно для не очень хорошо читавших Lean Startup, решил кратко записать ответ, чтобы потом на него ссылаться. ))

Вот 5 известных принципов Lean Startup (по одноименной книге):

  1. "Enterpreneurs are everywhere"
  2. "Enterpreneurship is management"
  3. "Validated learning"
  4. "Build-measure-learn"
  5. "Innovation accounting"

Validated learning означает следующее: "Startups exist not just to make stuff, make money, or even serve customers. They exist to learn how to build a sustainable business." На русском это одначает приблизительно следующее: "Стартапы нужны не только для того, чтобы что-то производить, зарабатывать деньги или обслуживать клиентов. Стартапы нужны для того, чтобы узнать (научиться), как построить устойчивый бизнес."

Таким образом, схема "Build-Measure-Learn" ("Создайте-Оцените-СделайтеВыводы"), концепция MVP - minimum viable product (простейший вариант продукта/услуги, имеющий бизнес смысл для потребителя) и механизм pivoting-а (т.е. "поворота", коррекции бизнес-модели в зависимости от полученного от MVP результата) отлично подходят для проверки инновационных гипотез, "выращивания" инноваций и встраивания их в стек регулярных продуктов/сервисов крупной организации.

О чем и предполагаю рассказать. В качестве иллюстрации будут как минимум два примера - внутреннего продукта, завоевавшего популярность в достаточно крупной и сильно гетерогенной компании, а затем ставшего успешно продаваемымым на внешнем рынке, и внутреннего сервиса, который мы с одним очень известным в российских agile кругах человеком так и не смогли трансформировать в устойчивый сервис в 2005-2007 годах, и который был очень успешно перезапущен в 2009-2011 годах с использованием системно применяемых принципов Lean Startup. 

Project T

ПРЕДУПРЕЖДЕНИЕ
Некоторые факты, имена и даты сознательно опущены или искажены ради соблюдения правил конфиденциальности. Данный пост является плодом воображения автора и отражает его личное мнение, и не является отражением официальной точки зрения работодателя автора.

==

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

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


( Collapse )

Gartner Agile prediction - 5 months before the checkpoint

Когда в конце 2010 года мы написали на своем знамени цитату из Gartner о том, что к 2012 agile будет использоваться в 80% проектов по разработке ПО (http://www.gartner.com/DisplayDocument?id=1244514), мы просто хотели верить в эту фразу и произносили ее как мантру. Нам было понятно, что к этому все идет, но 80% к 2012 году даже нам казалось довольно смелым утверждением. 

Сегодня можно уверенно сказать, что к 2012 году жизнь будет устроена именно так. До 2012 остается еще 5 месяцев, но все, абсолютно все наши заказчики, даже самые консервативные и традиционные, заявили о начале экспериментов с Agile, программах по переходу на Agile или уже реально начали Agile трансформацию. Вечно занятые executives и традиционные менеджеры спешат узнать про Agile хоть что-то, выкраивая для этого время даже в расписаниях регулярных status review визитов. 

Магия "Go see" торжествует. Магическое воздействие производит все -  Agile пространство, покрытые бумагой стены, доски с карточками, бэклоги и берндауны в GreenHopper и Jira, работающие билд-сервера, плазмы со статусами сборок,  Cucumber/FitNesse, работающие вместе и выглядящие довольно счастливыми  разработчики. Особой магией обладают тулы типа Sonar. Менеджеры, уставшие от завравшихся статус отчетов, получают простой способ видеть реальный статус качества кода и результаты прогона тестов 24x7 в режиме on-line.

Все хотят быть Agile, но далеко не все смогут. Многие пока просто не понимают, что это такое - жить и работать в стиле Agile. И не всем будет дано успешно пройти ментальную трансформацию от command and control стиля к модели gardening.