Хватит зацикливаться на «командах»
Речь идет о Scrum-командах. Функциональных командах. Каждая команда нуждается в PO. Самоорганизующаяся команда. Командные мероприятия / ритуалы. Помогите команде. Служите команде! Защитите команду. Фокусируйтесь локально! Будьте shit umbrella!
Звучит знакомо?
В этом посте я расскажу, почему не нужно фокусироваться на «командах», пока не будут созданы условия для эффективных команд.
Большинство Agile-методологий / фреймворков сфокусированы на «командах» (фронтовых командах отдельных участников). Между тем организационные дисфункции (те, которые вызывают 80% перетаскиваний) сохраняются. Это не из-за отсутствия предупреждения. Scrum явно заявляет о необходимости самостоятельных команд:
Команды Scrum являются самоорганизующимися и кросс-функциональными. Самоорганизующиеся команды выбирают, как лучше всего выполнять свою работу, и не управляются другими за пределами команды. Кросс-функциональные команды обладают всеми компетенциями, необходимыми для выполнения работы, в отличие от других, не входящих в состав команды.
… но почему-то это не считается предпосылкой для «выполнения Scrum».
Некоторые из ролей Scrum Master — «защищать» команду от реалий и разрешать их на стороне.
Мы не хотим, чтобы наши разработчики слишком беспокоились. Нужно, чтобы они сосредоточились на том, чтобы принести пользу и сдержать все обещания. Непрерывное улучшение — работа [менеджера] и [менеджера] за кулисами.
Мы нанимаем балансировщиков нагрузки (менеджеров проектов, менеджеров программ, менеджеров) для определения зависимостей между командами. Мы нанимаем Scrum Masters для «устранения блокировщиков и препятствий», в то время как команда работает над поставкой эффективных решений и изображают Scrum. Мы используем масштабированный фреймворк, освобождаем менеджеров, чтобы «скоординировать работу сотен разработчиков». Каков конечный результат? Команды остаются разорванными и спотыкающимися. Теоретически у них есть поддержка, но у них связаны руки зависимостями и слоями “поддержки” управления.
Вот в чем проблема…
Если у вас есть 20 команд, которые борются с веб-зависимостями, передачами, ограничениями, дело не сдвинется с мертвой точки. Команды Product Owner и Scrum Master будут лишь делать вид, что «владеют продуктом», запускать задачи, ретроспективы, а также предоставлять им собственную доску. никогда ничего не сдвинут с мертвой точки. Реальность такова, у вас в «команде» 150 человек, и нужно разбираться с этим.
Почему мы начинаем с уровня команды? Это проще! Команды легко поддаются влиянию. Во многих случаях организация придумывает интересный рассказ о том, что команды «были / являются проблемой». Такое редко происходит на практике. Спросите любого работающего в бизнесе инструктора. Командные задачи являются симптомом «проблемы», и инструкторы редко могут выявить источник проблемы если он находятся за пределами команд.
Уровни управления — связные роли, почему-то предназначены для решения проблем, никогда похоже, не двигаются и не пересматривают свои роли. Они образуют царства, где они остаются незаменимыми. Конечным результатом является то, что команды не становятся более автономными и самоорганизующимися, и организация никогда не осознает свой потенциал.
На мой взгляд, это одна из самых больших, если не самая большая, проблема, когда дело доходит до действительно более гибкого и прочного пути. Мы начинаем с того, что легко, но не пытаемся изменить то, что сложно. Команды всегда виноваты в том, что не приняли [путь], когда это невозможно. У команды едва ли хватит времени на постоянное совершенствование.
Утопия «Бизнес» и «Разработчики / Команды» неосуществима ни в одной организации с >1 командами, пытающимися наложить Scrum на существующие структуры, зависимости и культуру проекта.
Так… сумасбродные мысли.
Забудьте об Agile и Scrum на уровне команды. Начните с организации. Визуализируйте работу со всеми зависимостями. Имейте 150 человек, выполняющих задачи, если это действительный размер команды. Имейте 150 человек, голосующих за блокаторов, которые действительно имеют значение, и сворм для починки блокаторов. Встретьтесь с беспорядком лицом к лицу, перебирайте и совершенствуйте. Меняйте и реформируйте команды, чтобы динамично устранять самые большие блокаторы. Не нанимайте балансировщиков нагрузки, чтобы сохранить статус-кво. Фокусируйтесь на DevOps, инструментарии и распутывании политической иерархии, которая перегружает и злоупотребляет командами.
Будут ли встречи труднее? Да. Но это реальность. Вы не можете спрятаться.
Когда у вас уже есть автономные, самоорганизующиеся команды… введите Scrum. До тех пор используйте уровень программы / бизнес-уровень Kanban, чтобы видеть вещи такими, какие они есть, и работать над ними.
Это тяжелое решение, от которого мы склонны отступать. Сделай это!
Оригинал: Stop Obsessing Over “The Teams”.
