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

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

Те, кто тянули с размещением зефира до последней минуты, столкнулись с неожиданными результатами)

Вдохновляющий манифест разработчиков в Dodo Pizza.

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

И буквально на прошлой неделе руками Alexander Andronov (СТО Dodo Pizza) она преобразовалась в 7 важных для нас вещей:

1. Nobullshit
Если какой-то процесс не приносит ценности, давай избавимся от него. Здравый смысл и доверие — вот наши инструменты.

2. Гемба
Наш бизнес — это совмещение IT и оффлайн. Разработчики и управляющие пиццерией сидят рядом, постоянно общаются и работают рука обруку над созданием Dodo IS. Закодил — сразу видишь, насколько рад пиццамейкер новым фичам.

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

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

5. Фокус
Фокусируйся на главном. Отбрось то, что не важно. Не пытайся взять 20 задач и делать все подряд, ведь тогда ты не сделаешь ничего. Сделать что-то одно важнее, чем делать 20.

6. Ответственность
Менять жизнь 10 миллионов клиентов с помощью кода. Да, цена ошибки высока и мы несём ответственность перед миллионами клиентов, десятками тысяч сотрудников Додо. Нам не всё равно.

7. Постоянный рост
Расти можно только тогда, когда ты делаешь то, чего не делал раньше. Бери сложные задачи, бери то, чего не делал раньше. Ошибёшься — не бойся, пробуй снова. Только так возможен рост.

Привет! Спешу поделиться потрясающим по своей насыщенности постом о законе Конвея от Ивана Евтухова.

Суть закона: «Организация, которая создает систему, ограничена дизайном, который копирует структуру коммуникации в этой организации».

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

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

«Как только продуктовая команда сможет делать свои дела, ни с кем не особо не договариваясь и никого не ожидая, дело пойдет совсем с другой скоростью. »

В общем, однозначный мастрид в первый день новой рабочей недели.

http://evtuhovich.ru/blog/2016/10/05/conways-law/

#ценности #scrumValues #ретроспектива

Поговорим о Scrum ценностях. В самом начале моего пути я не обращал на них внимание и считал, что это какая-то ненужная фигня (готовясь к первому собеседованию на позицию Скрам Матера я просто пропустил этот блок в скрам гайде). Но чем больше я работаю с командами, тем больше понимаю, что ценности Scrum - краеугольный камень всего фреймворка. Чем сильнее члены Scrum команды привержены ценностям, тем эффективнее работает сам фреймворк: уберите одну из них и постепенно ваш Scrum начнет хромать, а затем совсем «загнется» и превратится во что угодно, но только не Scrum.

Подробнее о ценностях можно почитать здесь: https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/

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

1. Короткий рассказ о ценностях (15 минут)
2. Команда совместно определяет, какие ценности сильнее всего «страдают»  (dot-voting) (5 минут)
3. Разделение на небольшие группы (2-3 в зависимости от размера команды) и обсуждение наиболее «слабых» ценностей (одна команда - одна ценность). Что происходит с командой и  фреймворком, если данная ценность игнорируется? Какие анти-паттерны формируются? (5 минут)
4. Короткое обсуждение между группами последствий игнорирования определенных ценностей (5 минут)
5. Каждая группа определяет, какие действия/события усиливают определенную ценность, а какие - разрушают ее. (Одна группа - одна ценность) (7 минут)
6. Группы презентуют результаты своей работы и при необходимости дополняют друг друга. (15 минут)
7. Команда обсуждает, какие конкретные действия нужно предпринять на основании прошедшего обсуждения для того чтобы повысить приверженность к ценностям Scrum. (10 минут)

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

Привет!

Поиски края интернета снова не прошли даром. Наткнулся на законы об организационном поведении, сформулированные Крэгом Ларганом (создатель LeSS, консультант и software engineer).

Вот они:

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

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

Трансформация это больно.

