Как Agile помогает вести проекты в условиях неопределенности, выпускать продукты и находить рабочие решения там, где нет готовых ответов. Короткий тест, чтобы понять, подходит ли вашему проекту Agile. И как как заинтересовать руководство в переходе на Agile.
Эта статья поможет разобраться, как наладить кросс-функциональное взаимодействие, не ломая привычную структуру организации, даже если ваша компания пока не использует Agile-подходы.
Как развить гибкость, прозрачность и культуру постоянной обратной связи в традиционных организациях.
Практическое руководство для руководителей, проектных и продуктовых команд.
Есть два способа, как относиться к дедлайнам — и только команда решает, на чём сосредоточиться в первую очередь, и что делать с теми задачами, которые не получается завершить в срок.
Люди исторически учились действовать небольшими шагами, пробуя, ошибаясь и корректируя свои шаги. Но почему тогда нам до сих пор непривычно думать, что любой проект можно делать частями, а не целиком.
Быть руководителем — это непросто. Чтобы хоть немного упростить работу менеджеров, мы собрали несколько полезных инструменты для работы с командой.
Когда Agile-принципы успешно работают на уровне одной-двух команд, может показаться, что достаточно просто сделать то же самое с десятком команд. Но на практике при масштабировании без адаптации подхода начинается хаос. В таких ситуациях и нужен LeSS Huge — он разработан для случаев, когда над одним продуктом трудятся больше восьми команд.
Внедрение LeSS может проходить по-разному в зависимости от типа компании — в классических корпорациях, продуктовых стартапах или аутсорсинговых командах есть свои особенности. Существует пошаговый план, который помогает организации честно взглянуть на себя и избавиться от всего лишнего.
Некоторые организации при масштабировании начинают добавлять новые уровни управления, усложнять схемы взаимодействия и вводить дополнительные артефакты и встречи. Несмотря на все эти усилия, реального прогресса не происходит, потому что игнорируются базовые принципы. LeSS помогает понять, какие решения действительно улучшат систему разработки, а какие лишь создадут лишь видимость прогресса.
Large Scale Scrum (LeSS) — это такая среда, где десятки команд могут эффективно работать над одним продуктом, не жертвуя при этом качеством. Если внести изменения в продукт сложно и это занимает много времени, никакая реорганизация команд или введение новых ролей не сделает компанию по-настоящему адаптивной. LeSS помогает понять, как сохранить высокое качество продукта, даже когда над ним работают много команд одновременно.
В LeSS все команды работают над единым продуктом, поэтому используется один общий бэклог, синхронизированные спринты, и в результате получается один общий инкремент продукта. Планирование спринта в LeSS проходит в два этапа — сначала собираются представители всех команд, чтобы согласовать, кто и что берёт в работу, а потом каждая команда отдельно решает, как будет выполнять свои задачи.
В основе LeSS лежит простая идея, что для масштабирования Scrum не требуется вводить новые роли. При этом LeSS сознательно упрощает организационную структуру, убирая лишние иерархические уровни и передавая больше ответственности кросс-функциональным командам. Рассмотрим, чем LeSS отличается от классического Scrum и как при этом трансформируются роли менеджера, Scrum-мастера, Product Ownera и отдельных специалистов.
Многие компании стремятся масштабировать Scrum на уровень отдела или всей организации, потому что он показывает высокую эффективность при работе одной команды. Однако при добавлении новых Scrum-команд производительность не увеличивается линейно — напротив, это может привести к снижению общей эффективности. LeSS помогает решить эту проблему.
Модель приоритизации ICE – это инструмент, который помогает менеджерам и командам определить, какие проекты или идеи следует реализовать в первую очередь, а какие пока можно отложить.
В мире, где измеряемые показатели становятся заменой стратегии, важно помнить о роли и значении последней. История Wells Fargo - лишь один пример того, как неверный подход к метрикам может подорвать долгосрочные отношения с клиентами и угрожать стратегическому успеху компании. В этой статье мы рассмотрим, как правильно выбирать и использовать метрики, чтобы они служили укреплению и поддержке стратегии, а не становились причиной ее утраты.
В мире разработки программных продуктов Agile зарекомендовал себя как эффективный подход, позволяющий командам быстро реагировать на изменения и поставлять качественный результат. Но как именно мы обеспечиваем это качество в среде, которая ценит гибкость и открытость изменениям?
В современном мире мы часто слышим о необходимости движения к самоорганизованным командам. Компании заинтересованы в этом, так как это позволяет не только повысить скорость принятия решений, но и раскрыть потенциал команды, который, как известно, кратно превосходит индивидуальный.
Международный консорциум ICAgile обновил требования к обучению Владельцев продуктов. Мы уже дополнили и сертифицировали обновленную программу тренинга Advanced Product Ownership и спешим рассказать вам, какие у компаний ожидания от роли Владельца продукта.
Что такое PI планирование, или Планирование инкремента продукта, когда используется и как его проводить.
Итак, пришло время разобраться с нетипичными для Agile ролями, присутствующими в Scaled Agile фреймворке: Машинист (Release Train Engineer), Архитектор решения и Системный архитектор.
Один из самых популярных фреймворков масштабирования организации — SAFe, или Scaled Agile Framework. Разбираемся, на чем он основан и какие роли есть в SAFe.
Начинаем серию статей, посвященных развитию организации и росту численности команды. Подробно поговорим о фреймворках масштабирования SAFe, LeSS, Nexus, о модели Spotify и других гибридных решениях.
Команда OnAgile подготовила для вас несколько рекомендаций, которые помогут подготовиться к первой рабочей неделе и начать работу максимально продуктивно.
Последнее время наши клиенты часто просят помочь им подобрать персонал. Нужно наполнять команды, а еще нанимать людей на специфичные роли: Скрам-мастеров, Владельцев продуктов, Менеджеров поставок. Ключевой вопрос не «где найти сотрудников», а «как захантить "своих" людей».
В отличие от классического подхода, в Agile единица ресурса не специалист, а команда. А именно команда мотивированных профессионалов, которая обладает компетенцией преобразовать бизнес-идею в готовый продукт. Так как же перейти от группы специалистов к команде мотивированных профессионалов?
Нанять профессионала с рынка или выбрать из участников команды? Разбираем критерии выбора Скрам-мастера.
Давайте порассуждаем об HR с точки зрения сервисной парадигмы и возможности использовать некоторые agile-практики.
Коротко: это все тот же Scrum. Если вы не занимаетесь процессами на ежедневной основе, кардинальные отличия заметить будет непросто. Однако есть несколько важных вещей, которые обновились, и мы очень хотим обсудить их с вами.
Несмотря на то, что в базовом варианте работа agile-команды не предполагает такую процедуру как Управление проектом (как и саму роль менеджера проекта), часто бывает полезно применять хорошие практики, наработанные в рамках стандартных процедур управления проектами. Одна из них — анализ стейкхолдеров проекта.
Узнайте, как объективно оценить эффективность Скрам-мастера с помощью трех ключевых критериев, которые выходят за рамки стандартных метрик и позволяют измерить реальный вклад человека в этой роли в успех команды и продукта.
Третий подход к оценке задач, NoEstimates — один из самых интересных. Что если перестать оценивать задачи вообще?
Какие ошибки мешают создавать успешный продукт. Как развивать видение продукта и работать с бэклогом. Важные цитаты из книги «Управление продуктом в Scrum: Agile-методы для вашего бизнеса» Романа Пихлера.
Почему так сложно верно оценивать работы по созданию нового продукта — и какими способами можно улучшить точность оценки, не делая это процесс сложнее.
Существует миф, что Agile означает исчезновение мидл-менеджмента. Потребность в менеджменте действительно снижается, но у организации появляется необходимость в других ролях.
Метод Канбан эффективно работает как в ИТ, так и в других сферах: в производственных компаниях, в строительстве, закупках, HR и др. Рассмотрим, как его применяют российские компании.
Ключевые принципы и подходы к управлению персоналом в компании, начинающей трансформацию.
Agile-подход дает огромные возможности, однако как любые значимые организационные и культурные изменения, процесс перехода сопровождается риском.
Ключевые паттерны декомпозиции бэклога продукта, сервиса или процесса.
Концепция Jobs To Be Done помогает определиться с видением продукта и отдельными его функциями, которые будут привлекательны для пользователей.
Planning poker — техника командной оценки задач в относительных единицах. Впервые описана в 2002 году Джеймсом Гренингом, одним из авторов Agile-манифеста. В дальнейшем популяризирована Майком Коном в книге «Agile Estimating and Planning».
Как упорядочить бэклог и определить, какие элементы следует выполнить в первую очередь? Обратимся к математике и рассмотрим простой инструмент Weighted Shortest Job First.
При внедрении Scrum появляются две новые роли: владелец продукта и скрам-мастер. И часто бывает, что на них решают назначить одного человека — обычно это менеджер проекта или тимлид. Но это не лучшее решение.
Принятие решений: в каких условиях наиболее эффективно коллективное обсуждение, а в каких полезнее иерархическое управление?
Спринты вместо семестров и вовлеченные команды вместо скучающих слушателей лекций.
Что такое Scrum, и почему он крайне эффективен в современном мире. Практика ограничения одновременно выполняемой работы.
Мы собрали для вас список самых важных книг на тему Agile и всего того, что пригодится на нелегком пути трансформации. Они могут вам самостоятельно изучить подход, а также закрепить и расширить полученные на тренингах знания.
STATIK - Systems Thinking Approach to Introducing Kanban - это системное мышление при внедрении Канбан-метода. 8 ключевых шагов, позволяющих внедрить Kanban-метод в организации.
Вовлеченность и мотивированность сотрудников влияет в конечном счете на клиентский опыт. Но зачастую организации не уделяют достаточно внимания этим аспектам, фокусируясь на извлечении прибыли. Как начать изменять опыт сотрудников к лучшему?
Задача: ускорить поставку результатов проекта, сократить время принятия решений и обеспечить прозрачный процесс изменения приоритетов. Принципы, затронутые в статье, применимы как к выполнению одного проекта, так и к координации нескольких.
Цифровая трансформация стала частью стратегии большинства традиционных компаний в любой отрасли. Однако часто проходят месяцы с момента запуска инициативы внутри компании, но никакие значимые результаты не достигнуты. Почему так происходит?
Основные причины, мешающие традиционным компаниям вставать на путь гибкости и уверенно по нему идти.
Нередко от Agile-команд можно услышать недовольство о нехватке времени, поскольку большую часть времени люди стали проводить в «бесконечных встречах».
Краткое изложение ключевых идей «Руководства по использованию Канбан для Скрам-команд» (ориг. назв. «The Kanban Guide for Scrum Teams»), опубликованного Scrum.org в феврале 2018 года.
Важные цитаты из книги С. Альварес «Как создать продукт, который купят. Метод Lean Customer Development».
Компании, уже освоившие новые модели или только вступившие на путь трансформации, нуждаются в HR-службе нового поколения.
Миф связан с распространяющимся иногда суждением, что Agile требует, чтобы каждый член команды обладал всеми необходимыми навыками для создания ценности клиенту.
Миф связан с некорректной интерпретацией термина «самоорганизация» — отсутствие менеджмента, бесконтрольные действия людей. Однако в самоорганизацию вложен совсем иной смысл.
Комплексная трансформация бизнеса — это трансформация бизнеса целиком, и в первую очередь — это изменение культуры компании или группы компаний.
Сегодня термин «трансформация» в отношении бизнеса используется повсеместно. Однако нет единого понимания его значения. Каждый вкладывает в трансформацию собственный смысл. Особенно, когда речь заходит об Agile-трансформации.
Только лишь исправления отдельных ошибок в процессе недостаточно. Иногда стоит разобраться, что на самом деле важно для клиента — и систематически устранять из процесса всё, что ценностью не является.
Все самое важное о Scrum коротко.
С 2015 года мы помогаем адаптировать к изменениям культуру и процессы компании
Связаться с нами
Дмитрий Лобасев
Managing Partner
+7 495 221 87 39
dmitry@onagile.ru
Наш Telegram канал об Agile и гибких организациях, присоединяйтесь!