Требуется ли зрелой гибкой команде менеджмент?

После недавних жарких споров о Scrum я понял, что моя проблема в том, что я считаю управление совершенно ненужным и избыточным видом деятельности в полностью гибкой команде. Я считаю, что зрелая Agile команда не требует управления или какого-либо нетехнического процесса принятия решений. На мой взгляд (очевидно, с ошибками) более чем очевидно, что единственным подходящим и способным управлять зрелой командой разработчиков является их тренер (который является наиболее технически компетентным коллегой с надлежащими навыками общения). Я не могу себе представить, как мастер Scrum может внести вклад в такую ​​команду.

Мне очень трудно понять и понять ценность таких вещей в Scrum и менеджере как человек, который не является опытным разработчиком, но хорошо умеет планировать производственные циклы, когда в команде есть тренер. Что это вообще значит? Как может кто-то, не имеющий навыков развития, управлять высокотехнологичной командой? Возможно, управление здесь означает что-то еще?

Я рассматриваю управление как пустую трату времени и побочный продукт незрелости. В моем понимании зрелая команда полностью самоуправляема. Очевидно, я ошибаюсь, так как многие великие люди говорят обратное, но я не могу убедить себя.

Вы делаете много ошибок здесь.

Первый предполагает, что Scrum Master является менеджером. Они не. Они в основном администратор и помощник. Они следят за тем, чтобы все происходило в расписании Scrum, но им не нужно рассказывать, как это делать, если вы зрелая Agile-команда. В основном это просто происходит.

Но они не следят за качеством вашей работы, не отмечают ваш отпуск или что-то в этом роде. Они также не управляют продуктом или проектом; это делают другие люди.