На русском с законами можно познакомиться здесь: https://m.habr.com/ru/company/scrumtrek/blog/320832/

Оригинал для гурманов вот тут: http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior

«Главное качество лидера - энергия, а не интеллект» - Пьер Касс.

Согласны?

«Производительность Agile команды» - очень крутой тренинг от Анны Обуховой.  Три дня чистого удовольствия. Регистрация и подробная информация здесь: https://scrumtrek.ru/product/58/proizvoditelnost-agile-komandi/

#владелецПродукта #стейкхолдер #управлениеБэклогом

Ведущего аналитика от Владельца Продукта отличает умение правильно сказать «нет» на запрос стейкхолдера включить в бэклог продукта очередную фичу с НУЛЕВЫМ приоритетом. Как это сделать и при этом сохранить свое место в компании?

Майк Кон написал хорошую статью, где поделился полезными советами о том, как «правильно» отказывать заинтересованным лицам.

Ключевые тезисы:
1. Будьте предельно точны: это окончательное «нет» или «нет» в текущий момент (обозначьте время и условия при которых будете готовы вновь вернуться к разговору).
2. Не забывайте про уважение и эмпатию. Прежде чем говорить «нет» убедитесь, что точно понимаете, почему данный функционал важен вашему стейкхолдеру.
3. Сфокусируйтесь на одном, самом весомом аргументе. Не упирайтесь рогами в землю, если понимаете, что ваша аргументация слаба и после разговора вы согласны с позицией стейкхолдера.
4. Обратитесь к видению продукта и ключевым целям. Если вы их разделяете, а новая фича идет в разрез с обозначенным направлением движения - у вас есть весомый повод отказать.
5. Расскажите о последствиях, в случае, если вы скажите «да».
6. Предложите альтернативные варианты. Возможно есть способ реализовать необходимый функционал менее затратным способом за счет изменения некоторых элементов бэклога.

Подробнее с советами Майка вы можете ознакомиться здесь: https://www.mountaingoatsoftware.com/blog/six-guidelines-for-saying-no-to-a-stakeholder

#приоритизация #бэклог

К слову о приоритетах…

Всегда вызывала удивление фраза: «у нас 10 задач с первым приоритетом». Что это значит?

Действительно ли все задачи имеют один и тот же финансовый/репутационный/PR эффект? Даже если эффект от каждой из задач примерно одинаков, то что для нас сейчас важнее финансы/репутация или PR? А в случае, если все из перечисленного имеет одинаковую важность, то какая из задач даст нам наибольший выхлоп при наименьших затратах?…

Максимально простое и элегантное решение вопроса с приоритизацией предлагает Scrum: выстраивание очереди. Сама форма заставляет Владельца Продукта и заинтересованных лиц решить, что сейчас имеет первостепенное значение и на какой задаче нужно сфокусировать усилия команде.

#производительность #мотивация #энергия

Маствотч на выходные.

Анна Обухова в гостях у Евгения Лабунского (Scrum Ukraine).

О чем узнаете:
- как KPI убивает мотивацию и превращают людей в зомби
- выгорание людей и команд
- "батарейка" и сколько энергии нужно для успешной работы Скрам Мастера/Владельца Продукта/Agile коуча
- как измерить свой уровень энергии и что потом с этим делать

https://youtu.be/7V0wgvQBfk0

#SAFe #Масштабирование #Планирование

Несколько слов о PI планировании в SAFe.

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

Только представьте, люди, которые привыкли общаться в рамках формальных совещаний, все фиксировать в протоколах и многостраничных ТЗ встречаются на два дня, чтобы в процессе тесного взаимодействия разработать план на ближайшие 2-3 месяца. Фантастика!

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

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

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

Интереснейшая статья Максима Цепкова о принципиальной смене формата отношений между компаниями и сотрудниками.

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

Согласны?

https://spiraldynamics.ru/socialnyj-dogovor-rabota-dolzhna-obespechivat-schaste/

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