Trafiłem ostatnio na podsumowanie badań dotyczących Scruma, wykonanych przez ScrumAlliance. Podsumowanie jest z zeszłego roku. Chciałbym się nim z Wami podzielić, ponieważ myślę, że nie wszyscy mieli okazję zapoznać się z tym dokumentem.
Ogólnie obraz scruma rysuje się… No właśnie. Możemy uczestniczyć w szkoleniach, chodzić na spotkania grup lokalnych i wymieniać się doświadczeniami. I każdy tam coś powie, jak to fajnie funkcjonuje scrum w jego organizacji, jakie to super rzeczy robią. A jak to wygląda NAPRAWDĘ? Nie będę uprzedzał, co się w tym raporcie pojawia, aby trochę zachęcić Was do zapoznania się z nim. Dla mnie osobiście obraz ten nie był najprzyjemniejszy. Ale ocenę pozostawiam Wam, ponieważ z pewnością będzie ona subiektywna.
To co mnie najbardziej zainteresowało i na czym w niniejszym poście chciałbym się skupić, to Water Scrum Fall. Pojęcie to wprowadził Dave West, wysoko postawiony “zarządzający” w Forrester Research. Związek pomiędzy raportem ScrumAlliance, w którym przywołuje się to pojęcie, wprowadzonym pojęciem i tym, co napisałem powyżej, jest dość istotny. Tak jak wspomniałem, możemy sobie wyobrażać “piękny”, teoretyczny scrum, ale rzeczywistość sprowadza nas na ziemię. Tą rzeczywistością jest właśnie Water Scrum Fall, a dotyczy on stosowania wybranych praktyk scrumowych w starym, dobrze znanym świecie. Pojęcie to Dave dokładnie opisuje w raporcie Forrester dostępnym tu, ale nie sądzę, aby ktoś się pokusił o jego zakup :). Skrót możecie znaleźć tutaj i zachęcam do obejrzenia tej krótkiej prezentacji jako uzupełniania raportu o scrumie, albo nawet jako jej substytutu.
Najlepiej sama ideę oddaje slajd 11 (załączony rysunek), na którym dokładnie widać implementację scruma pośrodku starego procesu, na początku którego “ktoś” podejmuje decyzje o realizacji, a na końcu procesu, pomimo “użycia” metodyki zwinnej, potencjalne do wdrożenia oprogramowanie trafia w proces release management’u i czeka, czeka, jest testowane, czeka i może w końcu po kwartale trafia na produkcję. Dave przytacza również kilka symptomów takiego podejścia, z których najistotniejsze to moim zdaniem:
- każdy z członków zespołu projektowego pracuje nad więcej niż jednym projektem (multitasking/ context switching),
- plany determinują decyzję dot. projektu,
- programiści (developement) nie jest zaangażowany w proces zbierania / udoskonalania wymagań,
- nieregularne lub zbyt rzadkie wdrożenia.
Dave, poza wyżej wymienionymi, przytacza więcej symptomów, i opisuje dokładnie każdy z nich. Polecam.
Pogłębiając jeszcze bardziej temat, natkniecie się na artykuł, w którym możemy znaleźć dalsze odwołania, ale w którym to pojawia się także ciekawa typologia “ludzi od scruma”:
- the purists (puryści – interpretuję to pojęcie jako ludzi z “kościoła” scrumowego),
- the posers (pozerzy – udają, że są lepsi, niż w rzeczywistości są),
- the pragmatists (pragmatycy, znający ograniczenia i próbujący zrobić najlepsze, z tego co mają).
Aktualne wydaje mi się również pytanie, które pada na zakończenie ostatniego z wymienionych artykułów i które chciałbym, lekko zmodyfikowane, zadać Wam:
Czy praca / używanie Water-Scrum-Fall jest po prostu podejściem pragmatycznym, czy może też jest tylko jednym z etapów dojrzewania zespołów / organizacji przed “wejściem do kościoła scrumowego”? A jeżeli jest to tylko etap, to jakich środków trzeba użyć, aby do tego „kościoła” wejść?