ПУБЛИЧНЫЕ ТРЕНИНГИ В 2017

Agile Coaching Academy, модули 1, 2 и 3

Киев

31 авг - 2 сентября - модуль SKILLS FOR CHANGE

28-30 сентября - модуль DESIGNING SUSTAINABLE CHANGE

16-18 ноября - модуль DRIVING SYSTEMIC CHANGE

 

Программа профессиональной подготовки агентов изменений и лидеров agile трансформаций. Узнайте больше о Agile Coaching Academy.

 


Certified ScrumMaster (CSM) with LEGO!

Киев

7-8 сентября 2017

В 2017 мы проводим всего несколько сертификационных CSM тренинга в Киеве. Спешите записаться в группу, так как количество мест ограничено. Ознакомьтесь с описанием обновлённого продвинутого CSM тренинга.


Certified Scrum Product Owner (CSPO): from Idea to Release Roadmap

 

Киев

5-6 сентября 2017

В 2017 мы проводим только один сертификационный CSPO тренинг в Киеве. Спешите записаться в группу. Перейти на страницу тренинга и регистрацию.


Certified LeSS Practitioner (CLP)

Киев

12-14 сентября 2017

Три дня. 

При проводим второй в этом году Certified LeSS Practitioner (CLP). Класс проводится на английском языке.



ПОДБОРКА СТАТЕЙ

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

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

 

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

Read More 2 Comments

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

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

 

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

 

 

Read More 0 Comments

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

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

 

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

 

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

Read More 0 Comments

Culture follows structure

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

 

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

Read More

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

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

 

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

 

Read More 1 Comments

Certified Scrum Master - Минск

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

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

 

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

 

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

Read More 0 Comments

Scrum Master Club - апрель 2017

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

 

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

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

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

 

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

Read More 0 Comments

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

Read More 0 Comments

Large-Scale Scrum with LEGO

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

Read More 0 Comments

The future is now

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

 

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

Read More 0 Comments

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

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

 

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

Read More 0 Comments

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

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

 

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

 

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

 

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

 

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

 

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

 

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

Read More 0 Comments

User Stories

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

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

 

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

 

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

 

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

 

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

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

Read More 0 Comments

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

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

 

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

 

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

 

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

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

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

 

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

Read More 0 Comments

Unfinished work in sprints

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

 

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

 

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

 

= Business value not delivered

 

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

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

Continuous Improvements в LeSS

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

 

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

 

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

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

 

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

 

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

0 Comments