Большая ошибка, которую вы совершаете, заключается в том, что вы можете выйти из ситуации, описанной вами в других вопросах («Разработчики далеки от того, чтобы на данный момент выполнять гибкие методы программирования. Никаких модульных тестов, парных программ, CI ( а? что это?) ... вы поняли. ")" полностью зрелой Agile команде "в одночасье. Это просто невозможно. Забудь это. Даже не пытайся.

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

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

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

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

В моем понимании зрелая команда полностью самоуправляема.

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

Возникает проблема, что даже самоуправляемая команда в конечном итоге обретает человека с хорошими социальными и политическими навыками, который может представлять команду в других отделах. Кто-то, кто следит за тем, что делают все, когда уходит в отпуск и т. Д. Кто-то, кто занимается ерундой и бюджетированием. Кто-то, кто спорит с группами QA и PM, так что остальная часть команды не должна. Кто-то, кто является посредником неизбежных межличностных ссор между разработчиками. Кто-то, чтобы запланировать встречи и поддерживать моральный дух.

Этот человек менеджер.

• Вы приходите домой один день, и вы платите чек не ...
• Вы хотите взять отпуск, но команда слишком занята и была в течение года ...
• Ваша жена или ребенок больны и нуждаются в сокращении до 20 часов в неделю в
  течение 6 месяцев.
• Финансовый отдел призвал к сокращению бюджета, и кто-то должен идти.
• Кофемашина сломалась, и никто не может починить ее.
• Ваша команда настолько хороша, что не нужно исправлять дефекты и добавлять какие-либо функции, у вас закончилась работа - что теперь делать.
• Заказчик не будет платить за проделанную работу
• Клиент хочет сделать больше работы, чем вы можете достичь, и готов заплатить за это.

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

Хватит мешать менеджерам - узнайте, что у вас есть набор навыков, а у них другой набор. Все эти навыки необходимы в любой организации. Вы будете выполнять их работу так же хорошо, как они будут выполнять вашу. Редко иметь кого-то хорошего в обеих работах, реже иметь кого-то хорошего в обоих, которые могут делать оба одновременно. То, что происходит без ясли, - это то, что вещи постепенно разрушаются до состояния дисфункции. Если вам повезло, его признают достаточно рано, менеджер нанят, и внезапно проблемы исчезают, как по волшебству, и вам остается заняться работой, за которую вам платят, вместо того, чтобы играть в глупую офисную политику (выступая от опыт здесь).

Я рассматриваю управление как пустую трату времени и побочный продукт незрелости.

Вау. Вы не работали с хорошими менеджерами в последнее время, не так ли? (Мы все работали с плохими).

Я видел, как люди иногда делают ошибку, полагая, что все, что они не понимают, легко.

(Деловые люди особенно виноваты в этом - вы когда-нибудь получали спецификации низкого качества И крайний срок, установленный в камне?)

В большинстве предприятий команда разработчиков существует как часть большего целого. Менеджеры существуют как интерфейс между командой и остальной частью компании. Хороший менеджер будет работать в этих отношениях в обоих направлениях, обеспечивая, чтобы команда получала то, что им нужно (требования, офисные помещения, новые компьютеры, распознавание, бонусы и т. Д.), А также сообщая (постоянно меняющиеся) приоритеты, которые выходят из углового офиса ,

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

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

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

Удачи с этим.

PS - читайте. Не называйте себя программистом - отличный совет, и лучше, чем я, объясняет, как нас воспринимает остальной мир бизнеса.

Работа мастера схватки или менеджера в целом не должна действовать как диктаторский повелитель. Задача менеджера - убедиться, что его команда настроена на успех в бизнесе. Это включает в себя наем нужных людей, приобретение правильного оборудования и стратегический взгляд на продукт. Менеджер должен быть как линейный судья, сохраняя детали и мелочи, которые не важны для успеха команды от вмешательства в их прогресс.

Частично проблема заключается в том, что «Scrum Master», возможно, является наименее точно названной ролью за всю историю. «Scrum Facilitator» был бы немного более точным, но, как кто-то другой ранее указывал, работа SM заключается не в том, чтобы управлять командой, а в том, чтобы устранять проблемы, чтобы (самоуправляющаяся) команда могла продолжить свою работу. Да, мастер схватки также отвечает за обеспечение того, чтобы произошла схватка: задачи обновляются за оставшиеся часы, резервы удерживаются и увеличивают ценность, обновляются выгорания, отслеживается скорость и т. Д., Но это все еще тренировка и облегчающая роль, а не управляющая роль.

Другая часть проблемы заключается в том, что сотрудники в угловых офисах хотят знать ответы на такие вопросы, как «когда я могу отправить программное обеспечение?» и "какие функции он будет содержать?" и они привыкли задавать «Менеджеру проектов» эти вопросы и получать ответы, подкрепленные множеством впечатляющих диаграмм Ганта и практически без упоминания о таких неудобных вещах, как конус неопределенности.

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

Если вы считаете, что управление не требуется, кто будет выполнять следующие организационные работы, кто будет реагировать в следующих ситуациях?

• новые клиенты должны быть найдены. Как вы продаете свою продукцию? Как вы рекламируете?
• материалы должны быть куплены, поставщики должны быть найдены
• необходимо вести дипломатические переговоры с другими компаниями, банками или государственным учреждением

Я в небольшой команде без менеджера, и это работает. Почему? Я, честно говоря, не знаю.

Мое лучшее предположение, что все сводится к тому типу людей, которым вы являетесь. Некоторые люди "являются" компьютерами, поэтому их нужно кормить процессом. Другие люди являются «программистами» и имеют возможность создавать свой собственный мир и структуру из ничего.

Я должен создать систему или быть порабощенным другим человеком; Я не буду рассуждать и сравнивать: мое дело создавать. - Уильям Блейк

РЕДАКТИРОВАТЬ в ответ на комментарий Гленатрона:
это больше, чем просто команда разработчиков. У нас есть генеральный директор, администратор, который отвечает на телефонные звонки, и ИТ-парень. Мы общаемся с клиентами напрямую по электронной почте, телефону или встречам. Наш основной бизнес - создание собственного продукта и его продажа, а не поиск контрактов. Но есть и контракты.

Я больше думал об этом, и вот почему я думаю, что это работает:
1. Мы в первую очередь создаем свой собственный продукт, а не создаем чужой.
2. У нас есть последовательная рабочая этика независимо друг от друга без надзора.
3. У нас есть предметные знания.
4. Удачи. Горстка людей, которые ладят и хорошо работают вместе.

Кто-то упомянул, что у компании Valve нет менеджмента. Valve создает собственный продукт, а не создает чужой. Я думаю, что компания-производитель лучше поддается самоуправлению. Нет риска пойти по другому пути, чем ожидает клиент, потому что вы - клиент. В игровой компании это особенно верно. Сделайте свою игру веселой.

Вы не можете управлять своим весельем. Вы не можете управлять своим путем к оригинальному творчеству.