А именно:

• у менеджмента появилось чёткое понимание "новой компании", которую они хотят построить
• компания была побита на бизнес линии (одна основная с 5-ю командами и вторая экспериментальная с одной командой)
• владельцы и совладельцы (C-level) выработали стратегию перехода
• все в компании, кого эти изменения затрагивают, смогли внести свои коррективы, пожелания и в итоге прийти к консенсусу
• детали новой организационной структуры выработаны, найдены люди на новые роли (к примеру настоящие ProductOowner-ы)
• сформированы новые кросс-функциональные команды
• стартовал первый спринт!

Фактически, мы делаем LeSS.

Но что дальше, после старта спринта на все команды?

Я описал вкратце коучинговый план для своих спонсоров (это CTO и CPO).

Эта статья описывает подход построения долгосрочных и среднесрочных планов развития продукта и составлена по следам проведения двухдневного воркшопа в украинской продуктовой компании IPLand коучами из Scrum Ukraine.

Читать всю статью >>>

Мои обе книги по ретроспективам "Быстрый старт в agile ретроспективы" и "Сила интервенций в agile коучинге" доступны для бесплатного доступа с сайта компании Scrum Ukraine!

Качайте и пользуйтесь на здоровье.

Мой класс для Владельцев Продукта (Product Owner, PO) сильно отличается от большинства классов по этой тематике, которые я видел. Это не класс "Скрам для Владельцев Продуктов", где тренер использует свои "стандартные" слайды и лишь вставляет несколько терминов из контекста продакт-менеджмента.

Я стремлюсь, чтобы мой CSPO класс на  85-90% отличался от моего класса для Скрам-мастеров (CSM). Во-первых: участники нередко посещают оба (так что ни одна игра или симуляция не дублируются), во-вторых: этот класс нацелен на другую аудиторию, он даёт другие навыки, хотя нередко посещается Скрам-мастерами и членами Команд Разработки, которые хотят разобраться и начать помогать своим "продуктоводам".

Тренинг проходит под лозунгом "from idea to release roadmap", и я ставлю своей задачей наглядно, на примерах и повторяемых упражнениях показать участникам, как они могут взять практически любую идею продукта и разложить её на столько, что уже завтра можно начинать валидировать первые гипотезы и общаться с командой о рисках, технологиях, ключевых фичах. Хороший Владелец Продукта всегда имеет большой, видимый, известный всем и сделанный со всеми план релиза - долгосрочное видение развития продукта.

И это никак не беклог в джире, уж простите меня. Джиру можно использовать, на свой страх и риск, но не стоит путать "список айтемов" с ясным и согласованным со стейкхолдерами и командой видением развития продукта.

Мой класс - о том, как это виденье строить, валидировать, обновлять и коммуницировать всем вокруг. И также о том, как вписать эти активности в ежедневные Скрам рутины. Это важно. Ниже - детали.

Условно класс состоит из шести частей:

