БЛОГ

Вы знаете, что я также активно веду свой новый англоязычный блог? Посетите его.


Agile Product Roadmapping — как это было в IPLand

Agile Product Roadmapping
Agile Product Roadmapping

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

 

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

0 Comments

Книги по ретроспективам - теперь в бесплатном доступе!

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

 

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


2 Comments

Certified Scrum Product Owner (CSPO) - как это делаю я

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

 

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

 

 

 

 

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

 

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

 

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

 

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

Read More 0 Comments

infoq - Complexity of organizational design and its effects on scaling agility

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

 

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

 

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

0 Comments

Мрачный Скрам

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

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

A photo is owned by https://www.flickr.com/photos/62704954@N03/ and distributed under the Creative Commons License
A photo is owned by https://www.flickr.com/photos/62704954@N03/ and distributed under the Creative Commons License

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

 

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

Read More

Culture follows structure

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

 

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

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

Read More

Agile в аутсорсинге не работает

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

 

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

 

Случайное фото встречи. Я не знаю, кто именно из докладчиков утверждал, что "agile не работает". Быть может и скорее всего, эта фраза вообще вырвана из контекста.
Случайное фото встречи. Я не знаю, кто именно из докладчиков утверждал, что "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!


1 Comments

Certified Scrum Master - Минск

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

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

 

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

 

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


Тренина и Кривицкий
Тренина и Кривицкий
0 Comments

Интервенции в разрезе пяти стилей коучинга


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

 

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

 

И наоборот.

 

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

 

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

 

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

 

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

 

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

 

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

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

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

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

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

 

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

 

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

 

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

 

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

Read More 0 Comments

Scrum Master Club - апрель 2017

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

 

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

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

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

 

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


Read More 0 Comments

Доклад на PM Day Kyiv 2016: Complexity and system thinking

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

 

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

Избранные слайды и фото

Read More 0 Comments

Powerful Interventions - сила интервенций в agile-коучинге


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

 

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

Kaizen
"Кайзен" - более простыми словами

 

 

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

 

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

 

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

Read More 0 Comments

Large-Scale Scrum with LEGO

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


0 Comments

The future is now

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

 

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

Прошлое

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

 

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

 

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

 

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

 

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

 

Я ушёл.

 

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

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

 

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

 

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

 

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

 

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

Read More 0 Comments

Велик и могуч... термин «agile»

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

 

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

"Начало начал". Притча.

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Read More 0 Comments

Что создаёт грунт для agile проектов?

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

 

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

 

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

 

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

 

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

 

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

 

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

Статья от 03/2007

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


0 Comments

User Stories

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

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

 

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

 

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

 

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

 

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

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

USER STORIES: ЭКСТРЕМАЛЬНЫЙ ПОДХОД

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

 

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

 

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

 

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

Read More 0 Comments

Что не так с нашими ретроспективами?

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

 

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

 

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

 

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

  • Что в ходе спринта было хорошего?
  • Что было не очень хорошо?
  • Что можно улучшить в следующем спринте?

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

 

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

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

  • Выписывают множество жалоб на что-то, что было, по их мнению, не очень хорошо;
  • Генерируют множество идей;
  • На этом расходятся.

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

 

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

 

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

 

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

Read More 0 Comments

Scrum is ... или Карта мозга Скрам коуча

С чего все началось

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

 

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

 

Обсуждение началось с поста статьи Тобайаса Мейера (Скрам-тренера, фасилитатора и анархиста) под названием 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.

 

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

 

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

 

Поясню.

Что я понимаю под Скрам

Read More 0 Comments

Unfinished work in sprints

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

 

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

 

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

 

= Business value not delivered

 

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

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

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

 

= Business value delivered (but partially)

 

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

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

Continuous Improvements в LeSS

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

 

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

 

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

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

 

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

 

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

0 Comments

Large-Scale Scrum: Законы Лармана об Организационном Поведении

Мне выпала огромная честь выступить редактором русского издания недавно вышедшей книги по LeSS "Large-Scale Scrum".

 

Кроме того, что я давно хотел перечитать книгу полностью, а не частями и помочь с ее адаптацией на наш рынок, сам проект выдается очень увлекательным.  Я не только редактирую текст, с точки зрения LeSS, я правлю перевод, пытаясь найти в русском адекватные переводы таких терминов как к примеру: "cross-functional cross-component end-to-end colocated feature team".

 

Пожелайте мне удачи с этим!

 

Сегодня дошел до законов Лармана из главы про Внедрение, не могу не поделиться:



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

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

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

 

Внедрение LeSS

 

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

 

...

 

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

 

...

 

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

Read More 0 Comments

С чего стоит начать менять процесс?

КАК ПОБОРОТЬ СКРАМ-ДИКТАТУРУ

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

 

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

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

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

— ....

 

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

 

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

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

— ....

 

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

 

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

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

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

Read More 0 Comments

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

 

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

 

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

 

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

 

It is waterfallic!

 

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

 

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

