• Интервью с Алексеем Кривицким и Натальей Трениной, SCRUMguides

    Posted on September 7th, 2009 Александр Орлов 4 comments

    (До Agileee осталось 12 дней.)

    Это интервью с Алексеем Кривицким и Натальей Трениной из SCRUMguides задумывалось почти месяц назад. Но ребята оказались очень заняты, их ждада Agile конференция в Чикаго, а тут еще я задал вопросы, требующие развернутого ответа. В общем, процесс немного затянулся, но таки ура! интервью состоялось, чему я очень рад. Для тех, кто не в курсе Алексей и Наталья в Украине – это как Асхат Уразбаев и Никита Филиппов в России. :) Главные евангелисты гибких подходов.

    Леша, Наташа, привет! Спасибо, что согласились поделиться своим опытом с читателям проекта Happy-PM.com.

    Всегда рады делиться своим скромным опытом.

    Расскажите свою историю. С чего вы начали, как пришли к гибким подходам? И как в итоге оказались в  SCRUMguides?

    [А.К.] Ну, истории у нас разные. Я пришёл к Аджайлу из аутсорсинга. Насмотрелся на тяжеловесный RUP (он бывает и другим), на компанию, несущую на плечах  спущенный сверху CMM, на отсутствие внутри- и меж- командного взаимодействия. Уволился… Начитался книжек и понял, что XP/Scrum/Crystal могут дать то, чего мне, моим командам и заказчикам не хватало: эффективного взаимодействия, прозрачности, драйва.

    В 2007, живя вдали от Родины, запустил группу рассылки AgileUkraine.org. По возвращению из “ссылки”, стал работать независимым консультантом. Так родились “Скрам Гиды”. Сейчас мы стали называть себя коучами – это более верное определение.

    Весной 2009 на своём тренинге по “Базовым концепциях Agile и Scrum” я встретил ЕЁ!..

    [Н.Т.] :)  Я пришла к Agile из корпоративных проектов – руководила командой, разрабатывающей и поддерживающей интегрированные системы управления.

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

    Серфинг по интернет и чтение “Заметок с передовой” Хенрика Книберга, показывали, что подход довольно структурный и легковесный. Мы как раз запускали новый проект, ничто не мешало попробовать. И однажды утром, я порадовала свою команду – “Завтра у нас SCRUM!” :)

    Поиграли в ball-point, рассказала ребятам о ролях, церемониях и артефактах, и за пару дней мы запустили “первый спринт комом”. А через месяц отправилась на тренинг – за деталями и тонкостями планирования.

    Собственно, тренинг стал переломным моментом в моей карьере. Я ведь тоже “начитавшаяся книг” (тут у нас много общего).  А текущая корпоративная проектная культура, оставляла не так много пространства для практического развития.

    Что бы глубже разобраться  с гибкими подходами я разработала однодневный тренинг “для друзей”. Друзья из IT пригласили других друзей, и получилась сборная аудитория из разных проектных сфер. Это был интересный опыт.  И повод для общения с Лешей о  применении SCRUM вне IT.

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

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

    Многие события последнего полугода я считаю фантастичными. Прежде всего – возможность работать с НИМ.

    Сейчас в мире выработано довольно много методологий. Те же отцы-основатели Agile манифеста создали их несколько: Scrum, XP, Crystal. На ваш взгляд, от чего должна зависеть методология? Как менеджеру проекта выбрать методологию, которая будет лучше всего подходить для его ситуации?

    [Н.Т.] Забыть о <своей> ситуации и подумать о людях, с которыми он работает. Задействовать весь их потенциал, открыть новый уровень доверия,  вовлеченности, и самоорганизации. Разделить с командой ответственность за успехи и поражения, заставить их глаза блестеть, и вместе работать над выбором оптимальной методологии.

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

    К сожалению, этому не учат на курсах PMP. Многие менеджеры не знают ничего кроме водопадной модели, диаграмм Ганта и Парето – это наиболее ассоциируемые с проектным менеджментом концепции. А мир меняется, лучшие практики становятся отраслевыми стандартами.  Но прежде чем внедрять новые подходы в организации процессов – подумайте о том, что большего за ними стоит. То, что объединяет все методологии Agile-семейства и выражено в Agile-манифесте.

    [А.К.] Кстати, отцы-основатели манифеста (многих мы повидали недавно на Agile2009) недолюбливают слово “методология” и чаще используют “подход”.

    В сущности, всё семейство гибких подходов про одно и то же:

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

    Это моё понимание Манифеста, его ценностей и принципов.

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

    Еще один способ – “copy-paste”. Многим проще начать с чего-то существующего, проверенного и адаптировать это под себя. Выбор гибких подходов не так уж велик. SCRUM, де факто – самый простой в понимании и объяснении Agile-подход. Не зря же отцы XP и Crystal сейчас уже проводят SCRUM-сертификации (!). Важно наращивать и детализировать свой процесс, учиться разрешать проблемы, которые стали видны благодаря SCRUM, а не менять сам SCRUM.

    Примеру: если вы не можете научиться выпускать демонстрируемые версии продукта каждые три недели, не стоит удлинять итерации до месяца, вводить итерации плавающей длины, –  их стоит укоротить до двух недель!

    Таким образом, Вы получите каркас менеджмента. А инженерные практики стоит “позаимстовать” из XP, и научиться грамотно их применять.

    Последний Chaos Report показывает практически ту же неутешительную картину, что и 10 лет назад: только около трети проектов завершаются успешно. На ваш взгляд – почему нет улучшений в плане управления проектами?

    [А.К.] Я как раз слышал обратное – улучшения есть, в проектах среднего размера.

    Что же касается крупных проектов, то Agile только сейчас начал полноценно выходить на уровни корпораций, и мы можем читать первые отчёты и слушать презентации о внедрении SCRUM в корпорациях в 1000 человек и больше. Но, тут ещё очень многому индустрии стоит научиться.

    С другой стороны не все проекты должны завершаться успешно. На то они и проекты, а не налаженное производство. Из стартапов, к примеру, до этапа окупаемости доходит по статистике менее 1% проектов.  Я думаю, тут действует какой-то закон, который никогда не улучшит подобную статистику: чем больше появляется успешных проектов, тем больше в индустрию будет тянуть тех, кто хочет “испытать своё счастье” на каком-нибудь сложном и безнадежном проекте. Таким образом процент неудачных проектов не должен уменьшаться. Так же стоит говорить о возрастающей конкуренции на рынке программных продуктов, что усложняет проектные условия и тем самым “портит” статистику. Это замкнутый круг.

    Все важнее становится недорого проваливать проекты (крылатое выражение “Fail Fast”). И прозрачность, которую даёт Agile, здесь очень кстати – чем раньше мы узнаем о безнадежности проекта, тем больше сэкономим на НЕвыполнении лишней работы.

    Но статистика – безапеляционная и бездушная штука. Я бы о ней не говорил. Я уверен, каждого проектного менеджера волнует его проект намного больше, нежели индустрия в целом. Отчет его проекта, а не очередной Chaos Report. И Agile есть что предложить его конкретному проекту.

    [Н.Т.] Один мой коллега много лет руководит проектами в высшем сегменте бизнеса. Недавно в обновлениях LinkedIn прочла последнюю рекомендацию о нем – “He is a getting things done guy able to deliver complex projects with a perfect smile”. Все его проекты “водопадные”, но мне есть чему у него поучиться, прежде всего interpersonal skills.

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

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

    Предположим, воодушевленный менеджер решает внедрить какие-то практики и подходы. Как продать новые практики команде?

    [Н.Т.] Воодушевленному менеджеру стать воодушевляющим :) Сложно зажечь сразу многих – люди с настороженностью относятся ко всему новому. Но даже одного-двух приверженных сотрудников достаточно, что бы запустить маховик перемен. Если вы хорошо знаете свою команду, вы поймете, кто может быть таким человеком.

    [А.К.] Как говорит Кен Швабер (на самом деле Шуейбер, популяризатор Скрама): “Мы не получаем процентов от продаж, зачем же нам тогда что-то кому-то продавать”.

    Конечно это шутка, но правда в том, что продажа – это не то слово, которое мотивирует. Когда мы с Натальей работаем в командах, мы вдохновляем и вовлекаем (иногда приходится ещё и пробуждать). Вот слова, верно описывающие наш инструментарий!

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

    [А.К.] У многих команд наших клиентов их первый SCRUM-проект становится самым лучшим и любимым проектом. До этого у многих просто не было опыта настоящей командной работы!

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

    • тирания водопада
    • иллюзия директивного управления
    • вера в магию
    • эра затуманенности

    Достаточно вспомнить ваш самый плохой проект, и вы увидите, что там все это было (или почти всё).

    Работая с устоявшимися командами, часто приходится рушить концепции, учить работать с “чистого листа”. Для этого мы проводим SCRUM симуляции с LEGO, разрабатываем микро-проекты, играем во всевозможные игры, обсуждаем Ценности, Видение и Миссию командной разработки.

    Это переворачивает сознание, но требует ресурсов как с нашей стороны, так и со стороны команды. За день или два можно внедрить церемонии SCRUM, но не ценности, пропагандируемые Agile-подходами. Второе – значительно сложнее и требует больше времени.

    [Н.Т.] Нет одного готового рецепта для менеджеров – это некая офисная магия J Один из ее секретов – менеджмент в стиле коучинг (мы помогаем развить этот навык).

    Каким командам не подойдут гибкие методологии?

    [А.К.] У меня нет ответа. Но это точно НЕ зависит от “сеньёрности” разработчиков.

    Мне кажется, дело в стиле руководства. Вы знаете, что командные коучи в основном работают (должны работать!) с руководителем? Если менеджер не готов “отпустить поводья”, то где тут место самоорганизации?

    [Н.Т.] Если же предположить, что мы свободны изменять контекст – гибкие подходы будут полезны любым командам.

    С какими проблемами могут столкнуться команды, внедряющие, скажем, Scrum?

    [А.К.] С любыми :) Больше того, мы хотим, чтобы они столкнулись с некоторыми из них, научились с ним справляться и перешли на следующую ступеньку развития эффективности.

    SCRUM (как и любой Agile-подход) делает процесс прозрачным, а проблемы – видимыми. Раньше от вас никто не ждал релиза раз в две недели, теперь это может стать проблемой. Раньше команде не нужно было приходить к консенсусу, теперь необходимо развивать этот навык. Раньше заказчику не нужно было объяснять ценность функционала для бизнеса, теперь это стало очень важно. И прочее – прочее – прочее.

    [Н.Т.] В первый раз в своей команде я внедряла SCRUM самостоятельно, без коуча. Напрашивается цитата “Не пытайтесь повторить это в домашних условиях” :) . Конечно же, такой способ тоже возможен – это зависит от личных качеств, навыков и авторитета внутреннего коуча.

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

    К сожалению, “SCRUM, but..” (по-русски “Скрам-но” :) )- весьма распространенное явление. Лечить такие процессы и отношения бывает непросто, поскольку люди уже потеряли свежесть восприятия, выработали концепции и определенный скептицизм к подходам.

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

    [А.К.] Мне нравится философия Ицхака Адизеса, который разделяет проблемы на нормальные и анормальные. Как коучи мы проводим команды по такому пути развития, на котором они избегают анормальных проблем – личных конфликтов, диктатуры меняющихся лидеров,технического долга и прочих тупиков. При этом сталкиваются с нормальными проблемами и учатся с ними справляться – поддерживать код в здоровой форме, поддерживать эволюционирующую архитектуру приложений, эффективно взаимодействовать на межличностном уровне.

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

    Знаете ли примеры работы по Agile с гос. заказчиками? Если нет, то что мешает прежде всего?

    [А.К.] У меня таких примеров нет, так что ничего не мешает. :) Но если бы такие прецеденты были, то мешали бы определённо фиксированные типы контрактов.

    [Н.Т.] Мне кажется, многое зависит от возможности уйти от бюрократических аспектов работы с госзаказами. Оформление требований, архитектуры и прочей проектной документации по изжившим себя государственным стандартам плохо укладывается в концепцию гибкости.

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

    В последнее время на слуху у масс появляются новые слова. :) Чтобы сэкономить массам время, расскажите в двух словах, что такое, например, Lean?

    [А.К.] Lean Software Development, на русский стал переводиться как “Бережливая Разработка” (мало нам было гибкой? :) ). Это набор принципов, которые по своей сути выше принципов Agile. Они пришли в этом веке на Запад из опыта восточных компаний, таких как Тойота, 3М и других.

    Основная суть – целостных взгляд на процесс разработки продукта как на систему. Не имеет смысла оптимизировать работу команды или отдела. Важно быть нацеленным на оптимизацию всего потока производства. Многое Lean взял из систем массового обслуживание, систем с очередями.

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

    Lean привезли в Штаты из Японии Мери и Том Поппендик (Poppendieck). Кстати, скоро они посетят Киев с докладами и мастер-классами на конференции Agileee. Впервые и, вполне вероятно, единственный раз – так близко.

    [Н.Т.] Не пропустите возможность узнать о Lean из первых рук!

    А что такое Kanban? :)

    [А.К.] Канбан (говорят, что это читается как “Камбан” но я не японовед), это по сути визуализация потока работы, да так чтоб наглядно были видны физические ограничения. Если очень просто – то это доска с наклеенными на неё задачами по статусам, где, скажем, в работе может быть не более 3 задач.

    Отличие от Аджайла или Скрама с его Скрам-доской в отсутствии итераций. Это может быть весьма полезно отделам поддержки, у которых нет планируемого объёма работ.

    Из русскоязычных об этом много последнее время говорит и пишет Макс Дорофеев.

    Книги по УП, которые вас потрясли? Скажем так, книги, которые для вас много значат. Что вы бы порекомендовали прочесть вот сразу сейчас

    [А.К.]:

    • “Peopleware” или “Человеский фактор” Тома Де Марко и Тимоти Листера
    • “Agile Software Development”  Элистера Коуберна (есть русский перевод)
    • “Planning Extreme Programming” Фаулера и Бека
    • “Agile Estimating and Planning” и “User Stories Applied” Майка Кона
    • “Скрам и XP: заметки с передовой” Хенрика Книберга (электронная книга с русским переводом – спасибо AgileUkraine!)

    [Н.Т.] Я бы добавила “любовный” роман Тома Демарко – DEADLINE :) . Масса моих друзей, даже не имеющих непосредственного отношения к проектному менеджменту, остались в восторге от этой книги. И еще одну книгу Тома по управлению рисками в программных проектах – “Вальсируя с медведями”.

    Много книг сейчас на фазе прочтения и в to do – листе. В Штатах мы пополнили свою библиотеку на год вперед! Тематика – фасилитация, коучинг, тонкости внедрения Agile.

    Вам большой респект за то, что вы организовываете Agile EE? Судя по всему, там будет категорически интересно. Тем не менее, скажите пару слов, почему туда надо идти? Может быть, какие-то новости, что еще будет?

    [А.К.] “Идти однозначно!” Потому что Agileee – крупнейшая в Восточной Европе конференция по гибкой разработке. В ее программе – 32 докладчика из 15 стран мира, среди которых очень известные люди.

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

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

    На текущий момент география участников охватывает такие страны Западной Европы, как Германия, Дания, Франция, Бельгия, Голландия, Эстония, Финляндия. И, конечно же, много посетителей из Восточной Европы.

    Масштаб Agileee соразмерен с европейской конференцией Scrum Gatherings, участие которой дороже раз в десять, и проходит она в Западной Европе, США и Южной Америке. А мы предоставляем уникальную возможность – посетить высокопрофессиональную конференцию значительно ближе и дешевле.

    [Н.Т.] Стартуя в Украине, в последующие годы конференция посетит другие страны Восточной Европы. Быть может, мы бросим “свадебный букет” на закрытии Agileee и сообщим, в какой стране конференция пройдет в следующем году. Мы действительно многое делаем для имиджа нового бренда конференции, так что Вас ждут приятные сюрпризы ;)

    [А.К.] И последнее –  Киев просто прекрасен в начале осени!

    [Н.Т.] Добро пожаловать!

    Обязательно заглянем! Спасибо за интервью!

    (До Agileee осталось 12 дней.)

     

    4 responses to “Интервью с Алексеем Кривицким и Натальей Трениной, SCRUMguides”

    1. Скидка ведь действовала до 15 августа. Или я пропустил что-то?

    2. Точно, это я погорячился. :) Удалил.

    3. [...] Леша Кривицкий и Наталья Тренина решили сразу после Нового года устроить Agile конференцию. И я даже почти собрался туда приехать, как неожиданно понял что в это же самое время будет тренинг Happy PM в Москве. Поэтому, приехать в Киев самому не получится. Решил послать туда десяток дисков с сюрпризами, чтобы они как-то попытались меня там заместить. [...]

    4. [...] Читаем!.. [...]

    Leave a reply

    You must be logged in to post a comment.