Масштабируем Скрам с помощью Нексуса

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

Продолжение этой статьи »


Как оценить производительность Скрам-команды

Основной показатель успешности Скрам-команды — это поставка ценности. Чем больше ценности Команда поставляет, тем она эффективнее. Однако ценность — очень абстрактное понятие, поэтому Команда выбирает и фокусируется на достижении конкретных значений одной-двух продуктовых метрик, которые свидетельствуют об успешности Продукта.

Продолжение этой статьи »


Подборка полезных статей от 31 января

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

Продолжение этой статьи »


Хватит обвинять людей, меняйте систему

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

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

Джон Сэддон, Freedom from Command and Control
Продолжение этой статьи »


Инноваций не будет, пока вы не изменитесь

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

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

Продолжение этой статьи »


Почему выгодно обучать сотрудников, а не нанимать новых?

С течением времени Скрам-команда усиливает Критерии Готовности (DoD). Например, ранее Критерии Готовности не включали автоматические тесты или нагрузочное тестирование. Теперь Скрам-команда должна решить, как ей это сделать, потому что часто у сотрудников нет необходимых навыков и знаний для этого.

Я знаю лишь два способа, как можно расширять навыки и компетенции Команды. Первый — объявить Владельцу Продукта о том, что нужного навыка нет и попросить его нанять специалиста с рынка. Второй — нарастить компетенцию силами самой Команды, даже если это займёт некоторое время. Чтобы понять, какой из способов выгоднее, давайте воспользуемся помощью системных диаграмм (Causal-Loop Diagrams).

Продолжение этой статьи »


Кошмар Скрам-мастера № 2: Скорость работы Команды не растёт

Скрам-мастер Семён в печали: последние Спринты Команда не показывала стабильного прироста своей скорости (Velocity). А согласно KPI, Команда должна была увеличить её на 20%.

Кошмар Скрам-мастера № 2: Скорость работы Команды не растёт

Продолжение этой статьи »


Девять причин тонко нарезать Пользовательские Истории

Большинство Скрам-команд используют Пользовательские Истории для создания элементов Бэклога Продукта. Я часто замечаю, что Команда берёт слишком большие истории в Спринт. Это порождает много проблем, поэтому я рекомендую Скрам-командам декомпозировать задачи так, чтобы брать в Спринт 6–10 историй. Давайте подробнее обсудим, почему это так важно.

Продолжение этой статьи »


Как научить Скрам-команду декомпозировать истории

Многие Скрам-команды испытывают трудности при разбивке Пользовательских Историй на более мелкие задачи и говорят своему Скрам-мастеру: «Это невозможно!» Я часто сталкиваюсь с этой проблемой и рекомендую в таком случае провести воркшоп по декомпозиции. Ниже я подробно опишу, что должен делать Скрам-мастер, чтобы обучить Команду разбивать истории.

Продолжение этой статьи »


Системная оптимизация: прокачиваем компетенции Команды

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

Продолжение этой статьи »