Agile Labs

Отчёт о конференции

Agile Labs, Moscow

Собираюсь выступить на http://agile-labs.ru/.

Расскажу про 

• то, как решить проектные челенджи с Agile
  
• проведу часовую Скрам симуляцию с Lego

My submissions for Agile2009

Наконец-то дошли руки опубликовать две сессии для конференции Agile2009:

• Practicing multi-team Scrum with Lego 
• Distributed Development and Agile: the view from the offshore side
• Pull vs. Push Systems: why we need cross-functional teams 

Осталось, чтоб их теперь отобрали :)

Repeatable vs effective

Вчера, провёв отличный весёлый вечер с двумя CTO харьковских IT компаний, мы горячо обсуждали evolutionary design vs. design upfront.

Или по-русски: что лучше:

а) быстро выпустить то, что нужно сейчас, тем самым повысив вероятность переработок потом, но получить при этом обратную связь и подкорректировать курс проекта?

б) либо же - разработать продуманную гибкую архитектуру, которая с большей вероятностью сможет вместить новые требования?

Тема стара как мир (новый IT мир, я имею в виду).

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

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

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

Меня спросили, не то ли этого (повторяемость процесса) чего я добиваюсь от компаний, коуча Scrum. Я подумал, и сказал, что нет.

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

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

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

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

Это моё IMHO на сегодняший день, 7 ноября 2008 года.

Читать обсуждения этой темы в группе AgileUkraine

Неделя коучинга или море общения и креативности

Вот практически и завершилась неделя коучинга в Харькове.

Диалог на выходе из комнаты, где работает команда:
- Они это сделали!
- Кто они?
- Конечно же команда!


Фотоальбом

Что же мы успели:

• обсудить концепции Agile и Scrum;
  
  
• сойтись на главных плюсах, которые этому проекту может дать гибкая разработка;
  
  
• посимулировать анти-командность на примере "фабрики" по производству бумажных самолётиков конвейерным способом (push/pull системы);
  
  
• поиграть в симуляцию Scrum
  (ребята проявили недюжую креативность, создав настольную игру и за 2 итерации удовлетворив своего PO);
  
  
• поиграть в игру ball points (которую я увидел впервые на прошлом CSM у Робина Даймонда) - цель игры дать возможность команде улучшить свой процесс; оказывается всего 3 минуты коллективного общения команда может улучшить свою эффективность почти вдвое; и предела этому нет (Kaizen mind);
  
  
• научиться писать user stories;
  

Но это не всё!

• ребята оговорили и описали product vision (теперь, это лист формата A2, который висит на стене и напоминает цели проекта, основные фичи, конкурентов, риски);
  
  
• ребята помогли своему PO сгенерировать беклог историй (который оказался полнее и лучше структурированным, чем изначальный беклог, подготовленный РО);
  
  
• оценить беклог, уловив прелесть от использования planning poker;
  
  
• сойтись на критерии done" для своего проекта;
  
  
• выполнить планирование первого спринта.

Демо - не за горами. Но надежд много!

Увидимся.
Харьков, 1:42 am, уже пятница! :)

Смелость vs. профессионализм

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

Я не на столько смел. Я использую Agile, который предоставляет мне контейнер для понижения проектной сложности - итерации фиксированной длины и фиксированного объема работ. Это даёт мне уверенность на ежедневном уровне.

"И главное - сухо!"

Я не на столько смел, чтоб разрабатывать продукт слоями. Вместо этого мы пишем фичами.

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

Я не на столько смел, чтоб давать заказчикам обещания. Вместо этого мы им показываем release burndown, и они решают, куда вести проект.

Смелость - отсутствие профессионализма.

Impossible is nothing или конференции, конференции, конференции

В этом году посетил 3 крутейших ивента по agile, не считая тех, которые организовал сам (гы!):

• Agile Coach Camp, Мичиган
  
• Agile 2008, Торонто
  
• Scrum Gathering 2008, Стокгольм

Если бы мне кто-то сказал в начале года , что это случится, я бы не поверил. Удалось увидеть воочию пять подписчиков Agile Manifesto. Отличные ребята! :) C тремя (Ron Jeffries, Brian Marick, Ken Schwaber) познакомился лично, пропиарил Agile Ukraine (как полагается).

Это всё произошло благодаря другу из Индии Naresh Jain, которого я пригласил в Украину в апреле для участия в конференции Agile Gathering IV и проведением классов по XP.

Как оказалось, на каждой конференции нужны так называемые волонтёры (проще помощники). Работы не много: отнести флипчарт, прискотчить плакат, раздать-собрать feedback формочки и прочее. Даже интересно - видишь изнутри, как организовываются подобные конференции. Такая работка экономит пару тысяч долларов (такова цена входного билета на большинство конференци, увы).

Лучший вариант, однако, попасть туда бесплатно - это провести сессию (доклад, воркшоп, прочее). Что ж, будем работать и над этим. Всё постепенно. Стоит увидеть доклады как зритель перед тем, как решаться выступать.

Думал поехать на QCon в Сан Франциско и посмотреть на Кента Бека и Мартина Фаулера. Но решил отложить. Зато пристроил друга в волонтёры. Крутизна.

Хотелось бы в следующем году привезти на Agile 2009 (Чикаго!) с собой группку из Agile Ukraine. Буду над этим работать!