Продолжаем)

Часть 3 - Как поживают ваши инженерные практики? 

1. Есть ли в вашей системе для разработки кнопка "нажми, чтобы проверить", с помощью которой каждый из вашей или другой команды мог ы просто обнаружить допущенные ошибки регресса (сломанную функциональность, работавшую до изменений)? Обычно это достигается с помощью xUnit (jUnit, nUnit и т.д.).
2. Существует ли оптимальный баланс между автоматическим системным полным тестированием (функциональным тестированием) и автоматическим юнит тестированием? 
3. Использует ли команда при системном и юнит тестировании язык совпадающий я языком разработки? Совместная работа не становится лучше от использования проприетарных скриптовых языков или инструментов записи действий, которыми только часть команды умеет пользоваться. 
4. Затрагивает ли команда "серую зону" между системным тестированием и юнит тестированием? 
5. Существует ли на сервере непрерывной интеграции автоматическое уведомление в случае появления ошибки регресса? Может ли скорость появления такого уведомления быть снижена до часов или минут? ("Ежедневные билды для слабаков" Kent Beck)
6. Входят ли все тесты в результат работы сервера непрерывной интеграции? 
7. Поняли ли члены команды всю прелесть непрерывного дизайна и постоянного рефакторинга, как альтернативу Большого дизайна до разработки? Рефакторинг имеет четкое определение: изменение внутренней структуры системы без изменения внешнего поведения. Рефакторинг должен случаться несколько раз в час, где бы ни было - дублирование кода, сложная условная логика (видная по избыточным отступам и длинным методам), плохое именование идентификаторов, избыточная связь между объектами и т.п. Выполнять рефакторинг с уверенностью возможно только при покрытии автоматическими тестами. Пренебрежение рефакторингом делает сложным изменение продукта в будущем, особенно с тех пор, как стало тяжело найти хорошего разработчика, готового работать с плохим кодом.
8. Включают ли ваши критерии выполнения задачи для каждого функционального задания из бэклога полное автоматизированное покрытие тестами и рефакторинг? Изучение методов разработки через тестирование (TDD) увеличит возможность достижения такой задачи.
9. Применяется ли парное программирование при большинстве разработок? Парное программирование радикально повышает уровень пригодности кода к сопровождению и уменьшает количество багов. Но этот метод сталкивается с проблемой взаимодействия людей и иногда занимает большее время (если вы измеряете производительность в строчках кода, чаще чем в рабочей функциональности). Введите для примера дни парного программирования. И наверняка некоторые разработчики предпочтут работать таким образом.

Часть 4 - Как дела в вашей организации?  

1. Достаточное ли количество меж группового взаимодействия в вашей организации? Скрам скрама (Scrum of Scrum) единственный путь добиться такого взаимодействия и не обязательно самый лучший. 
2. Могут ли ваши команды независимо друг от друга реализовать работающую функциональность даже при пересечении архитектурных границ? 
3. Встречаются ли ваши скрам мастера друг с другом, для устранения возможных препятствий на уровне организации? 
4. При необходимости передаются ли организационные проблемы в офис директора по разработке? Может ли быть определена цена в долларах потерь от позднего выхода на рынок, потерь от падения качества, потерь клиентов от нереализованных возможностей? (Но учитесь на ошибках Ken Schwaber "Мертвый скрам мастер бесполезный скрам мастер") 
5. Относится ли ваша организация к тем редким организациям, где карьерный путь совпадает с общими целями ваших команд? Отвечайте "нет", если в вашей организации в карьерном смысле выгоднее заниматься разработкой или архитектурой, чем тестированием, автоматизацией или документированием. 
6. Признавала ли отраслевая пресса или другие независимые источники вашу организацию, как одну из лучших организаций для работы или лидером в вашей индустрии? 
7. Создаете ли вы из вашей организации "обучающуюся организацию"? 

Заключение 

Если вы сможете ответить на большинство этих пунктов, и у вас еще останется время до конца дня, дайте мне знать))) 

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

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