#9 Pierwsze kroki w nowym zespole

Cześć, jestem Magda. A ja Piotrek. W dzisiejszym odcinku będziemy rozmawiać, co robi Scrum Master w nowym zespole, o czterech obszarach do zaobserwowania oraz na koniec opowiemy parę narzędzi, które pomagają w tym procesie. Zapraszamy. Dzisiaj chciałabym porozmawiać, co robi Scrum Master w nowym zespole, jak zabrać się do rozwoju zespołu. Dostaję wiele pytań od nowych Scrum Masterów, od świeżych Scrum Masterów.

No dobra, dostałam tą pracę, ale co dalej? Jak mam się za to zabrać? Co powinnam zrobić? Więc też Grzesiek mówił w którymś podcaście, że Scrum Guide mówi co mamy osiągnąć, jak powinno być, ale nie mówi nic o tym jak to zrobić. Więc dzisiaj chcielibyśmy przybliżyć trochę W tym odcinku opowiem wam o tym, co się dzieje z kroki w nowym zespole.

Wielkie dzięki i do zobaczenia! Tak, ja postaram się rzucić swoje światło, swoje spojrzenie na aspekt wchodzenia Scrum Mastera do nowego zespołu, bez względu na to, czy jest on nowym Scrum Masterem, czy też doświadczonym Scrum Masterem. Wiadomo, że naturalnie łatwiej mi patrzeć przez pryzmat własnych okularów i tego, że Scrum Master jest już doświadczony. Jaki jest pierwszy obszar, który wyselekcjonowałaś? To na początek zespół, ludzie, z którymi będziemy współpracować, deweloperzy, jakie są relacje wewnątrz zespołu, jak oni lubią współpracować, czy zespół jest dojrzały, czy dopiero się utworzył, też kto ma w zespole największy autorytet, kto mógłby być naszym agentem zmiany lub kompanem w zmianach, żeby współpracować razem.

To wszystko są pierwsze kroki, pierwsze obserwacje, na które bym zwrócił uwagę. Czy są też jakieś konflikty może? Zdarza się chociaż. Zdarza się. Myślę, że możemy płynnie przejść do drugiego obszaru, jakim jest product owner, produkt, domena, w jakiej pracuje zespół. Co wytwarza zespół? Jaki produkt, jakie potrzeby użytkownika adresuje ten produkt? Piotr, czy coś byś jeszcze dodał tutaj? Scrum Master jako drugi z obszarów, z którym powinien pracować, to jest ta praca z Product Ownerem, natomiast co się pod tym kryje, to ja to rozumiem w ten sposób, że należy zrozumieć, nie tyle tutaj po ludzku, oczywiście to też kim jest Product Owner,

Ale jak jego rola jest osadzona w danej organizacji? Czy tak naprawdę właśnie jest on takim Product Ownerem zgodnym ze Scrumem, tak jakbyśmy chcieli? Czy ma wizję produktu? Czy jest osobą decyzyjną? Czy tak naprawdę jest właścicielem budżetu? Dlaczego o tym budżecie wspominam? No bo jeżeli mówimy w ogóle o produkcie, no to powinniśmy zrozumieć, Co to jest za produkt? Co ten zespół wytwarza? Jakie są przepływy pieniężne w tym produkcie? Czyli tak naprawdę jaką wartość buduje ten produkt? Kto z tego korzysta? Jak na tym zarabia? I na jakiej podstawie podejmujemy decyzję? Co powinno być priorytetem? No bo tak naprawdę jest napisane, że Product Owner powinien maksymalizować wartość. No i często ludzie mają duży problem, co to jest ta wartość, którą powinni maksymalizować i sprowadzają to do tego, że ta maksymalizacja wartości to jest taka, jak jakiś stakeholder przyjdzie do zespołu i powie, że to jest najważniejsze.

Czy mają decyzyjność w swoim obszarze pracy? Czy może nie ma tego mindsetu Agile'owego, gdzie jest command and control, macie robić tak, a nie inaczej? I koniec. Dokładnie, trzecie z obszarów, które wymieniłaś, czyli jak się mówi, że Scrum Master powinien pracować z zespołem, z Product Ownerem i z organizacją, czyli mamy tutaj tą trzecią odnogę, pracę z organizacją. Ona jest uważam najtrudniejsza i jednocześnie najważniejsza. W związku z tym, że jest najważniejsza, to z jednej strony powinniśmy się na niej najbardziej skupiać, ale z drugiej strony, jeżeli jeszcze nie mamy doświadczenia, to jest to bardzo trudne.

Z dwóch powodów. Pierwsze takie, że skoro nie mamy doświadczenia, to jeszcze nie widzieliśmy wiele modeli organizacji, co działa dobrze, co działa źle, więc ciężko nam się do tego ustosunkować i sugerować zmiany, które będą tak szerokie, że dotkną całej organizacji. A z drugiej strony ta sama organizacja wie, że skoro jesteśmy niedoświadczonym Scrum Masterem, to prawdopodobnie nawet nie daje takiego umocowania, żeby takie zmiany sugerować. Natomiast wspomniałaś o tej kulturze organizacyjnej. Uważam, że kultura definiuje sposób pracy, a nie na odwrót. Czyli to nie jest tak, że my postanowimy, że teraz będziemy pracowali zwinnie na przykład w Scrumie i nagle kultura około nas w organizacji się dzięki temu zmieni. To działa dokładnie odwrotnie.