Read More 0 Comments

Популярность Scrum

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

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

 

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

ПРОСТОТА

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

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

Read More 0 Comments

Advanced Scrum: проблемный вопрос

Все знают о трёх рекомендованных вопросах, на которые каждый из команды должен дать ответ во время ежедневного Скрам-митинга.

 

У меня с ними проблемы.

 

Как часто вы слышите расширенный ответ на третий вопрос: «Есть ли у тебя проблемы?».

 

Я — крайне редко, один раз на 10 митингов. Остальные разы звучит гордое: «Нет проблем!», — да ещё и с энтузиазмом.


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

 

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

 

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

 

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

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

 

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

 

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

Read More 0 Comments

Agile революции. Или как не дать гибкой разработке умереть

AGILE — это не только:

 

— Философия разработки софта;
— Подходы повышения эффективности;
— Ещё одна методология управления персоналом.

 

Вдумайтесь в ценности agile-манифеста.

 

Ведь это не что иное, как революция!


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

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

 

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

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

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

 

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

 

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

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

 

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

ЭКОСИСТЕМА ПРОЕКТА

Read More 0 Comments

Заводные апельсины нынче не в моде

Как управлять своим вниманием во время работы?

 

У вас бывает такое чувство, что вы делаете одновременно десяток дел?

 

Как-то раз, будучи рассерженным на своё расфокусированное внимание во время работы, я спросил подписчиков в Twitter, один ли я такой, или ещё есть пара человек во Вселенной, которым тяжело удерживать внимание на одном деле?


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

 

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

 

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

 

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

 

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

  • Перед началом работы решаешь, в каком режиме работа-отдых будешь работать (30/5, или 40/10 или 60/15 и т.п.);
  • Заводишь свой помодоро на выбранный интервал для работы;
  • Работаешь, не отвлекаясь ни на что, пока не прозвенит таймер;
  • После того, как таймер работы закончился, заводишь его на выбранный для отдыха интервал и занимаешься тем, что тебя отвлекало пока ты работал. Если вдруг ничего не отвлекало (чисто гипотетический случай) — отправляешься на заслуженный перерыв (минут на 10).

Что это дает? 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

Статья от 11/2009


0 Comments

QA в SCRUM

ПРОСТОТА И СЛОЖНОСТЬ SCRUM

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

 

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

 

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

 

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

 

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

QA И SCRUM

Read More 1 Comments

Dejirafication

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

0 Comments

Conflicts For Good. Ныряем в конфликты, выныриваем с пользой

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

 

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

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

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

Read More 0 Comments

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

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

 

 

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

Read More 0 Comments

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

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

 

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

Read More 1 Comments

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

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

 

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

 

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

Что же делать?

 

Нужно держать метрики в секрете и никому не показывать!

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

Хм… Что-то здесь не так.

 

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

 


Read More 0 Comments

War room или настенная живопись

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

 

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

 

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

 

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

Read More 0 Comments

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

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

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

 

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

Read More 0 Comments

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

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

 

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

 

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

 

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

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

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

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

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

Похоже, но не agile

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

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

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

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

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

Read More 0 Comments

Scrum Week Kyiv - 24-29 апреля

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

 

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

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

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

 

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

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


0 Comments

Daily Scrum – ключик самоорганизации

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

 

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

 

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

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

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

 

или

 

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

 

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

 

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

 

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

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

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

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

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

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

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

Часто задают вопрос: «А что происходит, когда Скрам-мастер не приходит на Скрам-митинг из-за утреннего похода к стоматологу (причины могут меняться)?»

 

Ответ прост – команда проводит свой митинг в условленное время.

 

 


Read More 0 Comments

Ретроспективы: формальность или польза?

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

 

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

 

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

 

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

 

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

 

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

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

 

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

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

 

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

 

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

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

 

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

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

Бармены, эстафета и околачивание груш

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

 

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

 

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

 

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

 

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

 

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

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

 

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

Но речь сейчас не о продукте. Речь о том, что ДеМарко называет «Slack».

 

С английского google-переводчик, переводит «slack» как «провисание», «затишье» или «битье баклуш». 

 

Мне больше по душе «околачивание груш». К тому же, из груш можно сварить отличное варенье.  А если повезет, то и конфитюр!

 


Read More 0 Comments

Ключевые обязанности Scrum-мастера

Работа Скрам-мастера – полная занятость или же её можно совмещать?

 

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

 

Ниже кратко приведены десять основных обязанностей, на которых хороший Scrum-мастер фокусируется ежедневно:


1. Выполнение Скрам процесса

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

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

Read More 0 Comments

Scrum is a diet, Kanban is a mirror

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

 

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

 

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

Read More 0 Comments

В поисках «Властелина Продукта»

Роль Product Owner или, говоря по-русски, «Властелина Продукта» – чуть ли не самая очевидная практика Скрам.

 

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

 


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

 

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

 

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

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

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

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

 

Почему?

 

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