Infoq был годами ресурсом, где я вдохновлялся видео с разных мировых конференций. В 2016 я выступил на Lean Kanban France (#lkufr2016) и infoq записало и выложило видео и слайды моей сессии. Крутотень!

Выступал я совсем не о Lean и Kanban. Говорил я о сложности организаций и о том, как с этим работать.

Смотреть видео.

Оригинальная статья Рона Джефриз (Ron Jeffreies) "Dark Scrum".

Переведено с разрешения автора.

Давайте поговорим о так называемом «Мрачном Скраме». Слишком часто, по меньшей мере в разработке ПО, создаётся впечатление, что Скрам угнетает людей. Слишком часто Скрам не приносит результата так быстро, надёжно и постоянно, как должен был бы. В результате - все страдают. И  чаще всего сильнее чем все остальные страдают разработчики.

В последнее время я часто размышляю над следующим: 

В мае мы провели третью встречу Scrum Master Club. Эта встреча была посвящена работе с культурой компаний. Неисчерпаемая тема. Все мы хотим поменять культуру компаний к лучшему. Но как?

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

Посмотрите на два приведённых ниже фото - какая культура более гибкая?

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

Так, на недавней встрече украинских аджалистов "Agile Pizza" (я сам не был, но следил в соц сетях и мне пересказывали живые свидетели), говорилось с аргументацией о том, что, мол,  "эх, жаль, agile не работает а аутсорсинге".

Agile - странная вещь.

Я еще помню 12-15 лет назад, как agile не работал совсем.

Затем, 5-7 лет назад - о том, как он не работает в банках.

Потом в гейминге и гейблинге.

Совсем недавно - о том, как в гос структурах его нет и не может быть.

Что же не так с этим аджайлом - он всё время где-то не работает.

Может позвонить в ЖЭК и вызвать мастера. Или вернуть по гарантии пока не поздно?

Оказывается, agile не работает не только в аутсорсинге.

На прошлой неделе один немецкий agile-коуч мне сказал (и об этом также есть скандальная статья), что agile не работает в немецкой культуре из-за любви к предсказуемости. (Жаль, что ребята из Zalando, jimdo, XING, Flixbus об этом не знают.)

Французы считают, что из-за своей любви к иерархии и сплетням, agile культуре на одних круассанах не прорасти.

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

За то все как один соглашаются с тем, что где-нигде, а в Скандинавии аджайл работает "на ура". Там он сокультурен их плоскому менеджменту, личной ответственности и трудолюбию. Почему же мне было так тяжело стартовать Скрам в 2004 в одном датском проекте? Тогда на старт первого спринта ушло полтора года!

Здесь что-то не так. Не находите? 

В аджайле не работает не более четырёх вещей одновременно.

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

1. менеджеры давят на народ процессом, ограничивая свободу улучшений
2. у команд не выходит (каменный цветочек) выпускать хоть сколько-нибудь рабочий продукт, хотя бы раз в месяц
3. заказчики далеко, и им на нас наплевать
4. менеджеры строят планы, не выходя из home-офисов и декретов

Что ж. Так бывает. Что из этого вызвано именно аутсорсингом? Возможно, как минимум третье. И от части -первое.

Продакт Оунер - как часть контракта. Pourquoi pas?

Не так давно я слышал историю о том, как сиклумовские ПМы, годами оттачивая контракты, смогли наконец-то там чётко прописать роль Владельца Продукта со всеми сопутствующими обязательствами. И они не только прописали её в новые контракты, которые используют сейлы, но и обновили контракты существующих аккаунтов. Пурква бы и не па?

Таких историй много. Более громких и менее громких.

То тут, то там я слышу, как заказчики распукают QA-отделы на Филиппинах и в Индии, и нанимают тестировщиков-автоматизаторов в свои nearshore-рные команды. Пурква бы и не па, в конце-то концов?

А может мы смотрим не в ту сторону бинокля?

То тут, то там практика continuous delivery становится реальностью...

Заказчики соглашаются с наймом локального командного коуча...

Кто-то на выходных настраивает первый раз за историю компании сервер сборок...

Где-то впервые за года разработчик и тестировщик вместе пишут тесты...

В офис тихо заносится первая маркерная доска...

"Scrum is the art of possible".

Эти микро-инновации процесса могут казаться очень незначительными. Но они имеют вес только внутри своего контекста и не могут быть вырваны из него без потери масштаба.

Нет, эти нано-изменения - не финальная победа. Это маленькие инкрементально-итеративные победки, победочки и победульки.

Но разве не в этом состоит суть agile-мышления? Понемногу, где можно и когда можно, менять свою среду своими руками.

Очень давно, на моём первом тренинге для Скрам-мастеров (2007 год), тренер сказал "Scrum is the art of possible". Это очень важная фраза. Она важнее всех фреймворков и ролей. Это про делать то, что сейчас возможно, не смотря на всё остальное, что (ещё) неподвластно.

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

Это про то, чтобы говорить "в этом году (квартале, спринте) мы чуть более agile" вместо того, чтобы сдаться, сказав: "тут аджайл не будет работать". 

C'mon guys!

Вау новость: мы с Наташей Трениной проводим класс в Минске.

Один класс, два тренера.

Ловите нас 3-4 августа на Certified ScrumMaster.

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

После десятилетий изучения команд мы точно уверены в одном - команды меняются, их динамика скоротечна и плохо предсказуема.

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

И наоборот.

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

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

К слову, я влюбляюсь в каждую команду, с которой работаю. Это, наверное, звучит сверх-романтично, но это так. Командной работе присуща магия, которую невозможно ни предопределить, ни описать. В командах происходят вещи, на которые коуч только и может что надеятся. Но они происходят каждый раз: то вдруг кто-то ни с того ни с сего возьмёт на себя роль фасилитатора недопонимания на совещании и вы, как коуч, только и будете что ахать, не ожидав такого взлёта; то вдруг кто-то вызовется помочь другим в чём-то разобраться безо всяких там “стендапов” или наводящих вопросов; то вдруг тихо и безо всяких предупреждений, кто-то возьмёт и наладит что-то, что вы как коуч уже и не надеялись, что в этой команде когда-то заработает… Вещи происходят. В своей динамике и с присущей магией. Не было команды, которая бы меня не удивляла и не дарила удивительные сюрпризы.

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

Если очень коротко, то, когда я работаю с командой в качестве командного коуча я как бы выбираю один из пяти стилей (режимов, уровней) работы, чтобы не задавить внутренний потенциал, но увидеть его и помочь проявится:

1. Встретить команду на её уровне

2. Показать команду самой себе

3. Поднять команду над “уровнем моря”

4. Зародить новые привычки

5. Дать команде вести себя дальше

Каждый режим работы подразумевает свой вид и стиль интервенций.

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

И так, пять уровней, пять шапок. Самое сложное конечно же знать, какие носить в каких случаях, а какие нет.

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

Как мы и планировали - в апреле в Киеве прошла "Неделя Скрама" - две встречи и два тренинга, включая первый в Украине тренинге по Large-Scale Scrum.

В рамках двух встреч "Клуба Скрам Мастеров" выступил:

• Алекс Шевчук - скрам-мастер из Сиклума с теорией о развитии команды
• Грег Хатчингз - тренер по LeSS с докладом о принципах масштабирования Скрама на всю организацию
• Алексей Кривицкий - тренер по Скрам с воркшопом о радикальных изменениях

Материалы собраны ниже.

Ждём всех на очередной встрече.

Моё выступление на главной (она же "гнучка") сцене PM Day Kyiv 2016 прошло под знаменем сложности, спагетти и японской поэзии.

Ниже - избранные фото и слайды, ещё ниже - полная презентация. Видео в процессе - ждём с нетерпением.

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

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

Вторая - это не так часто употребляемое "Kaikaku ("радикальные перемены"). Остальные 80% улучшений достигаются, к нашему всеобщему удивлению, именно через внедрение радикальных практик.

К слову, Скрам - это каркас процесса, который прививает философию Kaizen через постоянные циклы инспекции и адаптации. Ретроспектива - это собственно процессная церемония для практики Kaizen-мышления.

Что интересно, само внедрения Скрам - это по своей сути Kaikaku! Так как Скрам не внедряется по кусочкам (делал, не советую), а требует системных структурных измененией (к примеру построение кросс-функциональных команд).

Мои слайды с воркшопа на AGILEEE 2017 по масштабированию Скрам.

Статья написана на основе slidelog доклада. 

Расскажу о трёх вещах: прошлом, будущем и настоящем.

Хочется начать с личной истории. Почему? Да просто потому, что она у меня есть!

На заре моей карьеры я работал в одной компании.

Её названия я не могу назвать здесь. Могу лишь сказать, что оно начиналось на «мира-» и оканчивалось на «-тех». Эта компания  меня вырастила: взяла как полу-разработчика и дорастила до менеджера. Я ей очень благодарен.

Но речь не об этом.

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

Я ушёл.

Но, перед тем как уйти, я распечатал на корпоративном принтере две книги.

Когда впоследствии я стал миллионером, я купил их на амазоне. Вот одна их них: Agile Software Development Элистера Коуберна (Alistair Cockburn).

Я лежал в своей квартире на матрасе (тогда у меня ещё не было диванов) и читал эту книгу.

Она изменила мою жизнь. Я понял: «Вот оно! Вот ответ на вопросы, которые я даже не знал как задать». Эта книга изменила меня. Agile изменил мою жизнь. Я стал тем, кто я есть сейчас.

Шесть лет спустя, сида на том же самом месте, где я когда-то лежа читал книгу Элистера, я получаю имейл. Имейл от самого Элистера Коуберна: он принимает наше приглашение и едет в Киев.

Тот самый Элистер Коуберн едет в Киев. Вау!

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

Но начнем пока с «начала».

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

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

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

Таким образом ситуация пошла против природной нестабильности требований к ПО. 

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

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

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

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

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

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

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

Давным-давно, обсуждая с коллегами по agile движению, что для программистов означает «agile», я пришёл к следующим выводам:

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

Хорошие отношения — это интегральное понятие, которое подразумевает также профессионализм и доверие, без которых упешная кооперация между людьми невозможна.

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

Если же хорошие отношения не гарантируют наличие agile среды, то должно быть значит что-то ещё, что выделяет эти проекты из ряда других. Я делаю предположение, что это —

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

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

Статья от 03/2007

Что ещё важно понимать для развития agile среды в команде?

«Разработка ПО — это игра изобретательности и кооперации»

Элистер Коуберн

Сразу хочу предупредить, что эта история об историях весьма объёмна. Так сказать, лонгрид из личного опыта.

Скажу честно, пока я не прочел книги Майка Кона, я не верил в то, что этот подход жизнеспособен.

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

Мне кажется, я был не одинок.

К тому моменту, когда мне попались книги Майка, мой проект уже работал по Scrum, и я, видимо, уже созрел для восприятия более «крутых» тем из agile. Одной из таких тем для меня стали пользовательские истории.

Как и все другие идеи из agile, идея историй (если отбросить все предубеждения) весьма прозрачна и логична. Как говорят: «It’s about common sense».

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

Итак, вместо того, чтобы тратить время на написание, согласование и обновление спецификаций о требованиях к будущему продукту, заказчик делает короткие высказывания о том, как пользователь будет пользоваться будущей системой. Будучи собранными в том или ином виде, эти высказывания используются для последующих обсуждений с проектной командой. В ходе обсуждений начальные идеи, заложенные в первоначальных высказываниях, обрастают деталями. Такими деталями является всё, что поможет команде во время реализации истории помнить о нуждах пользователя, — это различные уточнения, ограничения, немаловажные критерии готовности.

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

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

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

Итак., как же проводить ретроспективы?

Базовые материалы по СКРАМ говорят, что после спринт ревью митинга (или, проще говоря, демонстрации результатов спринта) команда собирается на ретроспективный митинг, где обсуждаются следующие вопросы:

Это же касается ретроспективы по окончанию релиза или другой фазы проекта.

Для простоты я рассматриваю ретроспективы, привязанные к окончанию спринта.

При попытке проведения ретроспективы по вышеописанной структуре, многие команды:

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

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

А что, если ничего не будет сделано? В следующий раз команда cгенерирует очередной список, и так до тех пор, пока практика ретроспектив справедливо (для такого типа ретроспектив) не будет объявлена бесполезной.

Что же здесь не так?

Расскажу вам историю о том, как мы с коллегами-аджалистами несколько лет назад решили обсудить следующий философский вопрос: «Чем является Скрам: не более, чем инструментом или чем-то большим?»

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

Обсуждение началось с поста статьи Тобайаса Мейера (Скрам-тренера, фасилитатора и анархиста) под названием The People's Scrum, где автор утверждает, что он не согласен с теми, кто ставит Скрам наравне с такими инструментами как Канбан. И что (дословно):

To reduce it to “a tool” is to completely miss its magic, and to bring us back into a world of best practices and repeatable process.

Уменьшать Скрам до размера «инструмента» — это всё равно, что полностью упускать его волшебство и возвращаться в мир «передовых практик» и повторяемых процессов.

Это запустило активный поток дискуссий в нашей группе, к которой я приложил (готов это признать) свою нечистую руку.

Поясню.

Мне довольно часто задают следующий вопрос: «Что делать с историями, которые не полностью сделаны за итерацию?».

На мой взгляд, есть следующие варианты:

1. История не полностью сделана, и сделанная часть НЕ несет выгоды для заказчика

= Business value not delivered

В этом случае логично сделать следующее:

• Вернуть историю в беклог;
• Не учитывать сделанную часть работы при подсчете velocity команды в текущей итерации;
• Переоценить историю, если она оказалась значительно больше, чем думалось;
• Задуматься об разбиении этой истории на мелкие значимые истории, чтобы не повторилась такая же ситуация в следующих итерациях (тема для ретроспективы);
• Не откладывать историю в «долгий беклог», а продолжать работать над ней в ближайшую итерацию, пока свежо. Но это уже, конечно, решение, которое примет Product Owner.

2. История не полностью сделана, но сделанная часть несёт выгоду для заказчика

= Business value delivered (but partially)

В этом случае можно:

• Зачесть историю как сделанную. При этом обновить описание истории, указав, что именно сделано, какие тесты проходят;
• Создать новую историю (или ряд историй), описывающих недостающие требования;
• Переоценить историю и учесть её при подсчёте velocity текущего спринта.

Продолжаю цитировать перевод новой книги по #LeSS:

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

В крупных организациях обычно имеются отделы контроля качества и технологических процессов, сотрудники которых носят черные пояса Шести Сигм и занимаются проектами по усовершенствованию.

Или даже лучше - в некоторых организациях существует отдел трансформаций.

Избегайте их!

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

Законы Организационного Поведения Лармана гласят следующее:

1. Организации неявно оптимизированы, чтобы избежать изменения существующего порядка вещей (статус-кво), сложившегося среди руководителей среднего и нижнего звена, в должностях узких специалистов и во властных структурах.
   
2. Как следствие из первого закона: любая инициатива внедрения изменений будет сведена к переопределению или перегрузке новой терминологии, которая будет, по существу, обозначать то же самое что и существовавший статус-кво.
   
3. Как следствие из первого закона: любая инициатива внедрения изменений будет осмеяна как “пуристская”, “теоретическая”, “революционная” и “требующая прагматичной адаптации под локальные потребности”, что отвлечет внимание от устранения слабостей в сложившем порядке вещей среди руководителей и специалистов.
   
4. Культура следует за структурой.

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

Внедрение LeSS

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

...

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

...

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

Это становится тенденцией:

— «Алло. Нам нужны тренинги по Скрам!», - голос на том конце беспроводного провода.

— «Расскажите чуть подробнее...», — прошу я.

— «У нас несколько команд, которые работают по Скрам. Нуууууу, вернее, это не Скрам. Заказчики называют это Скрамом. На самом-то деле это очень сломаный процесс. Для этого нам и нужны тренинги. У нас небольшой бюджет. Хотим затренить 40 человек по полдня».

— ....

[продолжение] 

— «Ваши заказчики в курсе ваших планов по тренингам?», — чуть придя в себя, говорю я.

— «Нет! Они на это не пойдут. Они — крупная продуктовая компания. Мы хотим заказать тренинги для обучения своих, расширить их понимание процесса, промотивировать».

— ....

[продолжение] 

— «Я мог бы предложить вам тренинги для команд», — начинаю я. «Полдня — никак. Минимум — день. А лучше — два. Плюс отдельный тренинг для ваших Скрам-мастеров. Есть вариант сертификационного корпоративного тренинга. Это позволит вашим Скрам-мастерам лучше осознать свои функции и начать строить лучший процесс...».

— «Дело в том, — говорят мне, — что Скрам-мастера находятся на стороне клиента с разницей во времени в 7-10 часов и вряд ли они к нам приедут. Заказчики вообще пока что только раз приезжали. Так что нам тут нужен только тренинг для команд. И лучше все же полдня».

— «Как типично!», — говорю я, наливая себе 50 грамм успокающего.

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

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

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

И как же? Правильно — сайт будет разрабатываться 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».

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

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

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

It is waterfallic!

Дизайнеры, услышьте нас!

Нам нужно работать вместе. Это общая проблема, добавляющая рисков в и без того непростые современные проекты. 

Популярность Scrum продолжает расти.

Подтверждением популярности этого подхода в мире является стремительно растущее количество сертифицированных специалистов по Scrum.

Что же так привлекает всех в Scrum?

Во-первых, это видимая простота подхода. Scrum — это набор довольно несложных для формулирования правил, которые подчиняются законам здравого смысла.

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

Конечно, на этот вопрос приятно ответчать именно отрицательно. Мы ведь все герои! Намного сложнее признаться в наличии проблем, а тем более ещё и попросить о помощи. Это же прозвучит как громогласное заявление в своей некомпетентности перед всей командой! А если такое заявлять ежедневно — о, ужас!

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

У вас должны быть проблемы! Ежедневно. Если их у вас нет — вы делаете что-то неверно.

Что же делать, если команда морозится?

Я думаю, стоит изменить формат третьего вопроса.

Вместо закрытого вопроса (со всеми вытекающими): «Есть ли проблемы?», — или его открытого варианта (чуть лучше, но всё равно не то): «Какие у тебя есть проблемы?» , — я предлагаю использовать такой:

«ЧТО БЫ ТЕБЕ МОГЛО ПОМОЧЬ ЗАВЕРШИТЬ ТО, НАД ЧЕМ ТЫ СЕЙЧАС РАБОТАЕШЬ?»

Статься про такие вещи, как скрамтурбация и агиллюзия.

Откуда идут революции? Снизу, «из масс».

Откуда пришел Agile? Из первоклассных команд.

Но что, если менеджмент видит необходимость переменить процессы?

Как помочь команде «заразить» аджайлом верха?

Как избежать кровавых революций?

Работая коучами и тренерами, мы — мои коллеги и я — обычно наблюдаем в год 10-20 компаний, которые находятся на разных этапах аджализации. Есть очень много позитивных, вдохновляющих примеров.

Но есть и яркие анти-паттерны. Знание о них поможет вам не сбиться с пути.

Расскажу о двух самых опасных.

Но для начала — чуточку контекста.

Среди ответов (ура, я такой не один!) был ответ от Deborah Hartmann, известной в узких кругах Agile коучей и фасилитаторов. Ответ был прост: «Pomodoro? :-)».

