Scrum на практике. Высокая продуктивность и результаты – прямо сейчас

Я спросил у аудитории, правда ли это. Многие кивнули. Несколько человек аплодировали.

Я спросил у scrum-мастеров, донесли ли они проблему до руководства. Они сказали, что сообщали об этом, но им приказали молчать.

Полгода спустя эта большая известная компания (не могу ее назвать, потому что подписал соглашение о конфиденциальности, чтобы войти в здание) уволила своего CEO из-за того, что доставка была недостаточно быстрой.

Проблемы порой легко заметить, но трудно решить. И иногда решение одной сложной, глубоко укоренившейся проблемы может занять много времени. Однако вам нужно начать что-то делать с ней. Если вы не будете ничего предпринимать, люди поймут, что их проблемы для вас мало что значат.

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

Однажды мне позвонил старый друг. Он работал над крупным журналистским проектом, который проводили по всей стране и в котором участвовали десятки репортеров и редакторов. И он не мог продвинуться. Как и весь проект. Для некоторых задач им нужны были подтверждения, но получить их не удавалось. Вице-президент был занят. Он не отвечал на электронную почту. Или говорил: «Скажите scrum-мастеру, что я этим займусь, а сейчас мне нужно быть на важном совещании».

Я сказал моему другу, чтобы он использовал стикеры: расклеил их по стене, обозначив работу, которую нужно выполнить, чтобы было видно, какой стикер блокирует решение остальных задач. Затем достал телефон, сделал фотографию и отправил ее не только нужному вице-президенту, но и всем остальным вице-президентам тоже. Обходительно. Вежливо. Но повторяя процедуру каждый день: «Добрый день, хотел сказать, что мы по-прежнему не можем продвинуться. Спасибо большое, что помогаете с решением этого вопроса с учетом вашей загруженности». Проблема исчезла через три дня.

Решайте возникающие проблемы. Хотя бы начните ими заниматься. Покажите людям, что вы делаете для решения проблем. Так вы очень четко даете понять, что обязуетесь стать scrum-компанией.

Сфокусированность на том, что работает

ВАША ЖИЗНЬ ЗАВИСИТ ОТ ВЛАДЕЛЬЦЕВ ПРОДУКТА

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

Но иногда эта работа считается неважной. Или компания меняет название должности с «бизнес-аналитика» на «владельца продукта» и оставляет полномочия прежними. Или выбирает очень занятого менеджера и говорит ему: «Привет, ты теперь еще и владелец продукта. Но и старые обязанности не забывай». Или исполнительный директор очень хочет быть владельцем продукта, но у него нет времени на взаимодействие с командой. Или вы назначили технического руководителя владельцем продукта, и он не поддерживает диалог со стейкхолдерами или потребителями. Если вы продолжаете действовать так же, как раньше, то и ваши результаты останутся прежними. Хорошие владельцы продуктов – ключ к успеху в Scrum.

Ведущий владелец продукта в Scrum Inc. Патрик Роуч описывает это так: «Вы направляете экспедицию в неизвестность, и успех предприятия будет зависеть от вашей стратегии действий. Выживание зависит от вашей способности вдохновлять творчество в тех, кто вокруг вас, иначе вы неизбежно потерпите фиаско. Это головокружительная роль, которая может повлечь тяжкие последствия». Причем очень тяжкие.

Одно из самых грустных зрелищ, которым я был свидетелем, – ситуация, когда очень хорошие люди выполняют по-настоящему невероятную работу и очень быстро, но заняты неправильным делом. Или действуют неправильно. Приведу два примера. Nokia Mobile всего за несколько лет прошла путь от лидера индустрии до полной несообразности. При этом у нее были очень хорошие scrum-команды. Быстрые. Даже был Nokia-тест, который определял, гибкие вы или нет, с помощью вопросов, например: «Сколько длится спринт в вашей организации? У вас есть владелец продукта? А диаграмма сгорания задач? У вас есть приоритизированный бэклог?»

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