Podczas współpracy z drugim człowiekiem dzielimy z nim zarówno sukcesy, jak i porażki. Daje to duże pole do wzajemnego wsparcia i zrozumienia. Takie podejście jest kluczowe, aby móc rozwijać w sobie jedną z pięciu wartości opisanych w Scrum Guide: szacunek. Warto pamiętać, że tylko relacje (niezależnie od ich charakteru) zbudowane na wzajemnym szacunku dają ludziom możliwość rozwoju i spełnienia. Jaka jest zatem definicja szacunku w Scrum teamie? W jaki sposób ta wartość przekłada się na relacje biznesowe?
Przeczytaj także: 5 Wartości Scrum. Czym są i jak je stosować w codziennej pracy?
5 wartości Scruma, czyli krótki przewodnik po frameworku Scrum
Scrum jest frameworkiem, który służy przede wszystkim optymalizacji i usprawnieniu pracy zespołowej. W Przewodniku po Scrumie możemy przeczytać, że przedstawione w nim wartości nadają priorytety i kierunek we wszelkiego rodzaju decyzjach, jakie są podejmowane w poszczególnych Sprintach i innych działaniach w czasie trwania projektu. Wspomniany dokument opisuje 5 głównych wartości Scrum, i są to:
Przewodnik bardzo jasno wyznacza role i cele wymienionym wyżej wartościom. Ich skuteczne wykorzystanie zależy od tego, czy każdy członek zespołu jest w stanie pracować w zgodzie z nimi. Taka adaptacja całego zespołu to filar, który pozwala urzeczywistniać Cel Sprintu.
Cecha wysoce efektywnego zespołu Agile
Znane przysłowie mówi, że „ryba psuje się od głowy”. W tym kontekście możemy uznać, że pełne szacunku środowisko pracy zaczyna się od przywódców. To oni odpowiadają za utrzymywanie dobrych relacji oraz pomoc w niwelowaniu napięć i konfliktów między członkami zespołu. Musimy pamiętać, że ludzie są różni i pomimo najszczerszych chęci tego typu sytuacje będą się zdarzać. Przy ich rozwiązaniu zbawienny okazuje się być szacunek.
Przeczytaj także: Rola Scrum Mastera w procesie wytwarzania oprogramowania
Scrum Master: rola kapitana statku?
Za budowanie i rozwijanie odpowiednich postaw w Zespole Scrumowym odpowiedzialny jest Scrum Master. Dając przykład poprzez swoje zachowanie, sposób, w jaki rozmawia z programistami, kształtuje środowisko, w którym Zespół Scrumowy będzie się rozwijał.
SM jest osobą, która powinna zauważyć pierwsze „pęknięcia w kadłubie statku” i z pomocą instrukcji dostarczonej przez twórców Scrum Guide spróbować rozwiązać problem, zanim statek zacznie tonąć. Takimi pęknięciami mogą być zarówno negatywne nastawienie członków Zespołu Scrumowego do siebie nawzajem spowodowane konfliktem, opóźnienie w codziennych zadaniach z powodu braku zaangażowania w pracę czy problem w zgłaszaniu zauważonych błędów w kodzie.
Każdy z nas słyszał też, że lepiej zapobiegać, niż leczyć. Tak samo jest i w tym wypadku. Konstruktywna informacja zwrotna zapobiega napięciom i konfliktom. Dzięki takiej przejrzystości łatwiej jest skupić się na wykonywanej pracy.
Dobrym przykładem budowania szacunku w zespole może być sytuacja, gdy firma decyduje się na zaangażowanie Agile coacha. Dzieląc się wiedzą i umiejętnościami, nie tylko ułatwia on pracę nad przyszłymi projektami, ale także buduje lepszą atmosferę w zespole, tworząc bezpieczne środowisko.
Przeczytaj także: Agile Coach vs Scrum Master – kogo potrzebuje mój zespół?
Zespół Scrumowy – rola Product Ownera w organizacji
Scrum promuje wartość, jaką jest szacunek, poprzez uwzględnienie pewnych postaw w rozwiązywaniu złożonych problemów. Jednak szacunek w Scrumie nie powinien ograniczać się do relacji w zespole programistycznym. W tej kwestii może pomóc Product Owner, który ściśle współpracuje z zespołem, reprezentując biznes. Rozszerzenie pojęcia szacunku w Scrumie poza granice Zespołu Deweloperskiego, pozwala dostrzec dodatkowe pole dla rozwijania tej wartości.
PO wyraża szacunek dla zespołu, przekazując mu pieczę nad Backlogiem Sprintu. Ufa, że zespół najlepiej wie, ile pracy można wykonać w danej Iteracji i jak to zrobić. W ten sposób ludzie pracują autonomicznie, co stwarza możliwości rozwoju. Może on również promować szacunek, rozwiązując złożone problemy i dostosowując się do pracy w bardzo często niesprzyjających środowiskach.
W tej relacji również działa to w dwie strony. Developerzy, idąc w ślad za Product Ownerem, w pełni angażują się w powierzone zadania i szanują Właściciela Produktu oraz Interesariuszy, którzy wiedzą, że mogą na sobie nawzajem polegać. Co ważne, w pełnym szacunku środowisku zespół powinien również otwarcie komunikować się, informując o dostarczonych i niedostarczonych funkcjonalnościach.
Wartość Scruma: szacunek = lepsza transparentność?
Członkowie Zespołu Scrumowego doskonale rozumieją, że szacunek jako sztuka okazywana odmiennym zdaniom, pomysłom, celom, rozwiązaniom czy nawet kompetencjom jest niezbędny do sprawnego i bezkonfliktowego działania Scrum teamu. Ktoś, kto czuje poszanowanie wobec swoich błędów, jak i „małych wygranych”, jest w nich bardziej transparentny. Stawia na uczciwość. Nie boi się, że nie zostanie wysłuchany, i ponosząc pełną odpowiedzialność, przyjmuje feedback. Dzięki temu skupia się na realizacji wizji produktu.
Przestrzeganie tej wartości na wielu płaszczyznach relacji międzyludzkich skutkuje postępowaniem według pozostałych wartości w Scrumie. Pokazuje to, jak nieodłączne i kluczowe dla siebie nawzajem są wartości i zasady zawarte w Przewodniku.
Zespół Deweloperski dzięki szacunkowi pracuje zwinnie w sposób otwarty, odważny, pełen zaangażowania i skupienia nad realizacją zadań, a w rezultacie też nad całym projektem.
Zasady szacunku w Zespołach Scrumowych pracujących według metodyki zwinnej:
- cenimy jednakowo opinię wszystkich,
- słuchamy z taką samą uwagą, bez względu na to, kto mówi,
- nigdy nie przerywamy mówiącemu podczas Daily,
- szanujemy nowe pomysły,
- liczymy się ze zdaniem innych oraz wiemy, że inni również się z nim liczą,
- jesteśmy otwarci na uwagi Product Ownera.
Korzyści płynące z szacunku w Scrumie – podsumowanie
Na koniec podsumujmy, dlaczego te wartości są tak istotne. Wartość szacunku w metodologii Agile jest niebagatelna, a budowanie szacunku w relacjach międzyludzkich jest procesem długotrwałym i wymaga wsparcia na każdym etapie.
Wyjątkowo trudnym sprawdzianem dojrzałości relacji jest moment, w którym klient zmienia zdanie lub się myli, a także kiedy Zespołowi Scrumowemu zdarzy się popełnić błąd. W branży IT jest to naturalna sytuacja i jeśli dzieje się to w otwartym i życzliwym środowisku, należy to zaakceptować i zrozumieć. Odpowiedzialny i szanujący się zespół to taki, w którym członkowie potrafią radzić sobie z krytyką.
Przeczytaj także: Metodyki zwinne. Scrum a inne podejścia: SAFe, LeSS, Nexus