Отшутившись, что мне нужен будет, пожалуй, их целый килограмм, я призадумался. Вот как это бывает — услышишь о чём-то, о чём уже давно знаешь, и вдруг как током пробирает: «Вот же оно. Помодоро!».

Эту штуку придумал некто Франческо Чирилло (Francesco Cirillo) в году эдак 1992-м. Маялся он как-то в университете от неусидчивости. «Мама мия!», — говорили ему его коллеги по кампусу: «Ты можешь хоть десять минут позаниматься не отвлекаясь?».

И вот как-то раз, проходя мимо кухни (откуда, конечно же, пахло базиликом, пармезаном, моцареллой, оливковым маслом, песто и чем-то ещё столь же прекрасным), он услышал звон заводного кухонного таймера. «Бинго!», — подумал Франческо, и через 15 лет написал книгу о тайм менеджменте на 45 страниц.

Начать использовать этот метод было довольно просто:

Что это дает? 

Это дает сфокуированную бесперебойную работу в течение выбранного времени.

Редкость в наше время.

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

Я когда-то работал в компании, где писали на .NET. И так вышло, что мне нужно было написать небольшое приложение на Java. Очевидно, что никто не собирался покупать лицензию для моего любимого IDE, так что приходилось пользоваться evaluation версией. Благо, она сохраняла файлы, выполняла рефакторинги, компилировала и отлаживала. Отличие её от обычной версии было лишь в том, что каждые полчаса работы она просила купить лицензию и прекращала работу. Приходилось следить за временем, так как перезапуск — дело скучное, особенно, если ты был на половине предложения, когда сработала система лицензирования.

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

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

