AGILE COACHING AND SCRUM/XP TRAININGS IN EASTERN EUROPE

LOOKING FOR AN EXCITING OFFER: CTO OR AGILE COACH POSITION IN EU, CH, UK.

CHECK OUT MY RESUME
Showing posts with label blog. Show all posts
Showing posts with label blog. Show all posts

Dec 7, 2011

"Метрики и сантиметрики". Или в поисках agile метрик.


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

"Метрики - это зло", - так всегда открывает тему метрик Сережа Дмитриев, когда на тренингах всплывает вопрос метрик в Скраме.

Почему они зло? Да потому что, люди будут подсознательно вести себя так, чтобы повысить метрики, которыми вы их будете мереть: "Show me how you’ll measure me, I’ll tell you how I’ll perform" - гласит народная мудрость. В результате - метрики улучшаться, а ситуация - нет.

Что же делать? Держать метрики в секрете и никому не показывать!

Но как же прозрачность, самоорганизация и отсутствие единой точки менеджмента в Agile? Хм... Что-то здесь не так.

Может быть мы просто не то меряем?

ЧИТАТЬ ДАЛЬШЕ >>>

Dec 1, 2011

The Krivitsky Test - минимальный процесс разработки


Всем известен Тест Джоеля (Спольски): 12 шагов к лучшему софту.

Вот мой тест из 8 шагов:
  1. Есть ли удобный и единый source control с правами на чтение-запись у всех членов команды?
  2. Налажен ли процесс автосборок (он же continuous integration), который собирает продукт минимум раз в день, разворачивая сборки на тестовой среде?
  3. Есть ли у команды своя комната?
  4. Есть ли у команды физическая доска для планирования либо ее удобный электронный аналог?
  5. Есть ли в команде процесс краткосрочного планирования c горизонтом в одну, две или максимум три недели?
  6. Вовлечен ли заказчик в процесс приемки и раннего тестирования фич на ежедневной основе?
  7. Обсуждает ли команда свой процесс разработки как минимум раз в месяц для его наладки?
  8. Ограничивает ли команда размер своего баг листа, чиня дефекты регулярно?
По-моему опыту - утвердительные 8 ответов на этот тест существенно повышают шансы разработки хорошего продукта.

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

Как вы можете заметить - как минимум пять пунктов, а то и более, перекрываются с виденим Джоеля. Что не может не радовать :) Хорошего вам софта!

Что значит быть праведным agile-коучем?


Наткнулся только что на статью-дискуссию на infoq: "А есть ли у agile коучей код этики?"

"Искушение Святого Антония", С. Дали
Давно у меня на уме - что значит "быть праведным agile коучем"? Известно, что личный коучинг базируется на тех же методах, что и НЛП, у коготоро репутация чуть подпорчена... Да и встречаются клиенты, которые жалуются на коучей, которые дословно "messed around with our processes".

Так кто же такой праведный коуч? Каким принципам он следует? Что ставит во главу своей практики? Что ставит превыше всего?

У медиков есть свой: "не навреди".
У google - свой "do no evil".
А что есть у agile-коучей?

Набросок моих принципов - что для меня значит быть праведным коучем:
  • раскрывать потенциал людей, работающих в компаниях 
  • привести компанию на более высокую ступеть развития или как минимум показать потенциал и путь
  • работать с клиентами, уровень ценностей которых совпадает с моим
  • не чувствовать эмоционального фона к людям, а работать с процессами - помнить о том, что все хотят счастья и делают то, что делают, потому что думают, что это верный путь
  • не вести двойных игр, не быть политкорректным - открыто говорить то, что на уме
  • внердять практики (kanban, scrum, what-so-ever), только в случае, когда я интуитивно верю, что они смогут показать дальнейший путь развития компании, раскрыв потенциал
  • во время работы помнить о том, что я хочу научить компанию поддерживать свой процесс без моего участия и как можно скорее научиться обходиться без меня
Как-то так.
Готов рассмотреть предложение о внесении изменений в список, цена договорная :)

Nov 17, 2011

Видео доклада
"Offshore Outsourcing: the Agile Way"


