Czy sprinty Scrumowe działają w najszybszym możliwym tempie?

Niedawno przeprowadziłem wywiad z niektórymi firmami, które używają Agile, a dokładniej Scrum, a są pewne rzeczy, które nie do końca wydają mi się Agile. Wezmę teraz jeden przypadek, który szczególnie mnie interesuje, dotyczący sprintu Scrum.

Jeden konkretny kierownik projektu, z którym rozmawiałem (tak, powiedziałem kierownik projektu) z dumą stwierdził, że ludzie w jej zespole rozumieją („powiedziano mi”, to, co wybrałem z kontekstu), że nie wracasz do domu po upływie godzin pracy , wracasz do domu po zakończeniu pracy, bez względu na to, ile to zajmie. Przeczytałem między wierszami, że w sprincie pakujemy jak najwięcej funkcji i pracujemy w nadgodzinach, aby tak się stało.

Teraz do tej pory nie robiłem Agile (współpracowałem z instytucjami finansowymi i rządowymi, które nadal preferują wodospad), ale rozumiem, że:

• sprint w Scrum to nazwa ogólnej iteracji w Agile;
• zespół powinien pracować w zrównoważonym tempie i starać się unikać długoterminowych nadgodzin, ponieważ ma to wpływ tylko na krótki czas, a efekty są przyćmione przez problemy, które napotykają przez długi czas.

Czy moje wypowiedzi są prawidłowe? I czy powinienem traktować prezentację kierownika jako czerwoną flagę?

Nie musisz szukać daleko, aby zobaczyć, że praktyki te są sprzeczne z zasadami Agile. Jedna z zasad Manifestu Zwinnego mówi:

Zwinne procesy promują zrównoważony rozwój. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymywania stałego tempa w nieskończoność.

Kilka lat temu Scrum dokonał subtelnej, ale ważnej zmiany . Zamiast zespołów zaangażowanych w pracę, którą można wykonać, prognozują, co według nich można zrobić.

Zmiana następuje z powodu nadużyć, które brzmią bardzo podobnie do opisywanej przez ciebie postawy „nie wracaj do domu, aż do końca”. W fazie rozwoju zespołów jest wiele czynników, na które zespoły nie mogą się zgodzić - aby użyć analogii pogody, nie można „potwierdzić”, że jutro będzie padać.

Aby bezpośrednio odpowiedzieć na pytania:

• tak, Sprint to nazwa iteracji w Scrumie. Zobacz tę odpowiedź dla różnicy
• tak, zespoły powinny pracować w zrównoważonym tempie. Pewność tylko nadgodzin jest to, że będzie zmniejszenie produktywności zespołów długoterminowej.
• tak, to czerwona flaga!

Tak, masz rację, a gdybym usłyszał, co ci mówiono, uciekłbym stamtąd tak szybko, jak to możliwe. Po prostu używają zwinności jako wymówki. Brzmi jak klasyczny marsz śmierci.

Jest jedna kluczowa rzecz, która może uczynić to akceptowalnym: zespół akceptuje zakres sprintu.

W Scrum zespoły nie tylko otrzymują przydzieloną pracę. Właściciel produktu negocjuje z zespołem w celu ustalenia priorytetów pracy produktu i pracy technicznej (dłużnej). Kierownik projektu, właściciel produktu i zespół negocjują następnie, co zostanie wciągnięte w sprint i jaki jest zakres tej pracy.

W tym świecie zespół zasadniczo mówi „możemy wykonać pracę X, przetestować i wysłać tę iterację”. Oczekiwałbym więc, że zespół od czasu do czasu będzie pracował w nadgodzinach, aby wypełnić te zobowiązania.

To powiedziawszy, tak wiele miejsc drań zwinnie - i tak mało kierowników zespołów może skutecznie negocjować z ludźmi, którzy zwykle są ich szefami ... Uznałbym to za wielką czerwoną flagę.