К основной технике помодоро рекомендую добавить ещё одну вешь — коучинг-контракт. Перед запуском таймера (если нет таймера — можно использовать flash приложение), отвечайте самим себе на вопрос: «Что было бы для меня наилучшим результатом на ближайшие 20 минут?».

Такая вот полезная во всех смыслах история о помидоре.

Статья от 11/2009

Базовые основы и правила SCRUM просты для понимания. Мой опыт показывает, что объяснение сути подхода может быть сведено к пятнадцати минутам, в течение которых сторонний человек поймет все основные роли, артефакты и их связывающие правила. Это также касается людей, совсем не из IT сектора. Последние даже могут быстрее понять о чем идёт речь, так как лишены груза другого опыта.

Но он также и сложен. Его легко понять, однако, его тяжело применить. Вернее будет сказать — тяжело преодолеть те проблемы, которые становятся видимыми в проекте, где применяют SCRUM.

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

Почему же так сложно решить проблемы? Это сложно потому, что очень часто мы сами являемся частью этих проблем; то, как мы привыкли работать и создаёт эти проблемы. Решение же их лежит в изменении наших привычек, что и является большим препятствием. Зачастую бОльшим, чем сами проблемы.

«Вы всегда можете внедрить изменения. Вы всегда можете начать с себя. Вы всегда можете начать прямо сейчас», - так говорит Кент Бек, автор книг про eXtreme Programming.