А вот и долгожданное видео с Agile Tour, что прошел в Вильнюсе. Больше по теме вы найдете на сайте www.scrumoffshore.net.

Видео и ниже слайды:



Oct 6, 2011

Offshore Outsourcing and Agile

Пришлось переделать презентацию после фиалко на #agileee.

И на #agileturas пошло "на ура"!


Вот это фидбек!
@jurgenappelo It appears @alexeykri did great at #agileturas. I think he should do a keynote himself next year at#agileee

Sep 7, 2011

Offshore Outsourcing with Scrum

Сегодня выступил на ALE2011 с докладом "Offshore outsourcing with Scrum". Получил много обратной связи - общительность и позитивность западной аудитории вдохновляет.






Модели, паттерны и слайды доступны на блоге www.scrumoffshore.net

Улучшенная и удлиненная версия доклада будет повторена на AGILEEE 2011.

Aug 10, 2011

lego4scrum.com

Наконец-то!

Поднят ресурс lego4scrum.com, посвященный симуляции Скрам с Лего, которую я начал использовать с подачей одного моего товарища в 2008 и использую регулярно на тренингах как симуляцию полного цикла разработки по Скрам.


Aug 8, 2011

Scrum Lego Simulation
или "Я знаменит?!"


Только что на agile2011 встретил парня из Перу. Первое, что он спросил, после того, как узнал мое имя было: "а ты тот самый Алексей, который придумал Скрам симуляцию с Лего?".

Пришлось признаться :)

Вау, я знаменит?!

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

PS Два дня спустя проект запущен! lego4scrum.com

Offshore Outsourcing with Scrum


Только что узнал, что мой доклад Offshore Outsourcing with Scrum. A body of knowledge on managing offshore teams также принят на конференцию Agile Tour в Вильнюсе. Ура!

Осенью я буду выступать на, как минимум, трех конференциях:

Jul 23, 2011

Самокоучинг коучинга


Вернулся из Москвы, где провел последнюю неделю, консультируя по процессам одну крупную IT компанию.

Я оцениваю свою работу как 6 из 10. Почему? Потому что, я мог бы принести намного больше пользы. Хотя, все же, вспоминая неделю, я сделал лучшее из возможного. Имея то, что было мне дано.

Часть вещей, которые мне удалось сделать, я вообще никак не планировал. К примеру, я ехал совсем не для того, чтобы:
  1. Помочь одной команде научиться программировать из Ruby UI-тесты на Selenium.
    Нам вместе это отлично удалось, не смотря на сложность и динамичность интерфейса. Добавляю этот пунктик себе в резюме :)
  2. Научить другую команду писать unit-тесты в Java в стиле test-driven.
    Двухчасовой экскурс в TDD был весьма кстати. Мы даже смоги вырефакторить нетривиальный кусок кода и обложить его тестами. И это все в режиме real-time, работая в паре над кодом, который остальные видят на проекторе.

    (Оффтоп: москвичи слово "тесты" произносят с буквой "е", а не "э" как мы украинцы, выходит забавно и похоже на "лепим тесто". Ну в итоге, налепились бы достаточно :)
  3. Настроить Jira для процесса, переходящего на инкрементальную разработку.
    За часа полтора была настроена базовая конфигурация проекта, созданы разделяемые фильтры, участники проекта научились визуализировать состояние итерации.
  4. Классифицировать проекты по разрабатываемой модели зрелости процессов разработки и компаний. Об этом уже пишу отдельную статью на scrumguidesc.com.
Эти четыре достижения недели я считаю самыми важными. Хотя, они далеки от начального плана - запустить два проекта по Скрам.

Почему так вышло?

Команды не были готовы к моему приезду! Меня позвали, но каким-то образом команды не были готовы.

Что мне оставалось, так делать art of possible, адаптируясь на местности. По-моему, получилось всё же очень полезно. Не зря же мы - Agile. "Pray what you preach" - как говорят.

