Как представить Agile команде, которая использует жесткие не Agile методы?

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

Как вы продолжаете вводить Kanban или Scrum постепенно, не нарушая всю их систему, и при этом уверяя их в том, что она все еще может быть такой же подотчетной / проверяемой ?

Я знаю, что это, возможно, связано с « Как бы вы внедрили гибкую методологию, такую ​​как Scrum », но здесь я задаюсь вопросом о том, как обойти / обойти тот факт, что компания навязывает определенный способ управления SDLC под ложным предлогом, что это единственный способ иметь контрольный журнал.

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

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

Одна полезная практика, которой мы следуем, - это « Документ достаточно, но постоянно» . Это, очевидно, означает, что мы не следуем всем шаблонам, предписанным для проекта, но существует осознанное понимание и согласие относительно того, какие разделы / документы необходимы сравнению с теми, которые являются просто бессмысленными накладными расходами.

Затем вам нужно обобществить эту точку зрения и получить одобрение группы качества или отдела стандартов или как там это называется.

Agile принцип - это «достаточно» документации. Можете ли вы попытаться подтолкнуть его от Заказчика, чтобы выразить команде, сколько достаточно? Менеджер проекта может поговорить с заказчиком и понять его ожидания и организационные потребности, а затем и документально подтвердить решение и оправдать эти ожидания. Если это достаточно хорошо для них (то есть платящих клиентов), то это может быть то, что вы следуете.

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

В крупных организациях контроль и надзор за крупными программами осуществляются с помощью офисов мониторинга проектов (PMO), которые проводят традиционное планирование для калькуляции затрат / учета / управления ресурсами и т. Д. - следовательно, им требуется много документации, но они могут отслеживать прогресс, используя Agile-методы (таблица выгорания SCRUM для одного). Им нужно знать, как такие методы, как непрерывная интеграция, помогают им раньше, а не позже, и, следовательно, для продуктивности каждого лучше избавиться от накладных расходов.

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

Сначала я бы отделил Скрам от Канбана.

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

Скрам принципиально отличается в том смысле, что это то, что вытеснит существующий процесс.

Команде, которая привыкла к 12-месячным (или более длительным) циклам водопада SDLC, будет очень трудно перейти на Scrum. Постепенное сокращение цикла до 6- или 3-месячного выпуска поездов с меньшим объемом может быть полезным промежуточным этапом.

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

• Спросите себя, почему вы хотите использовать Scrum . Вам нужно решить реальную проблему?
• Убедитесь, что ВЫ привержены этому, потому что никто не сделает это за вас. Вы будете владельцем вещи. По крайней мере, пока это не принесет положительный эффект в организации
• Тренируйся . Книг и интернета мало. Сначала идите на курс, иначе вы резко увеличите свой шанс неправильно внедрить Scrum. Что, вероятно, приведет вашу команду к худшим результатам, чем раньше
• Сначала продай команду . Вы должны иметь их полную поддержку, очевидно,
• Не предлагайте изменения, предложите тест . И подумай об этом. Scrum может не подходить для вашей организации (или для вашей команды)
• Найти спонсора в топ-менеджменте

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

То, как мы это сделали, заключалось в том, чтобы взять небольшую группу разработчиков (и аналитиков), чтобы создать пилотную команду SCRUM. Мы следовали строгой методологии SCRUM около 4 месяцев, после чего компания размышляла о том, что мы сделали, как мы это делали, проанализировала данные (вы знаете, все, что нужно сделать БА).

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

Я думаю, что пилот был ключевым. Это дает строгой стороне деловое время, чтобы оценить и увидеть, что это работает сначала.

Я - проворный тренер, и одним из ключей к изменению инициатив является участие на всех уровнях! Это включает руководителей, команды разработчиков, менеджеров и т. Д. Прежде чем объявить о больших или малых изменениях, я бы посоветовал сначала пригласить людей на борт. Делать это в разговоре от третьего лица - это самый простой способ для людей начать использовать новые идеи. Что такое третье лицо? Блог, видео на YouTube, презентация и т. Д. Таким образом, эти люди могут начать выдвигать свои собственные идеи и под вашим влиянием вступят в борьбу с инициативой перемен.

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

Канбан: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI