I co Scrum na to? Nic! Choćbyś się prężył, wytężał, biadolił, nic! Ortodoksyjni Scrumiści powiedzą, to nie jest zgodne ze Scrumem. Powiedzą, że jeśli macie problemy to z tego powodu - że Scrum nie jest wprowadzony w całości.
Ale wprowadzenie praktyk Scrumowych jest trudne, o czym możecie przeczytać w artykule Michała. Natomiast czy ortoksyjni Scrumiści mają rację? Czy sam fakt, że nie wszystko zostało wdrożone zgodnie z zasadami Scrum, powoduje, że się on nie powiedzie? Otóż, temu chcę zaprzeczyć.
Dawno, dawno temu, kiedy poznawałem Test-Driven Development, usłyszałem takie zdanie (ciągle promowane przez Uncle Boba): "Nie wolno napisać ani jednego wiersza kodu, do którego nie istnieje test". Czy to prawda? Nie! Oczywiście, że wolno. Oczywiście, że wolno i powie to każdy wprawiony adept TDD, jednak, aby robić to z głową, potrzeba nielada doświadczenia i wyczucia.
I podobnie jest ze Scrumem. Być może nie dostaniesz stempelka "Scrum Certified", ale możesz to robić równie dobrze.
Główny problem wynika z tego, że w większości przypadków używając danego czy innego podejścia, skupiamy się na zasadach, na literze prawa, a nie na duchu... A wtedy mamy dwa wyjścia: albo się całkowicie podporządkować literze, albo zacząć ją łamać, usprawiedliwiając swoje błędy.
Ortodoksyjni Scrumiści (Ci którzy wydają certyfikaty), zawsze będą mówić, że musisz działać wedle litery. Bo tylko wtedy mogą zagwarantować, że to zadziała. Jak robisz własne przeróbki, to tracisz gwarancje.
A co nam może stanąć na przeszkodzie?
Zatem mamy zielone światło co do przeróbek, jednak chciałbym Cię ostrzec. Przeróbki to duża odpowiedzialność, gdzie na przeszkodzie stoi nam nasz największy wróg, czyli my sami. A dokładniej chodzi o mechanizm racjonalizacji.Mam okazję prowadzić od czasu do czasu szkolenia i mam do czynienia z tym mechanizmem bardzo często. Pojawia się on między innymi w sytuacjach, kiedy mówimy o jakimś rozwiązaniu, narzędziu czy podejściu, które wymaga dużego wysiłku, żeby go wprowadzić w życie. Wtedy uczestnicy często szukają usprawiedliwień i uzasadnień, dlaczego tego nie można u nich zrobić, dlaczego się nie da. Najczęściej oznacza to, że:
- po prostu potrzeba sporo czasu, żeby to zaczęło działać,
- jest to trudne do wykonania (trzeba negocjować z wieloma osobami, jest ryzyko, że dostaniemy po głowie),
- już kiedyś próbowaliśmy i się nie udało, jednak prawdopodobnie dlatego, że nie wiedzieliśmy, jak to zrobić.
- może mi po prostu brakuje odwagi, żeby to zrobić?
- może musiałbym być asertywny wobec szefa i nie wiem jak zareaguje, albo obawiam się, że źle zareaguje?
- może obawiam się, że dostanę po tyłku, jak zaproponuję inne rozwiązanie?
- gość zawsze wrzeszczy, więc pewnie będzie wrzeszczał tym razem!
- a jak mnie wywali z roboty?
Co jest potrzebne?
Załóżmy jednak, że jesteś przekonany i obiektywnie pewny, że trzeba jednak coś zmienić w zasadach. Kluczem jest to, żeby zrozumieć, jaki duch stoi za zasadami zapisanymi w Scrum Guide (czy jakimkolwiek innym podejściu typu TDD, BDD, DDD, Kanban etc.) A to nie jest łatwe, bo nie zawsze jest to wprost wypowiedziane przez twórców metody. Często wręcz sami twórcy nie do końca wiedzą, dlaczego to jest potrzebne, mimo że intuicyjnie są przekonani, że tak musi być. A później community przez wiele lat próbuje nadać temu sens.Dlatego pokrótce chciałbym przyjrzeć się owym Scrumowym zasadom. Temat ten będzie rozproszony na kilka postów. Dzisiaj zaczniemy od Product Ownera.
Product Owner
To chyba najbardziej newralgiczna część implementacji Scrum. Bardzo rzadko udaje się spełnić oczekiwania postawione przez metodę. Scrum mówi o roli, która jest związana z biznesem. Kogoś kto odpowiada za projekt od strony biznesu/klienta i podejmuje decyzje z tego punktu widzenia. Dla mnie główne przesłanie tej roli jest następujące:W KAŻDYM PROJEKCIE PROGRAMISTYCZNYM, JEŚLI MA ON MIEĆ SZANSE POWODZENIA, MUSZĄ BYĆ DOBRZE USTAWIONE RELACJE Z BIZNESEM.
Co to konkretnie oznacza:
- jest jeden punkt odnośnie decyzji biznesowych - jest jedna osoba (lub jeden byt), który podejmuje decyzje odnośnie dalszych losów projektu oraz wymagań). Często praktycznym problemem jest to, że wymagania przychodzą z wielu źródeł (np. różne departamenty w firmie, różne osoby) i to zespół musi sobie z tym radzić. To nie jest dobre. Zespół nie ma w większości odpowiedniej perspektywy biznesowej, żeby takie decyzje podejmować. Ale może podpowiadać, sugerować lub namawiać i to jest ok.
- biznes jest dostępny na konkretnych zasadach - ideałem Agile jest tzw. customer on-site, który pracuje bezpośrednio z zespołem, co jest rzadko wykonalne (choć warto o to walczyć do upadłego). Ważne jest, żeby ustalić konkretne zasady współpracy up-front. Te zasady powinny dotyczyć takich tematów:
- kiedy zespół może się komunikować z osobą decyzyjną,
- z jakimi sprawami,
- jakiego zaangażowania ze strony tej osoby potrzebuje zespół,
- jak będą rozstrzygane sytuacje sporne,
- jak będą rozwiązywane problemy
- jak będziemy uwzględniać zmiany
- w jaki sposób wymieniamy się informacją zwrotną (tu Scrum proponuje gotowce w formie Scrum meetingów oraz Sprint Review oraz Sprint Retrospective).
Kluczowe jest to, że określić dlaczego dla obu stron te zasady są ważne.
Zatem czy mamy kogoś kto nazywa się Product Ownerem czy nie, nie ma znaczenia. Jeśli jesteśmy w stanie ustawić odpowiednio relacje z biznesem, to jesteśmy w domu. Jeśli nie, żadna metoda nam nie pomoże.
To na początek. Reszta w kolejnych postach.
0 komentarze:
Prześlij komentarz