Water Scrum Fall – etap transformacji czy rzeczywistość, której nie da się przeskoczyć?

water scrum fall

Water Scrum Fall

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ść?

Jak sądzicie?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x