А вот наконец-то, благодаря друзьям, вышел перевод моего эпического доклада "Убей в себе джиру!". Смотреть и слушать всем:

Всё двояко. Все имеет свои плюсы и минусы.

Оценка проекта: зло или добро? Трата времени или инвестиция?

Что лучше: код, которым владеет вся команда, или архитектура в надежных руках?

Самоорганизация команды или сильный менеджмент, основанный на опыте?

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

Если вдруг нет — рекомендую почитать.

Пару лет назад я придумал метафору для описания стадий вовлечения Скрам-мастера в проекты.

Скрам-мастер может быть одним из трёх образов: Кащей Бессмертный, Чип-и-Дейл или Робин Гуд.

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

«Метрики — это зло!», — так всегда открывает тему метрик Серёжа Дмитриев, когда на тренингах всплывает вопрос метрик в Скраме.

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

Большая комната.

Неисчерпаемый запас sticky notes для каждой новой истории или бага.

Прикреплённый скотчем на стену лист A2.

Лист поделен на несколько секторов, каждый сектор определяет состояние готовности размещённых на нём историй или багов.

У каждого из нас есть список из хотя бы нескольких WTF-ов, которые одолевают нас годами.

Один из своих я всё же смог для себя решить.

Речь пойдёт о досках задач.

