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

Позже, в 2007 году, Кен написал книгу об адаптации Scrum на уровень организации, The Enterprise and Scrum[12]. Он описал стратегию и тактику для этой адаптации. Тактика применения Scrum для управления самой трансформацией также объяснялась.

Глубокое, но переходное изменение

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

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

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

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

Компания Primavera служит примером такого типа трансформации. Primavera производит пакет программного обеспечения для управления проектами, TeamPlay, созданного для индустрии разработки программного обеспечения. Все аспекты каскадного процесса автоматизированы в этом продукте. В начале 2000-х Primavera билась изо всех сил, чтобы закончить новый релиз TeamPlay. Выпуск выбился из графика, стоил дорого, был не закончен и имел неудовлетворительное качество. В 2003 году Primavera изучала использование Scrum. Возглавляемая Бобом Шацем, исполнительным директором по разработке программного обеспечения, организация трансформировала себя. Управление продуктами, продвижением, продажами, штатный персонал, поддержка и разработка продукта – все стало гибким, приспособленным и в высшей степени конкурентоспособным. Ирония была в том, что Primavera использовала эмпирический процесс, Scrum, для создания инструмента для предиктивного процесса TeamPlay. Вся история рассказана на сайте Боба[13].

Боб покинул Primavera в 2005 году. Его главный помощник Ибрагим Абдельсафи ушел из компании почти сразу за ним. СТО и СЕО Primavera действительно никогда не нравился Scrum – точнее, их устраивали результаты, но не устраивало, что это подрывает использование их продуктов. Когда Боб и Ибрагим покинули компанию, не осталось высшего руководства, приверженного Scrum. Все использовали форму Scrum, но делали это все хуже и хуже. Прозрачность стала затуманиваться, предсказуемость пропала и так далее. Когда в 2008 году компания Oracle приобрела Primavera, она была лучше, чем до использования Scrum, но уже не превосходна. Важно отметить, что сотрудники больше не мечтали скорее прийти на работу и делать великие дела.

Глубокие и стойкие изменения

Наиболее успешная персона в организации – топ-менеджер, который разворачивает Scrum по всей компании. Этот человек знает, что требуется, чтобы добиться значительных организационных преобразований. Он знает, что культурная трансформация должна быть глубокой и полной, чтобы затронуть корни. Когда такой человек описывает успехи, он говорит не о том, что сделал он, а о том, что сделали другие. Джон П. Коттер, профессор Гарвардской школы бизнеса и автор книг по изменениям, сказал: «Когда я иду говорить с CEO о трансформации организации, он обычно просит меня провести встречу с ним и его персоналом. Если его персонал участвует в разговоре, я высоко оцениваю их шансы на успех. Если все переговоры ведет руководитель, у организации нет ни единого шанса».

Настоящие изменения могут быть достигнуты старомодным путем: с помощью упорного труда. Чтобы трансформация произошла как надо, вся организация должна понять новую культуру и создать ее. Даже при вынужденных обстоятельствах трансформация организации – очень сложная задача. Коттер, один из самых профессиональных агентов по внедрению изменений, посчитал, что этот тип трансформации требует от пяти до семи лет и только 30 % организаций успешно изменяются. Мы должны посмотреть на General Motors, Ford и Chrysler. Перед лицом жесткой конкуренции они не смогли поменяться за 40 лет, и только сейчас изменения начинают проявляться.

Если вы заинтересованы в таком типе изменений, мы адресуем вас к экспертам. Советуем начать с прекрасных книг Коттера, включая Leading Change[14] и Changing and Succeeding under Any Conditions[15]. Затем свяжитесь с его организацией или какой-либо другой, специализирующейся на организационных изменениях.

Трансформации и упорство компании Carbonite

Carbonite была основана в 2005 году и стала публичной компанией в августе 2011 года. Продукты компании предлагают автоматическое онлайн-резервирование персональных компьютеров, везде и в любое время. Роб Рубин, вице-президент по разработке, сотрудничал с основателями Carbonite, Джеффом Флауэрсом и Дэвидом Френдом, с самого начала. Это был их шестой стартап, поэтому Роб полагался на их дальновидность и управленческие качества, а Джефф и Дэвид полагались на профессионализм Роба в управлении разработкой. Тем не менее к 2008 году основной продукт Carbonite внутри называли «болото». Для выпуска нового релиза потребовалось очень много времени.

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

Как Carbonite сломала шаблон

Роб присутствовал на презентации Scrum в Массачусетском технологическом институте в 2006 году. Ему действительно понравилась идея, что Scrum даст ему то, что он сможет измерить. В работе по управлению измерение результатов было для него на первом месте, а действие основывалось на этом измерении. Без измерений невозможно управлять. Роб хотел, чтобы Scrum обеспечивал четкие, прозрачные измерения прогресса навстречу цели каждые 30 дней и надежное измерение прогресса следующих 30 дней каждый день. Роб также верил, что технологические проекты и продукты – трудные, потому что их природа сложна, невозможно предсказать, когда они потерпят неудачу. И неудачи в них случайны. Ежедневная и 30-дневная информация о прогрессе или неудаче может быть критической для такого типа работы.