Что же я вынес из этого на будущее?
  • Коуч должен активно вести процесс подготовки проектов к коучингу.
    Оказывается мало оговорить цели коучинга с руководством. Нужно быть на постоянной связи с компанией и помочь ей правильно подготовиться к коучингу, чтобы получить максимум пользы.
  • Коуч должен возить с собой всегда всё необходимое.
    Так, чтобы в чистом поле, если придется, запустить проект или провести сессию стратегического планирования.

    Единственное, что я с собой не возил раньше - это бумага для флипчарта. Но есть ситуации, когда ее очень не хватает – на пример, когда нужно быстро сотворить настенную доску для визуального планирования (в чистом поле).
  • Ну и конечно be more bold.
    Этого никогда много не бывает. Когда вы приходите в новую компанию, где бытуют десятки ложных убеждений («ну нас это не получится»), без того, чтобы быть громким примером неуклонных изменений – никак. 
Коучинг приносит плоды. Даже когда, его никто не ждет. В этом его сила! :)

Jun 25, 2011

#ALE2011 - дайте микрофон!


Подал две заявки на выступления на ALE 2011.
  1.  "Simulated Enterprise Scrum with LEGO"
  2.  "Offshore Outsourcing with Scrum. A body of knowledge on managing offshore teams"
Процесс ревью докладов на ALE - публичный и массовый. Прошу всех, кому интересно, поучаствовать в ревью.

Jun 21, 2011

Что я вынес с AgileCamp и вывез из Самары? Часть два

 Вы не читали первую часть? Так сделайте же это немедленно! :)

Agile и UX, Usability, Interaction Design, User Interface Design. Или может ну ux?

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

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


В чем же проблема, спросите вы? А вот в чем:  

Designers think in screens.

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

И таких экранов, ну, скажем два десятка. Такой себе средне-сложный сайт.

А теперь представьте как подобный дизайн будут пилить верстальщики и программисты.

И как же? Правильно - сайт будет разрабатываться screen by screen.

«И шо такое?» спросите вы. А то, что бизнес требования и их приоритеты обычно перпендикулярны скринам. А именно, несколько user stories разных приоритетов могут сидеть на одном и том же скрине. Или же, что более вероятно - одна история будет проходить сквозь несколько скринов, как workflow.

Для примера вы можете представить себе типичный заказ чего-то на веб-магазине:
«As a first-time user I want to buy a book so that it got delivered to my home».

Даже у амазона в один клик это займет пару скринов, на которых кроме собственно элементов, поддерживающих процесс покупки товара будет расположено много-премного всякого разного из серии my profile, my wish list, my last orders, my friends’ wishlists  и прочие неважности.

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

Такой подход натурально порождает задержки выпуска релизов. Ситуации, вроде "75% функционала готово на 75%", невозможность приемочного тестирования функционала, уход от концепции lean startups и прочие смертные грехи. 

It is waterfallic.

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

У вас есть решения? успешные примеры итеративной верстки? яркие страшилки завала проектов из-за screen-thinking? Не стесняйтесь подавать свои доклады, писать статьи, вести блоги. Это сейчас крайне нужно индустрии. Это как agile 15 лет назад. Мы все еще там в процессах дизайна. O-la-la.

Что я вынес с AgileCamp и вывез из Самары?


Сижу в аэропорту в Самаре, жду посадки, хочу домой.  Думаю о последних четырех днях, проведенных в энергополе agile на чудесном AgileCamp (#agilecamp).


Кемпы рулят

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

Большой респект и уважуха визионерам кемпа – Никите Филиппову (@nfilippov) и его коллегам из ScrumTrek.

By design, господа и дамы, посетившие секцию бизнеса, должны были научиться:

  • паттернам организации Enterprise Scrum и подводным камням такого процесса;
  • построению командного видения продукта при помощи product box-ов из Innovation Games.
  • story mapping как подходу детализации бизнес модели, пользователей и их ожиданий от технического решения;
  • бумажному прототипированию;
  • демократичному риск менеджменту.
Теперь о том, чему научился я.

Йуху! LEGO симуляции масштабируемы!

With a little help from my friends, мне удалось смасштабировать LEGO симуляцию Scrum процесса на 96 человек. При чем, все участники работали над единым продуктом.

Вау!

Гляньте на чуток слайдов и фоток, чтобы получить представление о том, как это было. Я в захваті.

Правила игры еще требуют доработки напильничком. Но как для первого раза, я очень доволен. Буду симулировать подобный процесс на всех возможных конференциях, где мне смогут дать 120 минут на сессию, столы, возможность обклеить 20 метров стен и чуток людей :)

