One Scrum Process Story (in Russian)
Алекс Атемасов и Макс Колодезный
Командная энтропия
«Энтропия — равномерность или одинаковость. Второй закон термодинамики менеджмента: Энтропия в организации постоянно увеличивается»
Том Демарко, Тимоти Листер, «Человеческий фактор»
То, что касается организации в целом, касается и команды, в частности. И каждого человека, в частности. Что же случилось в нашем случае? Без тени смущения, могу сказать, что наш Scrum-процесс был близок к идеальному. Проблемы, естесственно, были, но как они создавались – так довольно оперативно и решались. Прошли стадию, так называемой кристаллизации команды, сменили Scrum Master'a, попытались внедрить нового Scrum Member'a… Потом пришел успех и признание — проект раскручивался, PO не стеснялся светить и пиарить команду, более того, способствовал этому. Апогеем стало выступление с докладом на Agile Gathering 7. Пол года назад мы и мечтать о таком не могли. И тут команда, откровенно говоря, зазналась. Решили, что круче нас только вареные яйца и… Тут приходит забавный пушистый зверек и говорит: «My name is Fail. Epic Fail». На постсоветском пространстве это зверька называют чуть по-другому. Случился проваленный спринт. Причем, проваленный на все 100%. Ни одна User Story не была готова полностью. Почему так случилось? Вот пару моментов…
Представьте себе Таскборд в начале спринта. User Stories расставлены по приоритету сверху вниз, задачи в каждой Story расписаны в нужном порядке слева направо. И команда начинает работу. Как начинает изменяться Таскборд? Задачи первой Story плавно двигаются по стадиям в In Progress, QA, Review (нужное подчеркнуть) и находят свой покой в Done. Первая Story готова и можно спокойно приступать к следующей. Так проходится вторая, третья и сколько там вам нужно… Самая страшная картина, которая может возникнуть в конце спринта — часть фич готова полностью, одна в процессе и одна-несколько еще не начаты. При правильном планировании последних у вас не будет вовсе. В любом случае, есть готовый функционал, есть результат.
А теперь представьте такую картину: в начале итерации в работу берутся все Story одновременно. А что? Мы крутые перцы, мы все успеем — по Story в лицо и вперед. И понеслась… К середине спринта ни одна фича не готова полностью, все потихоньку двигаются по Таскборду. Тут бы кто-то (в первую очередь Scrum Master) должен проснуться и прекратить это безумие. Предвидеть провал заранее. В нашем случае такого человека в команде не нашлось. В результате на конец спринта все User Stories были выполнены на 80-95%, на демо через раз показывались баги, Velocity итерации равняется нулю.
Ко всему прочему, Product Owner был в абсолютном неведении того, что спринт катится к своему Epic Fail'y. Показанное на демо стало для него полной неожиданностью. Стоит ли говорить, что он был не очень этому рад… Команда, и Scrum Master в первую очередь, должны были заранее, желательно в середине спринта предположить такое развитие событий и сказать об этом РО. Если очевидно, что спринт не будет выполнен на 100% с текущими задачами, PO может подойти к Таскборду, глянуть и сказать: «Эта фича пока обойдется без пары задач, эта фича сейчас не настоль критична, можно ее вынести в Soft Commit, но вот без этих вещей итерацию закрывать нельзя». И команда может спокойно, без паники, делать свою работу, и PO вовремя скоректирует свои планы на следующий релиз.
Что приходит на помощь в данной ситуации если уж Fail случился?
Как показывает практика, самые хорошие и продуктивные ретроспективы проходят после самых неудачных спринтов. Жесткая ретроспектива—это не «раздача слонов» PO всей команде, не сваливание ответственности друг на друга внутри команды. Это четкий разбор пролетов, может быть даже в довольно жесткой форме. Без стеснений и боязни даже переходить на личности, команда доберется до сути своих проблем и повесить нужную бумажку в Implement. И будет реализовывать этот Implement!
New Fun от Scrum Master'a. SM не должен позволить скучать девелоперу. Новые вещи, новая мотивация, новые идеи. Меняйте инструменты работы, меняйте Scrum под себя… У нас постоянно были новые Scrum Tools. Beer-box, пилон, еще груша посреди офиса, «воздушные стрелялки», дизайнер рисует карикатуры и обложки к каждому демо, даже послеобеденные прогулки всей командой. Это мелочи и, может быть, не серьезно, но SM должен делать все, чтоб девелопер приходил на работу с удовольствием, а не с желанием побыстрее отсюда уйти.
И конечно же, лояльность PO. Гнев, крики и вопли, что «он Д’Артаньян, а вы все плохие» и «как вы вообще могли?»… Стимула, мотивации это никому не прибавит. Только нарушит микроклимат в команде и охладит ее отношение как к РО, так и к разрабатываемому продукту. В нашем случае, РО присутствовал на Ретроспективе, услышал все сказанное всеми членами команды, после вышел и сказал: «Мне особо нечего добавить, вы исправитесь – я в вас верю». После этого команда просто не могла сфейлить… И не сфейлила!
(По мотивам презентации «One Scrum Process Story» от 12.06.2010)