• Аgile-менеджмент

Управление меняется. Новые подходы[10] идут в ногу с Agile-принципами.

Тем не менее, все инициативы, претендующие на название Agile-менеджмент, исходят не от движения, появившегося вслед за Манифестом. Сейчас самое время попытаться определить, что такое Agility.

• Определение Agility

Джим Хайсмит, один из подписантов Манифеста, так определяет Agility по отношению к изменениям:

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

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

Agility – это способность организации приносить максимум ценности, часто и своевременно, и адаптироваться к изменениям в своей среде.

Из этого определения ясно, что гибкость относится не только к команде, но и к организации.

• Agile организация

Принципы освобожденных компаний (liberated companies) также имеют много общего с Agile-движением с точки зрения ценностей и важности человеческого фактора.

Работа Фредерика Лалу[11], посвященная успешным новым организациям, выдвигает на первый план принципы бирюзовых организаций (teal organisations), идущих в ногу с Agile.

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

Рисунок 1.5 – Agility – трамплин, чтобы выбраться с галеры на свободу

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

Для большинства организаций ценности и принципы Agility по-прежнему носят подрывной характер (хотя ценности при этом весьма быстро изымаются) и идут вразрез с доминирующей культурой.

Если организации, практикующие Scrum, не согласны с духом Agility, который несут Scrum-команды, несоответствие довольно скоро вызовет перебои. Необходим комплексный подход.

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

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

Это становится ясно на практике. Многие задачи невозможно решить внутри команды. Нужно обращаться к экосистеме, внутри которой развивается команда, в частности, к отношениям с заинтересованными сторонами.

В этом издании мы разработаем системный подход к Scrum.

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

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

Соотнесение Scrum и понятий пермакультуры поможет нам построить экосистему, которая будет долгое время приносить пользу многим людям.

Какова ситуация в отношении Scrum сегодня?

Повальное увлечение Scrum (Scrum-мания!) положило конец потенциальному соперничеству между Agile-методами. Изучение общественного мнения и веб-исследования показывают, что Scrum, без сомнения, является самым популярным.

В опросах три четверти респондентов утверждают, что используют Scrum или его варианты.

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

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

Вполне логично, что при нынешней популярности Scrum написано много статей, критикующих его и предлагающих другие подходы.

Появляются разочарованные, которые не находят в Scrum обещанных преимуществ: довольных клиентов, отдачи от инвестиций, меньшее количество дефектов, быстрый выход на рынок, удовлетворение от работы в команде и т. д.

Другие понимают Scrum лишь частично:

✓ Пользователи, долгое время находившиеся под гнетом директора по информационным технологиям (CIO), которые обнаруживают, что Scrum приветствует изменения, и думают: теперь можно постоянно все менять.

✓ Менеджеры, которые уверены, что Agilе-команда – на то и Agile, что может выполнять больше работы за меньшее время.

Реальность может их разочаровать. Мы постараемся дать ответ на эту критику и разочарования.

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

✓ Если вы разрабатываете приложения из категории несложных по модели Cynefin вероятно, Scrum для вас – не лучший выбор.

✓ Если ваша организация придерживается культуры контроля и вы не можете продвигать необходимымые радикальные изменения, то Scrum не для вас.

✓ Если вы работаете в режиме непрекращающихся срочных задач, вы не сможете сосредоточить команду на спринте. Когда все работают в спешке, использовать Scrum не рекомендуется – в такой ситуации больше подходит Kanban. Но мы увидим позднее, что есть возможность использовать Scrum вместе с Kanban.

Scrum приветствует изменения, но не когда они постоянные. При строгом следовании принципам Scrum рабочая команда не должна отвлекаться, а состав не должен нарушаться. Изменения допустимы в конце спринта, но не во время.

Мы за изменения, но против постоянных прерываний процесса!

Концепция Shu Ha Ri была создана Алистером Кокберном (подписал Манифест и предложил использовать слово agile). Это модель развития, взятая из айкидо. Shu соответствует фазе обучения, когда ученик повторяет за учителем, не пытаясь что-либо изменить.

✓ Ha – вторая фаза обучения. Ученик берет на себя инициативу и ответственность за то, что делает.

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

Тех, у кого проблемы со Scrum, можно, спросить: начали они с фазы Shu прежде, чем перейти к Ha? Сохранился при этом формат Scrum? Соблюдали они все принципы?

В противном случае существует риск исказить концепцию Scrum.

Контекстуализация без искажений – вот в чем загвоздка. Поскольку Scrum – это просто фреймворк, его нельзя использовать сам по себе, без адаптации к контексту.

Например, во время разработки ПО дополнительно пригодятся инженерные практики из Экстремального Программирования.