Бумажное прототипирование

… должно включать создание прототипов из бумаги :)

Это два.

Чем проще процесс, тем легче. Мы долго обсуждали тему контейнеров и прочие наукообразные инструменты, которые используют ux-дизайнеры (есть такие звери) для систематизации своей работы. Мне кажется, что нами меж литров Жигулевского был нащупан здравый смысл.

Итак трезвый остаток: когда мы фасилитируем процесс донесения видения продукта, проводя владельцев бизнеса и команду от бизнес модели к user persona через story mapping и прототипы, - у нас как коучей должна быть одна простая цель: создать поле общего понимания целей проекта.

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

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

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

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

Такие мысли по поводу прототипов.

Отдельным постом напишу об  

Agile и UX, Usability, Interaction Design, User Interface Design.

Так это был для меня личный hot spot кемпа.

Чмоки!

Jun 14, 2011

Как мы запускаем Скрам проекты

Заметки с передовой SCRUMguides.

Автор: Алексей Кривицкий

Последнее время (больше года) активным спросом пользуется пользуется наша программа Скрам для команд: тренинг + запуск проекта от 3 до 5 дней.

Почему эта программа так популярна? Думаю, что отчасти из-за того, что мы акцентируем свое внимание на реальном проекте с его контекстом и всеми заинтересованными сторонами - от заказчика до команды.

В этой статье мы хотим поделиться тем, как мы это делаем. По порядку и с иллюстрациями.

ДИЗАЙН ПРОЦЕССА

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

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

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


Зачем это обсуждать?

ЧИТАТЬ ВСЮ СТАТЬЮ >>>

Jun 10, 2011

Тренинг с Никитой Филипповым


В Эстонии на AgileSaturday я чуть-чуть помогал Никите Филиппову (ScrumTrek, Россия) проводить его воркшоп по story mapping. Это прекрасная техника, заслуживающая отдельной статьи (уже пишу).



В результате мы решили с Никитой провести в Самаре после AgileCamp однодневный мастер-класс со скромным названием :


Это мой первый тренинг с Никитой - будет интересно всем!

А вот чуть фоток из Эстонии:


Jun 2, 2011

Конференция AgileBaseCamp, Днепропетровск


Буду выступать на AgileBaseCamp в Днепре, 2 июля.

Готовлю две темы:

  1. Доклад “Project Estimates, мать их!”
  2. Воркшоп “Конфликтовать полезно! Углубляем демократию в Agile-экосистеме“
Доклад “Project Estimates, мать их!”

Хочу говорить за оценки. Наболело. Я уже давно ищу ответы на вопросы:

Чего больше в оценках – мусора или выгоды? вреда или пользы?
Когда начинается неполезный перекос?
Можно ли вообще обходиться без оценок?

Я намереваюсь дать пару десятков советов из своего опыта и помочь вам сделать процесс оценивания минимально болезненным и максимально полезным. А не наоборот. А может и отказаться от оценок вовсе!

Воркшоп “Конфликтовать полезно! Углубляем демократию в Agile-экосистеме“
Что вы будете делать, когда рабочий процесс пренебрегает интересами меньшинства группы?

Что, если вы - это самое меньшинство?

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

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

В этом воркшопе Алексей поделится краткими основами Глубинном Демократии, её взглядам на конфликты, а затем... А затем, аудитория сможет попрактиковаться в разруливании типичного конфликта, который может возникнуть в Agile команде.

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

May 25, 2011

От Кащея Бессмертного до Робин Гуда. Или стадии Скрам-мастерства


Кто вы как Скрам-мастер: Кащей-бессмертный? Чип-и-Дейл? Или Робин Гуд?


Я недавно нашёл метафору стадиям вовлечения Скрам-мастера в проекты.

