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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

= Business value not delivered

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

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

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

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

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

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

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

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