Scrum jest rozbity na sprinty, w których oceniasz zestaw zadań do wykonania w czasie tego sprintu (zwykle 2 tygodnie, ale widziałem gdzieś od 1 dnia do 4 tygodni). Myślę, że to stwarza zachętę do niedoszacowania zadań. OP (właściciel produktu) będą chcieli, aby niskie szacunki wiązały się z dużym zaangażowaniem na sprint. Zespół dokona dużych szacunków, aby wygenerować ładne wykresy wypalenia dla PM. Są to oczywiście oznaki kiepskiej organizacji. Naprawdę chcesz uzyskać dokładne prognozy i nie obawiać się, że nie uda ci się zabraknąć i przenieść opowieści do następnego sprintu lub zakończyć wcześnie i usunąć dodatkowe zadania z zaległości. Myślę, że termin „sprint” tworzy obraz osób pracujących szybciej.

Nie: sprinty Scrum to timebox, nic więcej, nic więcej. Na początku sprintu / iteracji zespół podaje szacunkową liczbę punktów historii, które według nich mogą osiągnąć, w oparciu o takie rzeczy, jak poprzednia wydajność, dostępność, nadchodzące wydarzenia, otwarte przeszkody itp. Następnie negocjują z właścicielem produktu o tym, które historie użytkowników zostaną wprowadzone do sprintu. To jest (lub było? Patrz inna odpowiedź) zobowiązanie, które zespół daje właścicielowi produktu.

Jeśli podczas programowania okaże się, że rzeczy nie są tak, jak się spodziewano (w końcu chodzi o rozwój oprogramowania) i istnieje ryzyko, że zespół nie spełni zobowiązania, informują właściciela produktu, że istnieje ryzyko, że jedna lub więcej historii nie do ukończenia.

I w porządku. Jasne, to źle się czuje, gdy muszę przyznać, że pod koniec sprintu się nie udało, ale to nie porażka, to szansa na poprawę. Ponieważ pod koniec sprintu / początku nowego można zrobić retrospekcję sprintu, a pierwszą rzeczą, którą ktoś zapyta, jest: „Dlaczego nie udało nam się tego sprintu i co musimy zrobić, aby go nie powtórzyć ? ” Jedną z opcji byłoby oddanie mniejszego zaangażowania (= zajęcie mniej punktów fabularnych).

tl; dr: Sustainable Pace. W Scrumie chodzi o kadencję, coś, co zespół może nadążać w nieskończoność na zasadzie sprintu do sprintu. Praca w godzinach nadliczbowych nie jest; zespół zostanie przepracowany, praca stanie się niechlujna, członkowie będą wzywać chorych lub całkowicie rezygnować, a wtedy masz o wiele większy problem niż nieudany sprint.

Zwinne procesy promują zrównoważony rozwój. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymywania stałego tempa w nieskończoność.

Z Manifestu Agile

Praca w nadgodzinach przez cały czas nie wydaje mi się zrównoważona.

To powiedziawszy, nie widzę problemu z tym, że wiosenne zobowiązanie jest silne (jeśli tak chce zespół), a konieczność pracy w godzinach nadliczbowych, gdy przesadzasz lub przekręcasz szacunki, jest dobrą zachętą do lepszego szacowania lub komunikowania się oczekiwania wobec PO.

Jeden konkretny kierownik projektu, z którym rozmawiałem (tak, powiedziałem kierownik projektu) z dumą stwierdził, że ludzie w jej zespole rozumieją („powiedziano mi”, to, co wybrałem z kontekstu), że nie wracasz do domu po upływie godzin pracy , wracasz do domu po zakończeniu pracy, bez względu na to, ile to zajmie. Przeczytałem między wierszami, że w sprincie pakujemy jak najwięcej funkcji i pracujemy w nadgodzinach, aby tak się stało.

To nie jest Scrum. Proponowane obciążenie pracą timeboxu opiera się na szybkości zespołu , a nie na liście życzeń menedżera. Oni po prostu próbują oszukać cię, abyś uwierzył, że niekończąca się praca w nadgodzinach jest „zwinna”, a tak nie jest. Zespół stanie się bardziej wydajny, pracując bez zakłóceń i skupienia, ale Scrum nie jest magiczną różdżką zapewniającą niekończące się przyrosty wydajności.

Albo menedżer ma niewielkie nieporozumienie z Agile, albo (co bardziej prawdopodobne) uważa, że ​​programiści są tacy głupi. Z drugiej strony, kiedy zespół raz po raz akceptuje sprint, wiedząc, że będą musieli wykonywać pracę w godzinach nadliczbowych, może rzeczywiście są głupi i nie zasługują na to lepiej?

Chyba znasz odpowiedź ... ;-)