Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

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

Во время подготовки трансформации команда очерчивает начальную задачи и создает бэклог. Например, задача начала обсуждения следующих этапов деятельности определяется, разбивается на пункты, проясняется и заносится в бэклог трансформации. Работа упорядочена и проверяется в течение времени. Из этого выкристаллизовываются конкретные проекты. Эти проекты – спринты, а инкремент изменения организационной структуры – результат каждого спринта. (Следующая глава, «Скрамить Scrum», объясняет, как команда трансформации использует Scrum для управления трансформацией.)

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

Должна быть создана четкая стратегия связей по трансформации. Это действие заложено в табл. 9.3. Вне зависимости от того, какие связи имеют место, их всегда недостаточно. Во время работы с организациями мы слышим невероятные вещи, которые принимались за правду. Часто тому причиной становится недостаток ясности. Если люди беспокоятся, потому что они не знают, что делать, или не знают, как делать что-либо, значит, средства связи неэффективны.

Таблица 9.3. Связь видения и стратегии

Плохая коммуникация – причина непрозрачности, сплетен и слухов. Информация, которую разрабатывает и распространяет команда трансформации, должна быть ясной. Уведомление о необходимости трансформации должна идти сверху вниз, снизу вверх и во всех направлениях. Информирование о новом видении и стратегиях должно проводиться всеми способами, включая презентации, распоряжения руководства, рабочие заседания, неформальные форумы, соревнования. Это следует делать на обедах, встречах один на один с сотрудниками, которые обеспокоены судьбой компании, в блогах, почтовых рассылках, в документах и при личном посещении командой трансформации и руководством всех подразделений организации. Общение должно быть частым, актуальным и постоянным.

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

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

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

Сопротивление принимает множество форм, и самая пагубная из них – пассивное сопротивление. Люди не протестуют, они не спорят и не возражают. Они не хотят быть отождествлены как помеха, но они не хотят меняться.

Жизненно важно усадить менеджеров и остальных сотрудников в одну лодку перед приближением перемен. Эти люди – основа организации. Они знают свое дело, потребителей, системы и продукты. Без них не будет изменений.

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

Менеджеры и другие сотрудники должны провести небольшие собрания внутри отделов для ответов на вопросы. Следует подготовить проспекты, описывающие объявленные решения руководства. Покидая это собрание, сотрудники должны знать, с кем связаться внутри организации для получения ответов на возникшие вопросы.

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

Первые проекты по разработке программного обеспечения начинаются в действии 3 (табл. 9.4). Ваша организация уже имеет некоторый опыт работы со Scrum, из пилотного проекта ( глава 3), разовых проектов ( глава 4) или работы Scrum-студии ( глава 5). Эти проекты – часть устойчивого внедрения и использования Scrum путем разработки продуктов организаций. Также они – причина изменений во всех смежных областях.

Таблица 9.4. Распространение по всей организации

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

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

Уберите очевидные препятствия . Начните устранять некоторые из хорошо известных помех. Каждый должен иметь список вещей, продуктивных для разработки программного обеспечения. Измените то, что сейчас требуется, но раздражает. Обременительные циклы проверок и согласования – обычно первое, что можно урезать. Найдите еще элементы для раннего исключения. Люди начнут верить, что происходит что-то особенное, выгодное для них.