После прочтения стаьи о коде этики agile-коучей, я довольно долго размышлял над тем, что скрывается за фразой «быть праведным agile-коучем»?

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

В свете довольно спорной репутации методов, вопрос о том, кто же такой  «праведный коуч», остаётся открытым. Каким принципам он следует? Что ставит во главу своей практики? Что ставит превыше всего?

У медиков есть свой девиз: «не навреди».

У  Google — свой "do no evil".

А что есть у agile-коучей?

Для себя я определил несколько принципов, которые приближают коуча к праведности:

• Раскрывать потенциал людей, работающих в компаниях; 
• Помогать компании развиваться или, как минимум, показать потенциал и путь вверх;
• Работать с клиентами, чьи ценности совпадают с моими;
• Стараться не отвлекаться на эмоции, которые я испытаваю к людям, а работать с процессами. Важно помнить, что все стремятся к счастью и делают то, что делают, потому что уверены, что это верный путь;
• Не вести двойных игр, не быть политкорректным, открыто говорить то, что думаю;
• Внердять практики (Kanban, Scrum, What-so-ever), только в случае, когда я интуитивно верю, что они смогут показать дальнейший путь развития компании, раскрыв её потенциал;
• Во время работы помнить о том, что я хочу научить компанию поддерживать свой процесс без моего участия и как можно скорее научиться обходиться без меня.

Вспоминал недавно один из своих первых проектов:

Звучит довольно по-аджальному.

Впрочем, такого ощущения не возникает при воспоминаниях об этом проекте.

Давайте попробуем разобраться, в чём же дело:

В апреле в Киеве мы проводим 5-дневную цепочку мероприятий:

Certified ScrumMaster: Advanced Practitioner - углублённый сертификационный класс. Два дня.

Certified LeSS Practitioner - класс по Large-Scale Scrum и масштабированию Agile. Три дня.

Scrum Club Meetup - две встречи клуба Скрам-практиков с приглашёнными гостями-докладчиками. Вечера.

Ждём всех в гости!

Регистрации на все мероприятия открыты по ссылкам выше. 

В статье «Ежедневные встречи – не только для Скрам-мастеров» Майк Кон описал типичнейший анти-паттерн: превращение этой встречи в статус-митинг.

Это происходит автоматически, как только Скрам-мастер начинает опрашивать всех участников, задавая им вопросы и устанавливая порядок ответов на них:

– Так, Вася, с тобой всё понятно… 

– Коля, ты следующий…

– Миша, что ты делал вчера?

или

– Дима, какой план на сегодня? ... Какая новая фича? ... А как же этот баг? ... Нет, займись лучше багом ... За полдня сделаешь?

Это  ни разу не Daily Scrum. Хотя со стороны очень похож на описанную в Скраме десятиминутку.

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

А пока мы задаем вопросы и встреваем в процесс планирования, мы остаёмся центральным звеном, без которого ничего не происходит и которое замыкает всю ответственность на себе. Это сложно, одиноко и неэффективно. Это старая школа менеджмента. Stop it!

Лучшие ежедневные Скрам-митинги происходят когда:

• Команда стоит напротив своей физической доски задач полукругом;

• Участники передают друг другу «говорящий маркер» – тот, кто держит маркер, говорит. Остальные слушают и задают уточняющие вопросы;

• Скрам-мастер стоит в стороне вполоборота к команде и записывает на доске основные проблемы и горячие темы. Он делает это для команды. Иногда он прерывает говорящего словами: «Похоже, это горячая тема. Для кого ещё это важно? Вы хотели бы её обсудить отдельно после митинга? ОК. Записал. Идем дальше?»;

• Время от времени Скрам-мастер вставляет короткие вопросы, направляющие команду к взаимодействию:

- Понятна ли всем суть проблемы?
- Для кого ещё это является проблемой?

- Кто мог бы помочь?
- Чем бы я мог помочь?

- Что ещё важного нам стоит сегодня обсудить, пока мы все вместе?

• После встречи Скрам-мастер может предложить команде пройтись по каждой задаче в "To Do" и убедиться, что они в работе. Или провести мини-ретроспективу самого Скрам-митинга, повысив его пользу для всей команды.

Ретроспективы, как известно, являются обязательной практикой многих гибких методологий. В частности, таких как XP, семейства Crystal, SCRUM.

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

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

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

Почему же это так?

Давайте начнём с начала.

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

Одно «но» – завершённому проекту от этого уже было ни холодно ни жарко. Его команде тоже. Вскрытие же, как никак!

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

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

Звучит просто и логично.

На деле же провести эффективную ретроспективу может быть весьма нелегко.

Я составил список самых распространённых причин, которые заставляют команды если и не избегать ретроспектив, то, как минимум, относиться к ним как к формальности:

• Книги по методологии, используемой командой, очень бегло описывают процедуру ретроспектив, и команда просто формально выполняет предписанные шаги («раз надо, так надо, не будем спорить с гуру»);

Расскажу вам историю из прошлого, которая до сих пор очень актуальна.

Травмировал я как-то колено в преддверии конца света (привет народу Майя!). И выпало мне целых шесть недель весеннего обострения в марте в новом для себя режиме. Что же произошло за это время?

Во-первых, я отлично отдохнул.

Во-вторых, я смог наконец-то сделать то, что не мог сделать уже много лет. А именно – найти время для низкоприоритетной и совсем некритичной задачи — выучить ruby on rails.

