8. Scrum на уровне организации
Многие организации принимают решение перейти на Scrum. Как и в случаях со многими другими типами организационных преобразований, результаты зависят от многих факторов. Некоторые фактические результаты описаны в этой главе наряду с обстановкой, которая создана для каждого из них.
Мы работали со многими организациями, большими и маленькими, чтобы помочь им трансформироваться и получить эти преимущества. Первая публикация об этих усилиях, The Playbook for Achieving Enterprise Agility («Пособие для достижения бизнес-гибкости»), выпущена в 2005 году в результате сотрудничества Кена Швабера с корпорацией Rally. Она не была доступна широкой публике, но часто используется при развертывании Scrum. С этой публикацией можно ознакомиться в .
Позже, в 2007 году, Кен написал книгу об адаптации Scrum на уровень организации, The Enterprise and Scrum. Он описал стратегию и тактику для этой адаптации. Тактика применения Scrum для управления самой трансформацией также объяснялась.
Глубокое, но переходное изменение
Тип адаптации, который мы уже увидели, как правило, весьма приятен. Организация регулярно выпускает качественные, ценные релизы программного обеспечения, и они хорошо принимаются пользователями. Отделы разработки и продвижения продуктов эффективно работают вместе, чтобы формулировать и предоставлять новые релизы.
В процессе перехода к Scrum вся работа организации переворачивается, находясь в контролируемом хаосе в течение нескольких лет.
В конечном счете релизы программного обеспечения станут лучше, сотрудники будут ходить на работу с удовольствием, а потребители полюбят сотрудничество с вашей организацией. Тем не менее преобразование зависит от высшего руководства, которое его запускает. Очень часто этот человек идет на повышение, или его нанимают где-то еще до того, как другие люди, которые понимают новый способ мышления и работы, развиваются в рамках всей организации, и до того, как трансформации закреплены в самой организации. Поэтому, когда он покидает организацию, улучшения не закрепляются. Старая культура работы, на которую новые методы накладывались, не искоренена полностью и вновь проявляет себя. Совершенство и непрерывное улучшение медленно снижаются. Организация остается во много раз лучше, чем она была до того, как стала использовать Scrum, но не на том уровне, на котором могла бы быть. Люди начинают стараться. В течение нескольких лет организация становится лучше, чем в самом начале, но это еще не гибкая Scrum-организация. Возможность была упущена.
Сравнивая записи, мы обнаружили, что это правда почти для каждой преобразованной компании, которую мы знаем и в которой принимали участие.
Компания Primavera служит примером такого типа трансформации. Primavera производит пакет программного обеспечения для управления проектами, TeamPlay, созданного для индустрии разработки программного обеспечения. Все аспекты каскадного процесса автоматизированы в этом продукте. В начале 2000-х Primavera билась изо всех сил, чтобы закончить новый релиз TeamPlay. Выпуск выбился из графика, стоил дорого, был не закончен и имел неудовлетворительное качество. В 2003 году Primavera изучала использование Scrum. Возглавляемая Бобом Шацем, исполнительным директором по разработке программного обеспечения, организация трансформировала себя. Управление продуктами, продвижением, продажами, штатный персонал, поддержка и разработка продукта – все стало гибким, приспособленным и в высшей степени конкурентоспособным. Ирония была в том, что Primavera использовала эмпирический процесс, Scrum, для создания инструмента для предиктивного процесса TeamPlay. Вся история рассказана на сайте Боба.
Боб покинул Primavera в 2005 году. Его главный помощник Ибрагим Абдельсафи ушел из компании почти сразу за ним. СТО и СЕО Primavera действительно никогда не нравился Scrum – точнее, их устраивали результаты, но не устраивало, что это подрывает использование их продуктов. Когда Боб и Ибрагим покинули компанию, не осталось высшего руководства, приверженного Scrum. Все использовали форму Scrum, но делали это все хуже и хуже. Прозрачность стала затуманиваться, предсказуемость пропала и так далее. Когда в 2008 году компания Oracle приобрела Primavera, она была лучше, чем до использования Scrum, но уже не превосходна. Важно отметить, что сотрудники больше не мечтали скорее прийти на работу и делать великие дела.
Глубокие и стойкие изменения
Наиболее успешная персона в организации – топ-менеджер, который разворачивает Scrum по всей компании. Этот человек знает, что требуется, чтобы добиться значительных организационных преобразований. Он знает, что культурная трансформация должна быть глубокой и полной, чтобы затронуть корни. Когда такой человек описывает успехи, он говорит не о том, что сделал он, а о том, что сделали другие. Джон П. Коттер, профессор Гарвардской школы бизнеса и автор книг по изменениям, сказал: «Когда я иду говорить с CEO о трансформации организации, он обычно просит меня провести встречу с ним и его персоналом. Если его персонал участвует в разговоре, я высоко оцениваю их шансы на успех. Если все переговоры ведет руководитель, у организации нет ни единого шанса».
Настоящие изменения могут быть достигнуты старомодным путем: с помощью упорного труда. Чтобы трансформация произошла как надо, вся организация должна понять новую культуру и создать ее. Даже при вынужденных обстоятельствах трансформация организации – очень сложная задача. Коттер, один из самых профессиональных агентов по внедрению изменений, посчитал, что этот тип трансформации требует от пяти до семи лет и только 30 % организаций успешно изменяются. Мы должны посмотреть на General Motors, Ford и Chrysler. Перед лицом жесткой конкуренции они не смогли поменяться за 40 лет, и только сейчас изменения начинают проявляться.
Если вы заинтересованы в таком типе изменений, мы адресуем вас к экспертам. Советуем начать с прекрасных книг Коттера, включая Leading Change и Changing and Succeeding under Any Conditions. Затем свяжитесь с его организацией или какой-либо другой, специализирующейся на организационных изменениях.
Трансформации и упорство компании Carbonite
Carbonite была основана в 2005 году и стала публичной компанией в августе 2011 года. Продукты компании предлагают автоматическое онлайн-резервирование персональных компьютеров, везде и в любое время. Роб Рубин, вице-президент по разработке, сотрудничал с основателями Carbonite, Джеффом Флауэрсом и Дэвидом Френдом, с самого начала. Это был их шестой стартап, поэтому Роб полагался на их дальновидность и управленческие качества, а Джефф и Дэвид полагались на профессионализм Роба в управлении разработкой. Тем не менее к 2008 году основной продукт Carbonite внутри называли «болото». Для выпуска нового релиза потребовалось очень много времени.
В 2008 году у Carbonite было семь высококлассных разработчиков, но все они работали не в офисе, а удаленно. Имелось также семь владельцев продуктов, каждый со своей сложной задачей высочайшей важности.
Как Carbonite сломала шаблон
Роб присутствовал на презентации Scrum в Массачусетском технологическом институте в 2006 году. Ему действительно понравилась идея, что Scrum даст ему то, что он сможет измерить. В работе по управлению измерение результатов было для него на первом месте, а действие основывалось на этом измерении. Без измерений невозможно управлять. Роб хотел, чтобы Scrum обеспечивал четкие, прозрачные измерения прогресса навстречу цели каждые 30 дней и надежное измерение прогресса следующих 30 дней каждый день. Роб также верил, что технологические проекты и продукты – трудные, потому что их природа сложна, невозможно предсказать, когда они потерпят неудачу. И неудачи в них случайны. Ежедневная и 30-дневная информация о прогрессе или неудаче может быть критической для такого типа работы.
Результаты
Роб обучил свою организацию Scrum в 2008 году. С тех пор Carbonite улучшил свой цикл выпуска продуктов, распространившись по всему миру. На недавней презентации Роб и Джефф Флауэрс сообщили, что без Scrum Carbonite никогда бы не смогла стать публичной компанией. Scrum дал организации стандартный процесс для внутреннего пользования и расширения компании. Самое ценное – то, что Scrum не был навязчивым. Если компания, внедряющая его, уже имела высокий уровень мастерства и налаженные процессы, Scrum сохранял их, их оказалось легко комбинировать с моделью Scrum для обеспечения нужной измеримости и предсказуемости.
Роб и Джефф верили в своих сотрудников. Они использовали Scrum, чтобы создать окружающую среду, в которой сотрудники Carbonite могут быть креативными и работать эффективнее. Все они понимали суть проблем и работали вместе над их решением. В дополнение команды Carbonite в конце каждого спринта проводили ретроспективу. Это мероприятие было интенсивным. Все, что в работе могло быть сделано лучше и повышало производительность продукта, было открыто для дискуссий. Споры возникали жаркие, но продуктивные. Складывались крепкие рабочие команды, даже несмотря на то что количество сотрудников возросло с семи человек почти до сотни. Они создали свое будущее. В 2011 году «Бостонская деловая газета» назвала Carbonite одним из лучших рабочих мест в Бостоне.
Два непременных элемента для любой Scrum-адаптации
При попытке трансформации организации надо иметь в виду два предостережения.
Не пытайтесь изменить или адаптировать Scrum
Scrum – это не такой метод или процесс, который может быть изменен, чтобы приспособиться к существующей организационной культуре; культура должна быть изменена, чтобы Scrum заработал. Scrum устраняет все культурные дисфункции, которые мешают разработке программного обеспечения в манере, описанной в этой книге. Для организации Scrum – «канарейка в угольной шахте». Если Scrum не используется с целью создать гибкий, прозрачный процесс разработки, проблемы остаются невидимыми и продолжают наносить вред организации. В результате главная выгода от Scrum теряется.
Не сомневайтесь
Не пытайтесь облегчить организационные изменения. Важно, чтобы продвижение было очевидным, энергичным и первоначальный импульс сохранялся. После того как люди начинают использовать Scrum, наиболее важные препятствия легче идентифицировать. В некоторых организациях наблюдается тенденция излишне тщательно планировать и обдумывать. Это не подход Scrum.
Scrum требует действий, испытаний, оценки, изучения, устранения препятствий и более активных действий, для того чтобы создать вещи, представляющие ценность для всех заинтересованных сторон.