Была половина двенадцатого ночи, все еще находились в офисе, но никто и не думал работать. На днях команда запустила сайт Lolleaderz.com, и на него уже поступили отличные отзывы. Число пользователей росло. CEO наконец-то одобрил идею вечеринки по поводу этого удачного релиза, которую настойчиво предлагали Роджер и Ави. Он позвал диджея, организовал шведский стол с закусками и спиртными напитками. Роджер и Ави намеревались хорошенько выпить.
Роджер наткнулся на Эрика, который увлеченно болтал с несколькими членами команды, и сказал ему: «Мы бы никогда не сделали этого без тебя!»
Эрик немного подумал и ответил: «Очень мило с твоей стороны. Но сам посуди, что особенного я сделал? Я просто указал на некоторые проблемы и предложил решения, которые в свое время помогли мне самому. И время от времени я позволял вам столкнуться с некоторыми из этих трудностей, чтобы вы поняли, в чем их суть».
Подошел Ави со словами: «Так как насчет пары сложных моментов, с которыми все-таки пришлось столкнуться? Почему мы не смогли их избежать? Не подумай, что я жалуюсь, ведь полученные результаты говорят сами за себя».
К этому моменту возле них оказалась большая часть команды, а также несколько менеджеров. Эрик сказал: «Если бы у тебя не было той тяжелой встречи с другими аккаунт-менеджерами, то сумели бы вы продвинуться вперед и объединить в проекте все пользовательские истории? Удалось бы вам оценить скорость работы над проектом и начать планировать свои спринты?»
Роджер задумался. «Так ты считаешь, что единственный способ чему-нибудь научиться – это нарваться на неприятности?»
На это Эрик ответил: «Я бы предложил взглянуть на ситуацию с другой стороны – позитивной – и стать более эффективными. Когда вы ищете способы совершенствования, вы растете как команда».
Все присутствующие заулыбались и закивали. Откуда-то из-за спин собравшихся прозвучало: «Именно это я и хотел услышать!»
Это сказал CEO, выглядевший очень довольным. «Я вижу, что у этой команды большое будущее. Отличная работа!»
Переосмысление scrum-ценностей
В ходе проекта Lolleaderz.com Роджер, Ави и команда встретились с множеством трудностей. Многие команды, столкнувшись с подобными проблемами, провалили бы проект. Как же этой команде удалось превратить проблемы в возможности? Как они смогли извлечь опыт из своих ошибок и достичь успеха?
Одна из важных причин – наличие эффективного наставника, Эрика, который помог им преодолеть препятствия. Прежде всего Эрик помог Роджеру, Ави и остальным членам команды вникнуть в ценности Scrum: мужество, приверженность, уважение, сосредоточенность и открытость. Он рассказывал им про «свиней» и «кур», чтобы они поняли, что такое «приверженность». Он помог им понять, как сделать ежедневные scrum-митинги эффективнее и стать более сосредоточенными. И он показал им, как научиться взаимному уважению, начав прислушиваться друг к другу. Эрик помог улучшить планирование и организацию спринтов и бэклога с использованием таких инструментов, как пользовательские истории и скорость. Это сделало команду более открытой для всех, включая других аккаунт-менеджеров и CEO. И когда настали трудные времена, Эрик показал им, как важно иметь мужество говорить правду, даже если это на какое-то время приводит к неприятным последствиям.
Каждый проект имеет свои проблемы и вызовы. Когда вы пробуете новую методику впервые, эти проблемы могут усугубляться из-за отсутствия опыта, непонимания или повторения старых ошибок. Хороший наставник, такой как Эрик, знает это. Вместо того чтобы пытаться избежать ошибок, он воспользовался ими, чтобы создать учебные ситуации для команды. Это называется позволить команде неудачу, и такой прием – один из основных в арсенале коучинга.
Лисса Адкинс пишет об этом в уже упоминавшейся здесь книге Coaching Agile Teams:
Позвольте команде неудачу: конечно, это не значит хладнокровно наблюдать, как команда приближается к краю пропасти. Но используйте десятки возможностей, которые возникают в каждом спринте, чтобы позволить команде провалить одно из заданий. Команды, попадавшие в трудные ситуации и выходившие из них благодаря в том числе сплоченности, становятся крепче и работают быстрее по сравнению с теми, которых оберегали от неудач. Такая команда может удивить вас. То, что должно было причинить ей вред, сделало ее сильнее. Наблюдайте и ждите.
Одно дело – читать такие слова, как «мужество», «приверженность», «уважение», «сосредоточенность» и «открытость», и соглашаться, что они звучат как призыв. И совсем другое – пойти к руководству и сказать, что команда не успеет поставить ПО в срок, потому что ей не хватает времени в спринте. Трудно проявлять мужество, когда ситуация грозит вам увольнением.
Вы не сможете успешно внедрить Scrum, не придерживаясь этих ценностей. Но дело в том, что только часть компаний имеют культуру, совместимую со Scrum, а у остальных ее нет. Возможно даже, что ваш руководитель требует от вас командно-административного стиля управления проектами и вы будете уволены, если попытаетесь создать самоорганизующуюся команду.
Scrum-команды учатся на своих ошибках – благодаря этому они развиваются и двигаются вперед. Команда нуждается в культуре, при которой совершать ошибки – это норма. Именно поэтому мы так тесно сотрудничаем внутри scrum-команд и взаимоуважение так ценно. Но даже если команда терпима к ошибкам и способна учиться на них, может случиться, что она работает в компании, которая их не приемлет. Как пишет новатор в области разработки программного обеспечения Грэди Буч в своей книге Beautiful Teams:
Один из известных мне признаков здоровой компании – ее терпимость по отношению к возможному неуспеху. Компании, которые крайне негативно относятся к провалам, имеют тенденцию быть менее инновационными, и работать в них не очень-то весело, потому что люди настолько боятся неудач, что всегда излишне осторожничают. А компании, допускающие большую свободу действий (хотя и не настолько, чтобы подорвать бизнес) и позволяющие сотрудникам совершать ошибки, оказываются более продуктивными, потому что в них карьере работника не угрожает случайная оплошность, допущенная в коде.
Так что же делать, если вы обнаружили, что оказались в компании, где неудача означает увольнение? Возможен ли в ней хоть какой-нибудь Scrum?
Не каждая команда и не в любой компании может самостоятельно организоваться за один день, и это нормально. Если культура вашей компании не совпадает с принципами Scrum, то вы, как адепт этого подхода, должны разъяснять окружающим ее ценности. Лучше всего делать это на личном примере: показывать, что значит открытость в работе, уважение к другим членам команды, а также умение проявлять мужество при столкновении с трудностями. Найти хорошего наставника – отличный способ продемонстрировать людям, как работают принципы Scrum, и помочь им начать менять свое отношение к делу. Часто команды пытаются использовать консультантов как наставников. Это очень удобно для руководителей: следовать чужим советам в том, какие изменения надо внести.
Но иногда, даже если вы делаете все правильно, сложившаяся культура компании, в которой вы работаете, может быть слишком далека от ценностей Scrum. В этом случае самоорганизация и коллективные обязательства могут оказаться для вашей команды недостижимыми.
А по мнению Кена Швабера, не добившись самоорганизации и коллективной приверженности, вы не получите Scrum.
И это нормально!
Даже помимо безоговорочно принятых ценностей, самоорганизации и коллективной приверженности Scrum содержит множество полезных методов. Они очень просты, легки в применении, и, как правило, вы можете внедрить их внутри команды, не спрашивая разрешения у руководства (или позже извинившись за самодеятельность).
Даже если вы работаете в среде, где невозможно изменить существующие ценности, внедрение отдельных приемов Scrum может дать полезный результат. Вы должны так поступить, потому что лучше что-то делать, чем сидеть сложа руки. Просто убедитесь, что вы и ваша команда знаете, что делаете и где проходят границы ваших возможностей по внесению изменений.
Однако не стоит просто применять отдельные методы, а потом называть это полным внедрением Scrum. Поступив так, вы обрекаете себя на борьбу в дальнейшем. Сотрудники компании, читавшие о «гиперпродуктивных командах» и «потрясающих результатах», будут спрашивать, где все это. А у вас не найдется достойного ответа. Еще неприятнее, если команда, увлекшись Scrum и рассчитывая на радикальные улучшения, обнаружит, что для нее почти ничего не изменилось. В некотором смысле это равнозначно сигналу о том, что они достигли предела возможных изменений и дальнейшие улучшения производить нельзя. Это может расстроить и даже демотивировать работников. Такие проблемы создадут препятствия для внесения улучшений в будущем. Ведь если планка установлена слишком низко, то люди будут считать, что дальнейшие улучшения находятся вне их компетенции.
Иными словами, поздравляя окружающих с использованием новой методологии, вы будете создавать у них впечатление, что Scrum – это всего лишь переименование статус-митингов в ежедневные scrum-митинги, а требований – в бэклог. Это опасно для внедрения Agile, потому что фундаментальные проблемы, которые вы пытаетесь решить за счет Scrum, никуда не денутся. Большинство людей будет считать, что Scrum не может их исправить и даже что эти проблемы существуют везде и не имеют решения. Вспомните, сколько раз вы слышали фразы «Разработчики не могут заранее оценить объем работ», «Программное обеспечение постоянно глючит» или «Проекты никогда не выполняются в срок», произнесенные таким тоном, словно это законы бытия.
Хуже всего то, что, утверждая, будто Scrum может решить те проблемы, которые многим кажутся неразрешимыми в принципе, вы производите впечатление фанатика. Отсутствие явных результатов будет отталкивать людей от Scrum. Это повредит вашей карьере и настроит коллег против Scrum.