Read More 0 Comments

Перестаньте спрашивать "когда?" #noestimates

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

 

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


Read More 0 Comments

О совмещении ролей ScrumMaster (SM) и Product Owner (PO)

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

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

Причины:

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

 

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

 

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

 

Read More 0 Comments

Product Owner's Job Description

Что делает Владелец Продукта в Скрам проекте?

 

Проблема стара как мир разработки.

 

За это время я работал с различными тренерами: Mark Vizdos, Mark Pushinsky, Robin Dymond, Henrik Kniberg и Sergey Dmitriev. Все они одного и того же мнения о сути, роли и функциях Владельца Продукта.

 

Делюсь своим пониманием.


Кто такой Product Owner?

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

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

"Outsourcing головного мозга". Или всё-таки можно научиться совмещать гибкую разработку и fixed-price?

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

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

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

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

 

Это не так.

 

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

 

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

 

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

 

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

 

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

 

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

Read More 2 Comments

Краткое руководство по масштабированию Scrum встреч до 50+ участников (без дополнительных затрат)

Скрам масштабируется

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

 

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

 

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

 

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

 

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

Скрам встречи масштабируются

Read More 0 Comments

Scrum-мастер - не (только) командный коуч и фасилитатор

Или всё, что вы хотели знать о Скрам-мастере, но боялись спросить.

 

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


Вуди Аллен 

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

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

Read More 3 Comments

Уход за беклогом (груминг), или Как сделать планирование спринтов легкой задачей

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

 

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

 

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

Груминг как он есть
Груминг как он есть
Read More 0 Comments

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

“There is no dark side in the moon, really. Matter of fact, it’s all dark.” «The Dark Side of the Moon» Pink Floyd, 1973

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

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

 

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

Read More 0 Comments

Больше, чем plain vanilla scrum. Общепринятые практики работы с требованиями.

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

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

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

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

Read More 0 Comments

Самоорганизация хаотична. Но это не повод для микроменеджмента.

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

 

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

 

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

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

Команда и её внутренний "хаос"
Команда и её внутренний "хаос"
Read More 0 Comments

Ретроспектива в команде после тренинга

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

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

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

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

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

 

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

 

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

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

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

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

 

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

 

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

 

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

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

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

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

Read More 0 Comments

Новейшая история менеджмента компаний (часть 3): Битломания и три типа менеджеров в Скраме

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

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

George Martin
George Martin
Brian Epstein
Brian Epstein

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

 

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

Read More 0 Comments

Новейшая история менеджмента компаний: часть вторая, в которой страсти накаляются

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

 

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

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

 

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

Read More 0 Comments

Новейшая история менеджмента компаний: от эры стагнации к Ренессансу

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

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

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

Read More 0 Comments

Что общего у беклога продукта и испанской инквизиции?

Любителям “Monty Python” посвящается.

 

Nobody expects the Spanish Inquisition

 

Monty Python

 

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

 

Пожалуй, это ключевая вещь, которую можно сказать о беклоге продукта – или проще «списке работ по продукту», таком себе to-do-листе.


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

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

Read More 2 Comments

Почему Скрам молчит о роли тим-лида (а я - нет)

Неужели Скрам забыл о роли тим-лида?

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

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

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

 

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

и

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

 

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

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

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

Read More 0 Comments

Ловите меня на Kyiv Project Management Day 2016 уже в сентябре.

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

 

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

 

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

 

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

 

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

 

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


0 Comments

Доклад "Современная история менеджмента" или как развиваются организации

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

 

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

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

 

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

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

Слайды

Read More 0 Comments

Новый тренинг "Certified Agile Leadership" от ScrumAlliance в Киеве

ЧТО ЭТО ЗА ТРЕНИНГ?

 

В начале этого года ScrumAlliance запустил новую программу обучения и сертификации Agile Leadership Program. Читайте также о запуске этой программы на InfoQ.

 

Эта программа готовит вас - лидеров к управлению организациями, находящимися на пути освоения agile мышления, его ценностей и практик . Задача такого лидера непроста: с одной стороны ему нужно развивать организацию, растить других лидеров и помогать (не мешать) прохождению изменений; с другой стороны - развиваться самому, повышая свой уровень осознанности процессами лидерства, управления и делегирования.

 

Этот тренинг - первая из двух сертификаций "Certified Agile Leadership Program":

Вот, что вкладывает в понятие agile-лидера Скрам-альянс и этот сертификационный курс:

  • Operates effectively amid uncertainty, complexity, and rapid change
  • Is knowledgeable about Agile values, approaches, and practices
  • Surfaces more creative solutions through increased self-awareness, a growth mindset, and engaging others
  • Aligns and empowers teams toward delivering more customer value
  • Personally integrates feedback and experiments, and adapts their ways
  • Takes a collaborative continuous-improvement approach to organizational effectiveness
  • Catalyzes change in others and facilitates organizational change 

ТРЕНЕРЫ

 

Read More 0 Comments