Фаза первая. Кащей-бессмертный

Вы недавно стали использовать Скрам? Прошла пара-тройка-пятёрка спринтов? Без вас всё валится?
  • Вы не пришли утром на работу (были у зубного) - команда пропустила свой daily-митинг.
  • Вы не подумали провести ознакомление с беклогом следующего спринта - планирование заняло три дня.
  • Вы уже два дня не обновляли sprint burndown - никто про него даже и не вспоминает.
Это ОК! Вы в стадии Кащея Бессмертного, который над "златом чахнет". Чтобы было злато - нужно ежедневно над ним "чахнуть". Чтоб делался Скрам - нужно ежедневно стоять у штурвала. Нет вас - нет Скрама.

Но может вам всё таки удалось донести полезность Скрама, зажечь кого-то в команде, донести до заказчика прелесть подхода?

Фаза вторая. Чип-и-Дейл

Тогда, вы становитесь Чипом-и-Дейлом!

При чём - обоими в одном лице )

Ваша загрузка в проекте как Скрам-мастера уже не 100%, а скажем 70 или 60. Вы уже можете себе позволить пропустить раз в неделю утренний митинг (не для зубного, а для проверки "скрамности" команды), и команда его проведёт без вас. Да ещё и доску обновит!

Во класс!

Но иногда случаются пожары. HR выдёргивает вашего коллегу на полдня на интервью. Или заказчик решает за ночь перелопатить план спринта. Или, к примеру, закончились жёлтые стикеры. Тогда доблестные Чип-и-Дейл приходят на помощь!

Фаза третья. Робин Гуд

Но может вы были настолько хороши в образе Чипа-и-Дейла, что заразили примером других?

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

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

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

Многие и нас навсегда остаются в роли Кащея для своей команды. А зря - Робин Гудом быть куда приятнее. К тому же это даёт  время заняться другими командами или прилегающими отделами, которым может быть как раз Кащея сейчас и не хватает.

Scrum.WTF: Визуальные доски. Забить или прибить?


По следам доклада на Agile PechaKucha vol.2.

Один из WTF-ов, которые меня одолевали последние годы, и который я совсем недавно смог для себя разрешить.

И так, речь про доски задач.


А дилемма с ними такая :


Я вижу много (нет, реально много) команд, которые не используют доски по причине удаленности заказчика. Говорят: "мы не можем планировать на стене, так как наш Властелин Продукта удалён, и мы поэтому используем _____ (вставьте название любого тула)".

Но по моим впечатлениям не более 20% команд, которые себя называют "распределёнными" - по-настоящему распределены. Чаще всего - они просто отделены от своего PO, но сидят всей командой одной комнате.

Если вы просто отделены, то вам это нисколько не мешает планировать спринт на стене.

Как это сделать?


Очень просто - разделите сущности :

  • план команды на спринт - на стене в виде доски (информационного радиатора), 
  • а вот беклог релиза (с статусами историй и прочей статистикой) - в тулзе, так чтоб многоуважаемые удалённые господа могли обновлять в любое удобное время где бы они не находились.
Просто? Да. 

Дополнительный плюс - PO не сможет явно микроменеджить команду, messing around с её планом на спринт. 

Нужен статус? Спроси. Ну или если уж очень часто нужен - можно поставить веб-камеру в комнате команды с видом на доску. Ну или устраивать ежедневный созвон для обмена статусами. 

Но доска при этом сугубо инструмент команды, сделанный ею для самой себя.

Такой вот Scrum.WTF

May 23, 2011

Dvija

На сей раз не об Agile!

Зову всех на концет группы Dvija, в которой ваш покорный слуга играет на четырех струнах

May 20, 2011

PechaKucha done



Выступил на Agile.PechaKucha 19 мая, Киев.

Немного стрессовый формат 20 слайдов по 20 секунд на каждый. Но зато, если вам не понравился докладчик - ждать всего 6 минут 40 секунд  :)

Мой доклад, судя по отзывам в куллурах, понравился! Я уже выступал с этой темой на AgileBaseCamp и опубликовывал slidecast. На этот раз раскрыл еще пару вотзефаков.