В-третьих, я не только освоил рельсы, но и написал сервис для SCRUMguides, которым мы пользуемся вот уже несколько лет. Почему-то у нанятых нами профессиональных «рубистов» в 2010-2011 году это получилось намного хуже.

Может все дело в колене?

Или всё дело в том, что наконец-то меня никто не подгонял, я делал то, что считал нужным делать в удобном на тот момент рабочем темпе и не гнался за результатами?

Меня, кстати, до сих пор удивляет, что наш confeture.com пережил уже немало крупных конференций. И выжил! Конечно, на тот момент это был незаконченный продукт, так называемый minimal viable product, у которого всё ещё было впереди, включая серьёзный рефакторинг UX.

Он знает и понимает Scrum, обучает ему команду, а также всех окружающих проект.

Он помогает команде корректно использовать каркас Scrum и получать выгоды от идей эмпирической разработки продуктов.

Скрам – известный всем, состоящий из набора несложных правил каркас управления проектами, который реализует Agile ценности и принципы, Следуя этим правилам вы гарантировано устраните самые  распространённые проектные проблемы.

Это вам что-то напоминает?

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

Кстати, а есть ли Product Owner в Канбане?

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

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

Вот лишь небольшой список проблем, которые могут быть вызваны неверным выбором Владельца Продукта:

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

Почему?

Потому что он им не владеет. Он за него отвечает.

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

Всё, что вы подозревали об оценках проектов, но боялись спросить!

Часто слышу вопрос о совмещении ролей ScrumMaster (SM) и Product Owner (PO).

Как по мне, то это крайне нежелательно.

Одна из задач SM – следить за правилами выполнения “игры Scrum” и помогать команде и заказчику (в частности, PO) эффективно работать. То есть выполнять наибольшее количество business value за единицу времени, но при условии поддержки определенного уровня качества!

PO не всегда видит и понимает значение внутреннего качества продукта, поэтому зачастую присутствует противостояние между командой и PO. Звучит это так: «Что лучше: продавать больше фич (писать быстрее и больше) или же писать меньше, но качественнее (т.е. медленнее)?».

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

Это представитель заказчика. Не посредник, не делегат, не менеджер на стороне подрядчика, а именно представитель со стороны заказчка.

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

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

Эта статья также доступна на 

dou.ua/lenta/articles/agile-in-outsourcing

Кажется, что гибкая разработка, в частности приёмы и советы каркаса Скрам, идёт вразрез реалиям мира аутсорсинга и fixed-price проектов.

Это не так.

Мне часто говорят: "Ну да, конечно, это всё прекрасно работает у вас там в Европе в продуктовых компаниях. У нас же здесь - никак. Мы работаем в аутсорсинге."

Это заблуждение.

Вернее, аутсорсинг, конечно, можно использовать как оправдание своей некомпетентности. Но это ещё никому не помогало.

Fixed-price проекты, я считаю, это отличная возможность отточить своё мастерство менеджмента. Scrum, к слову, родился как раз в таких проектах. Если у вас в проекте не ограничены средства, зачем тогда вообще что-то менеджетить? Пусть течёт как течёт. Так что fixed-price и agile - они как раз очень даже мило уживаются, поддерживая друг друга. В противовес fixed-scope проектам, которых на самом деле не существует. Вернее, scope то конечно можно пытаться ограничивать... но это идёт в разрез законам природы и всемирного тяготения к изменениям.

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

Эта тема, явно, болезненная, судя по яркой реакции на мой недавний провокационный пост:

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

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

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

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

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

Бисексуальность удваивает ваши шансы на свидание в субботний вечер.

Вуди Аллен 

Мне часто задают вопрос: “Ты работаешь Скрам-мастером или agile-коучем”? Слишком часто. А после того, как я сообщаю о том, что работаю независимым agile-коучем, уточняют, работаю ли я как “agile-коуч, “на уровне организации” , или (я так понимаю, имеется в виду “простым смертным” ) Agile-коучем? В таких случаях я тихо ухожу вдаль.

Расскажу вам об одном недавнем случае. Ездил я как-то на open space конференцию (они ещё бывают называются “unconference”, но по-русски это звучит смешно), на которой матёрые agile-тренеры пытались проранжировать все виды agile-коучей: от фасилитатора команды (он же “коуч без власти”) до agile-коуча на уровне организации (он же “agile бог”). Скажем так, дискуссия не задалась. 

Довольно давно, когда я запускал свой первый Скрам-проект (Ciklum, проект Encode, 2004 год) мы не знали, что такое груминг.

Заказчик созванивался с нами для планирования спринта… и тут начиналось: мы задавали глупые вопросы; заказчик куда-то убегал за ответами, с кем-то советовался и менял приоритеты; мы воевали с картами за истории, били истории на задачи… и так бесконечно. Планирование спринта у нас редко занимало меньше 8 часов.

Хуже всего то, что через две недели этот кошмар нужно было повторить. Сильная закалка для Скрам-мастера! :)

- «Приходит Владелец Продукта с беклогом..", – так я начинал свои избитые пересказы Скрам-каркаса. И это воспринималось как данное..

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

Скрам минималистичен и неполон по определению. Именно поэтому так много Владельцев Продуктов не могут найти места в Скраме практикам традиционного менеджмента продуктов, которые они привыкли выполнять в «до-аджальные» времена.

Если вы ещё не читали статью Майка Кона "Правила против общепринятых практик в Скраме", то я рекомендую вам с ней ознакомиться. Статья о практиках, которые довольно часто встречаются в Скрам-проектах, но не являются базовыми правилами Скрам.

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

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

