Итак, что нужно сделать первым делом, а чего делать не следует?
Для начала было бы неплохо понять цели руководства, выслушать их проблемы. Возможно их проблемы и не являются проблемами, а цели не решают задач бизнеса. Например, сейчас все хотят скрам, но не у всех получается. И тут возникает вопрос: а нужен ли вообще данной компании на текущем уровне развития скрам? Возможно ещё рано и он будет только мешать, разработчики будут беситься и становиться менее производительными. Особенно если команда разработки небольшая. Возможно более лучшим и удобным решением будет канбан.
Вы всё делаете не правильно!
Не нужно говорить что-то в стиле «Вы всё делаете неправильно, сейчас я вам покажу как правильно». А с чего ты взял, что они до тебя не пытались делать «правильно», но это не зашло и эволюционным методам команда выработала методики идеально подходящие именно этой команде для решения именно этих задач. В лучшем случае команда заново пробежится по всем граблям и придёт к тому же удобному для неё способу ведения разработки. А в худшем случае — есть риск потерять команду. Что не может являться целью компании.
Процессы стоит модифицировать постепенно и научным методом. Например, перед тем как что-то поменять, нужно сформулировать гипотезу: меняем то-то, ожидаем получить то-то. Затем внедряем изменение и наблюдаем. Если цель достигнута, значит ты красавчик, а если нет, то нужно отменить изменение, потому что не зашло. Не нужно быть мазохистом и пытаться сохранить не работающие изменения не приносящие профита.
Ведите дневник
Ведите дневник событий, которые происходят в компании. Кто-то накосячил? Отлично, запишите это в свой дневник. Кто-то странно себя повёл — запишите. Случилось что-то хорошее — запишите. Улучшили производительности системы — сохраните данные до и после. Но старайтесь никому его не показывать. Потом будет интересно почитать свои записи и сделать выводы. Ни в кое случае нельзя делать публичную «доску позора» и выставлять на всеобщее обозрение косяков сотрудников компании. Им это очень не понравится, они могут уйти.
Команды и люди
Нужно присмотреться к людям, пообщаться с каждым те-а-тет, выслушать их проблемы и потребности. Выяснить кто хорош, а кто плох. Все ли на своём месте и занимаются своим делом. Кого нужно удержать, кого уволить, а кого прокачивать. Опять же если уже есть сформированная команда.Желательно максимально быстро выбрать кандидата (кандидатов) кто мог бы занять твоё место в случае твоего повышения и сразу начинать его растить.
Дейли митинги и скрам стенд-апы
Очень мало кто умеет проводить ежедневные 15-ти минутные митинги, совещания, планёрки. Чаще всего сотрудникам это не интересно, они скучают, пропускают мимо ушей или смотрят мемасики в сматрфоне. Проводите такие митинги только тогда, когда кому-то есть что сказать и есть те, кому важно это услышать. В противном случае это пустая трата времени. 4 человека ежедневно тратящие 15 минут на минтинг еженедельно сжигают по 5 трудо-часов компании, а за месяц набегает уже 20 часов потраченного времени.
Управление ожиданиями
Ясно высказывайте и фиксируйте коллегам свои ожидания, а также просите коллег делать то же самое по отношению к вам. Самое неприятное происходит как раз тогда, когда кто-то не соответствует чьим-то невысказанным ожиданиям. Если ожидание не высказано, то оно не должно ни на что влиять.
Документация
Нужно проверить документацию, насколько она актуальна, покрывает ли все процессы и компоненты системы. Назначить ответственных за её написание. Может ли посторонний человек разобраться в продукте по этой документации? Используется ли документация сотрудниками других отделов?
Вряд ли в компании каждый сотрудник знает о системе всё и в случае ухода одного из сотрудников есть шанс навсегда потерять часть знаний о системе, поэтому все данные должны быть сохранены в текстовом и графическом виде и быть в свободном доступе для сотрудников компании. Чем больше сотрудник знает и понимает в происходящем, тем более он замотивирован делать лучший продукт.
Если отдел разработки небольшой
Опять же повторюсь ,если команда или отдел разработки имеют малое количество сотрудников, 5 и меньше, то возможно нет смысла внедрять скрам, будет слишком много накладных расходов. Также остро стоит вопрос о документации системы, при уходе из компании одного человека велик шанс потерять значительную часть знаний!