?

Log in

Previous 10

Apr. 27th, 2012

Agile process experiments: silent hours

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

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

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

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

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

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

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

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

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

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

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

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

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

Tags:

Apr. 20th, 2012

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% тратилось на дело. И то, только если эти задачи все-таки принимались в скоуп спринта. 

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

Apr. 10th, 2012

Презентация "Управление инновациями в стиле Lean Startup" с SWP'12

Apr. 9th, 2012

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).

Mar. 29th, 2012

Управление инновациями в стиле 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, а затем более подробно разберем несколько реальных примеров применения этих принципов для управления инновациями в российских компаниях.

Mar. 25th, 2012

Инвалиды офисного труда. Часть 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 более подробно.   

Feb. 24th, 2012

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. 

Feb. 6th, 2012

Project T

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

==

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

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


Чиать дальшеCollapse )

Sep. 5th, 2011

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. 


Tags:

Previous 10