Ostatnia rzecz, którą jeszcze chciałem dodać do tej organizacji, bo też mi znowu przyszło do głowy, że po raz kolejny tutaj należy być bardzo ostrożnym i znowu nie być hipokrytą, czyli jeżeli zaobserwujemy na poziomie organizacji coś, co wydaje nam się, no nie, jak to tak może działać, to na pewno źle, w ogóle ja czytałem w artykułach i na szkoleniu, że to powinno być inaczej, I od razu będziemy mówili, że to wszystko nie działa i będziemy takim głosem destrukcyjnym bardziej, wytykającym błędy, a nie proponującym rozwiązania. No to należałoby się wcześniej zastanowić, no jednak ta organizacja odnosi prawdopodobnie jakiś sukces, skoro stwierdziła, że chce się rozwijać i zatrudniła na przykład nowego Scrum Mastera, no to skąd wzięła na to pieniądze i do czegoś doszła tym właśnie sposobem pracy, jaki dzisiaj jest.

I tutaj taka podpowiedź. Fajnie zrobić na przykład shadowing dewelopera, zapytać jak pracuje, z jakich narzędzi, zobaczyć go w akcji. W ten sposób można też nawiązać relacje z deweloperem, pokazać, że interesuje nas ich praca, że chcemy zrozumieć, a nie oceniać i mówić jak ma być zrobione. Tutaj trochę nawiązujemy do takiego odwiecznego pytania, czy Scrum Master powinien być techniczny, czy powinien być osobą techniczną. Mi jest łatwo mówić jako osobie technicznej, natomiast uważam, że w pewnym stopniu powinien przynajmniej jako minimum rozumieć język zespołu, rozumieć czym są te narzędzia, do czego służą, jakie zespół używa.

No bo bez tego to w ogóle będzie jak bez jednego oka, no to ciężko będzie zrozumieć w ogóle proces zespołu i o czym ci ludzie mówią, jakie mają problemy, co ich tak naprawdę boli, jeżeli nie wie się, jeżeli się po prostu nie rozumie języka. Natomiast jeżeli ktoś jest bardziej techniczny i rozumie ten proces na takim głębszym poziomie, rozumie te wszystkie narzędzia używane i wtedy jest w stanie sam zaobserwować jakieś blokery, jakieś pola do usprawnień i powiedziałbym, że to jest po prostu wartość dodana, czyli to jest coś, co już nie jest wymagane, ale jest korzyścią, więc jest to po prostu jeden z atutów, który Scrum Master może wyciągnąć i np. Zasugerować, jakie zmiany na podstawie swojego doświadczenia w procesach, nie wiem, code review czy w ogóle CICD.

Czyli podsumowując, nie znać wszystko od podszewki, dokładnie jak działa, ale zrozumieć te narzędzia i cykl wytwarzania. No pewnie. Nikt nie wie wszystkiego, to fikcja. Czy myślałeś o jeszcze jakichś obszarach do zbadania? Bo chciałabym przejść już do tych narzędzi, które mogą pomóc w układaniu planu na rozwój zespołu. No to przejdźmy do narzędzi. Dobra. Ostatnio na sobie odkryłam, jakim mocnym i ważnym narzędziem jest wizualizacja pracy. Dlatego też zachęcamy jako Scrum Masterzy, więc czemu nie korzystać z własnych wskazówek. Więc narzędzia polegające na wizualizacji naszych obserwacji tego, co mamy w głowie, naszych wniosków.

Chyba tak to się dokładnie nazywa. Po prostu łatwiej jest zobrazować lub sprawdzić, które obszary wymagają naszych działań. Też bardzo lubię listę pułapek z labiryntów Scrama, Jacka Wieczorka. Pozdrawiamy, jeśli można. To też pomaga zidentyfikować obszary, które trzeba poprawić. Na koniec jeszcze takie mierniki produktowe, no bo Scrum Mastery jest odpowiedzialny za efektywność zespołu, nie ile dostarcza, ale co dostarcza i jaką wartość, ale też właśnie te mierniki produktowe prawdopodobnie sami ich nie znajdziemy.

Na koniec polecam też Przenieść to do zespołu i skonfrontować nasze obserwacje, czy to, co my zauważamy, czy też jest problemem dla zespołu. Piotrek, co myślisz na temat tych narzędzi? Ja myślę, że wraz z doświadczeniem coraz bardziej się odchodzi właśnie od takich prostych narzędzi typu jakaś checklista Scrum Mastera, bo po prostu one przestają być potrzebne. Nawet dostrzegamy ich ograniczenia, że one zadają jakieś konkretne pytania i wpędzamy się w pułapkę odpowiedzi na jakieś pytanie, które po prostu może być w ogóle niedostosowane do realiów tego zespołu. Osobiście z takich narzędzi to ja korzystam tylko z dwóch.