Мотивация и сплоченность команды: как найти ценность в повседневной работе

Иногда участники команды могут чувствовать себя потерянными в потоке задач. ПО нужны деньги, клиентам нужно решение их проблем. Спринт за спринтом, мы решаем возникающие проблемы, думаем о предстоящем релизе, а поток все не заканчивается. Мы забываем, какое отношение всё это имеет лично к нам: почему мы здесь, зачем? Ах, да, ЗП. Ну вот мы и работаем за две смски об авансе и получке. Грустно.

Эта статья для скрам-мастеров и участников команд. Она о том, как увидеть ценность в повседневной работе. Я рекомендую проводить сессию «Ценность для команды» в начале работы над продуктом, если вы начинаете, или в любое другое время, если вам нужно воскресить мотивацию команды.

Итак, пошаговый план организации сессии «Ценность для команды»:

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


Как начислять зарплату команде разработки, которая работает по Скраму

Артем Игнатенко спросил нас:

Как пересматривать зарплаты в Dev команде? Учитывая Т-образные компетенции, ставить ценник на каждую компетенцию? И как проводить объективную оценку этой компетентности (аналоги оценок 360 и ИПР для Scrum-команд)?

Отвечаем:

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


30 лучших книг для Скрам Мастера

Всем привет! В этой статье  я хочу поделиться своим списком лучших тридцати книг для Скрам-мастера. Этот список я высылаю всем участникам сертифицированного тренинга Professional Scrum Master (PSM). Настало время открыть его широкой публике 🙂

Все книги я читал и много применял на практике. Они работают 🙂  Книги покрывают все восемь областей модели компетенций Скрам-мастера, которую разработал Agile Coaching Institute:

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


3 причины, почему Спринты полезны

Перевод статьи Дэвида Старра «3 reasons to sprint«.

Некоторые команды спрашивают, почему так важно заканчивать работу за Спринт. «Это искусственное ограничение моей работы.» — поясняют они. «Почему мы не можем потратить столько времени, сколько необходимо? Почему всё должно быть готово до завершения Спринта?» По моему опыту, эти разочарованные команды, скорее всего, хотят перейти от плохо внедренного Скрама к катастрофически реализованному Канбану и работе по системе “точно вовремя” (just-in-time).
Использование спринтов дает три преимущества, которых нет в системе “точно вовремя”.
Продолжение этой статьи »


Владелец Продукта — предприниматель

Перевод оригинальной статьи Гюнтера Верхеена https://guntherverheyen.com/about/

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

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


Почему Обзор Спринта больше, чем Демо

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

Важно — инспектируем Спринт как событие.

Спринт сам по себе — одно из 5-ти официальных событий Скрама. Обзор Спринта — это не просто демонстрация “Готового” Инкремента продукта, а инспекция прошедшего Спринта, исследование его как эксперимента. В Скраме каждый Спринт — это проект, а сама разработка продукта состоит из большого количества подобных мини-проектов. Каждый Спринт может оказаться последним. Владелец Продукта принимает решение о финансировании очередного Спринта исходя из экономической целесообразности (ROI).

Каждый Спринт может стать последним. Владелец Продукта принимает решение о финансировании очередного Спринта исходя из экономической целесообразности (ROI).

К примеру, формально на Обзоре Спринта могут быть приняты следующие решения:

  • Остановить разработку.
  • Финансировать следующий Спринт.
  • Добавить команду(ы) для увеличения скорость разработки.
  • Изменить состав Команды Разработки.

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


Скрам – фреймворк, а не методология

Мы продолжаем переводы статей по Agile- и Scrum-тематике, сегодня — статья Гюнтера Верхеена «Скрам – фреймворк, а не методология»

Над переводом работали:


Лобин Сергей

Павличенко Илья

Дмитрий Кустов

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


Мифы о Скраме: Скорость = Ценность?

Команда Agile Translaters поздравляет всех с наступившим Новым Годом и продолжает свою работу над переводом замечательных ресурсов по Agile и Scrum, далее следует перевод замечательного блог-поста Алекса Балларина Scrum Myths: Velocity = Value?

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


Скрам как движок организационных изменений

Когда люди обсуждают Скрам, то чаще всего возникает картинка выше: фреймворк и его роли, артефакты, события. Правила Скрама довольно просты, и они детально описаны в Руководстве по Скраму (Scrum Guide). Очевидно, что людей привлекают потенциальные преимущества Скрама (скорость, бизнес ценность и т.д.). Ко мне на открытые тренинги частенько приходят руководители компаний (в том числе и вне IT), которые, прочитав нашумевшую книгу Джеффа Сазерленда “The Art of Doing Twice The Work In Half The Time”, с нетерпением хотят как можно быстрее внедрить Скрам, чтобы получить обещанные бонусы. И кажется, что стоит лишь определить роли, пройти сертификационный тренинг — и дело в шляпе! К сожалению, это не совсем так, а точнее… совсем не так. И вот почему.

Другая сторона Скрама (“темная сторона луны”).

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


В поисках розового скрама, канбана и холакратии

Сделал сегодня пост на фейсбуке про «Поиски розового единорога» и мне в личку поступила пара вопросов, мол чем не устраивает эта или эта компания.

Ниже я набросал тут небольшой фильтр, который поможет вам отличить то что я ищу, от того что предлагаете вы :):

Когда в компании розовый Скрам, то:

  • Есть на 100% выделенный Владелец Продукта (PO)
  • PO полностью и самостоятельно распоряжается бюджетом продукта (может сам решить и выплатить бонус команде, принять решение о найме еще одного члена команды, купить еще один сервер и тп)
  • Команда кроссфункциональна, то есть в команде есть дизайнер, тестировщик и тп и все они выделены на 100% и нигде ни с кем больше ничего не делают
  • Члены команды не расписывают кто будет делать те или иные таски на планировании
  • команда сама мониторит процесс своих улучшений
  • ваш процесс эволюционирует

Когда в компании розовый Канбан, то:

  • У вас есть ограничения по колонкам
  • У вас мониторится lead time и cycle time (можете показать графики за год и более)
  • Происходит гибкое перераспределение людей по задачам
  • команда регулярно обсуждает свои финансовые результаты
  • команда сама мониторит процесс своих улучшений
  • ваш процесс эволюционирует

Когда в компании розовая Холакратия, то:

  • CEO сложил с себя свои полномочия и организация управляется Конституцией
  • У вас проводятся регулярные Governance meeting где используется Интеграционный процесс принятия решений
  • У вас проводятся регулярные Tactical meetings со всем необходимым шаманством по метрикам и проектам
  • Орг структура, роли и их зоны ответственности в вашей компании меняются постоянно (как минимум ежемесячно)
  • команда сама мониторит процесс своих улучшений
  • ваш процесс эволюционирует

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