За последние несколько лет перечисленные практики мне не раз довелось наблюдать за кулисами у успешных команд в роли Agile-коуча и рассказывать о них на тренингах Certified ScrumMaster в роли Скрам-Тренера.

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

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

В Agile это называется "process over people". 

Команда изнутри:

Обычно после тренинга я рассылаю участникам литературу и фотографии плакатов.

Недавно в ответ я получил несколько писем с описанием того, что происходит в командах Скрам-мастеров после тренинга.

Вот одно из них:

Настроение отличное! После тренинга я ещё подрзарядился энергией!

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

Провели первую ретроспективу по рекомендациям Алексея. Раньше я был уверен, что у нас в команде нет инициативы и идей. А всё потому, что раньше ретроспективу я проводил в формате: «У кого есть идеи, что можно улучшить? Ни у кого? Ну тогда я расскажу…».  

Сегодня же я в начале встречи попросил каждого перечислить, что у нас хорошо.

Потом каждого – что плохо (всё фиксировалось на доске).

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

Принятые решения занесли в ToDo List на новый спринт.

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

Ещё один интересный побочный эффект – я понял, что присутствие заказчика на ретро совсем не страшно. Просто раньше я угрюмо признавался, что не всё хорошо и предлагал, что делать (в основном – уменьшать Velocity), а Product Owner сидел и хмурился. Сегодня же напряжение мигом снялось, когда он понял, что команде не всё равно и у неё есть идеи, что можно улучшить.

Антон Кан, участник тренинга Certified Scrum-Master, Минск

Начать изменять процесс с ретроспективы – это отличная идея.

Это намного лучше, чем прийти и сказать: “Так, я был на тренинге, вот мой сертификат, теперь у нас будет полный Скрам”.

Ведь ключевой идеей Скрам-мастерства является активация команды и помощь им в принятии ответственности за построение удобного и эффективного процесса разработки.

Знаете ли вы этих людей?

Подсказка есть в моей статье "Битлз и самоорганизация".

Они – менеджеры. Оба управляли ливерпульской четвёркой. Одного из них даже называли “пятым битлом”. Но немногие меломаны знают их. Почему так?

Да и зачем группе нужно было целых два менеджера? Да ещё и такой непростой группе с двумя яркими соперничающими лидерами? Не много ли менеджеров и лидеров на команду из четверых человек?

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

Теперь коридоры компании полны вывесок вроде: Integration Manager, Iteration Manager, Quality Manager,

Development Manager, Account Manager, Change Manager, Crisis Manager, Retention Manager и т.д. Похоже, что наша компания отлично укомплектована и готова к дальнейшему развитию!

Но позвольте спросить: "Насколько место, изображенное на фотографии, приведённой ниже, безопасно?

С 2008 года я в качестве консультанта и бизнес тренера посещаю различные IT компании. В некоторых провожу день-два, с другими работаю довольно долго. В последнее время я плотно работаю с 10-15 компаниями в год.

Недавно у меня появилось новое хобби – угадывать основные проблемы, с которыми сталкиваются проекты в таких компаниях, по описанию структуры компании.

Я не гений и не пророк. Далеко нет. Просто мне кажется, что я нашел некоторую очень типичную линию развития компаний (pattern, если хотите), которая позволяет довольно точно воспроизводить текущую фазу развития компании со всеми присущими характеристиками.

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

Итак, есть всего две вещи, которые важны в беклоге: его наличие и его доступность.

Перепрочёл Scrum Guide…

Всё еще никаких упоминаний. Ни словечка по этой теме.

По поиску слова “лид” выдаёт два результата:

“Скрам-мастер - servant-leader (дословно “служащий ЛИДЕР”) для Скрам команды”.

и

“Scrum-мастер ... коучит и направляет организацию, ЛИДИРУЕТ процесс внедрения Скрама”.

Единственная причина, по которой Scrum Guide не упоминает об этой широко распространённой роли - это потому, что эта роль нерелевантна для Скрама.

Думаю, что так и есть...

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

Видео и слайды доклада

Ловите меня в Киеве на PM Day 2016 c темой:

“Почему масштабирование agile - это неверное решение не той проблемы. Или как вернуть молодость своей организации.”

Масштабирование или “agile at scale” - это горячая тема. Новые каркасы, процессы, методы и сертификации растут как грибы в Карпатах. Но без глубокого понимания системной динамики вашей конкретной организаций любой подход “скейлинга” будет лишь временной заплаткой на теле этой организации.

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

Мы рассмотрим еще несколько (к сожалению) типичных схем структуризации компаний (которые кажутся правильными на первый взгляд) и поговорим о вариантах рефакторинга и выплаты организационного долга с целью изменения организационной динамики и возвращения компаниям столь рано потерянной молодости и прыткости.

Приносите попкорн.

2012 год - я выступаю с новым докладом "Современная история менеджмента" на "SPM Conf" в Минске. Я с этим докладом ездил более года. Это лучшая запись из существующих. 

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

• Как обычно происходит организационный рост компаний?
• Откуда берутся менеджеры?
• Как структуры влияют на культуру?
• Какие есть альтернативы (и есть ли) структурным решениям?

Вопросы всё так же актуальные, что и сегодня.

Особенно благодаря повышенному сейчас интересу к методам и подходам т.н. "agile at scale".