Nakreślę w tym miejscu w skrócie swoją sytuację w pracy. Już kilka długich lat w IT jako programista. Dopiero pół roku temu zacząłem pracować w zespole kierowanym wg Scrum. Do tej pory miałem styczność jedynie z różnymi wariacjami Waterfalla, z prostymi dziennymi statusowymi zdzwonkami lub po prostu wolną amerykanką. Próba przejścia na Scruma już na początku doprowadziła wśród moich kolegów do wielu burzliwych dyskusji. Niekiedy dosyć emocjonalnie podchodzili oni do zmian względem wyuczonego stylu działania i nawyków. Były to na przykład konieczność wchodzenia programistów w kompetencje testerów (gdy ci nie wyrabiali się z pracą), brak zajęcia dla koderów na koniec sprintu (a nie mogliśmy dorzucić sobie nowego zadania do pisania, bo nie osiągnęlibyśmy na czas Definition of Done) i tak dalej.
Szczególnie przeszkadzał nam brak czasu na faktyczne programowanie. Otóż czas ten był wg nas zajęty głównie przez częste i rozwlekające się spotkania i dyskusje. Być może wynika to z naszych przyzwyczajeń, w końcu serduszko nałogowego kodera cierpi, gdy musi czekać on na zadania lub robić coś innego niż programowanie. Tutaj daily, tam jakieś retro, a potem jeszcze nawet pół dnia planowania i czasu w sprincie zostaje mało. Po naszym zwróceniu uwagi na ten problem, zatrudniony Scrum Master podrzucił nam kilka swoich sugestii, które mają na celu rozwiązywać ten problem, ale też pozwalają spojrzeć na częste i długie spotkania nieco inaczej.
Przede wszystkim, czy przed spotkaniem jest określony jego cel? Bez tego możliwe, że jest to niepotrzebny meeting i stracimy tylko czas, bo nie ustalimy na nim niczego konkretnego. Wyznaczony cel pozwoli łatwiej doprowadzić spotkanie do końca i, jeżeli ten cel osiągniemy, to możemy gładko uznać, że ta konferencja dała nam jakąś wartość.
Time Box, czyli ustalone ramy czasowe dla spotkania. O ile jesteśmy zdyscyplinowani lub prowadzi nas moderator (na przykład Scrum Master), to pilnujemy się, by nie odbiegać rozmową od tematu. Niepotrzebne dygresje lub komentarze nie sprawią, że konferencja będzie bardziej wartościowa. Przykładowo podczas daily nie pytamy jak coś zostało rozwiązane (albo dlaczego nie zostało), bo nie zmieścimy się w wyznaczonym do tego czasie 15 minut. Nawet jeżeli okaże się, że będzie potrzebna dodatkowa konsultacja, to oficjalnie kończymy daily w Time Boxie i dopiero potem rozmawiamy o innych sprawach. Możemy się zastanowić, czy potrzebna jest nam na daily obecność Scrum Mastera, o ile potrafimy się sami dobrze zorganizować czasowo. Ponadto, jeżeli Product Owner pojawia się na codziennej zdzwonce, to przypilnujmy, by nie przeciągał rozmowy próbując wprowadzać swoje tematy, gdyż daily jest spotkaniem statusowym tylko dla zespołu deweloperskiego.
Ustalenie Action Points. Są to wywnioskowane i sprecyzowane działania, które wykonamy po zakończeniu spotkania. Najlepiej, by te punkty były jasne dla każdego i zostały spisane, przynajmniej na kartce papieru. Nie zostaną wtedy łatwo zapomniane i jest większa szansa, że faktycznie dojdą do skutku (w porównaniu do ustaleń jedynie wypowiedzianych na forum). Jeśli okazuje się, że zdzwonka nic nam nie dała i po niej nie wiemy od czego zacząć pracę lub musimy się znów kontaktować ze sobą, to prawdopodobnie nie ustaliliśmy celu i/lub Action Pointów. Z kolei o ile udało nam się je określić, to po ich realizacji powinniśmy zweryfikować je pod względem efektów i podjąć dalsze kroki, gdy nie osiągnęliśmy dzięki nim rozwiązania problemu.
Regularne prowadzenie dokumentacji jest ważne, by móc zrezygnować ze spotkań w celu wymiany wiedzy. W moim wypadku były one konieczne, gdy z zespołem zajmowaliśmy się kodem kiepsko opisanym i zapomnianym. Oczywiście powinniśmy robić jak najwięcej, by do sytuacji braku dokumentacji nie doprowadzić. Nie jest ważne, że nie został oddelegowany analityk do jej tworzenia. Zespół powinien sam się wtedy zaangażować w opisanie działania funkcjonalności, by nie rzucać samemu sobie kłód pod nogi i zapobiec problemom w przyszłości.
Jeżeli spotkanie cykliczne nie przynosi nam wartości, to się na nim więcej nie pojawiamy – brutalne, ale skuteczne. Być może wcale nie musimy się na nich meldować, a jednak tam dołączamy na wszelki wypadek w nadziei, że pojawi się interesujący nas temat.
Ocena na koniec spotkania – każdy ocenia w głosowaniu jawnym od 1 do 5 (np przez Fist of Five) czy dyskusja była wartościowa. Wystarczy wyciągnąć wnioski na podstawie tego wyniku.
Kamerki na daily czy innych rozmowach poprawiają komunikację. Widać emocje ludzi i nikt z obecnych nie może zaryzykować braku skupienia na temacie. Uczestnicy mniej ociągają się z odpowiedzią na zadane pytania i rzadziej czekają w ciszy, aż ktoś inny odezwie się za nich.
I jeszcze inne spojrzenie na temat przeciągających się spotkań. Przede wszystkim, jeżeli daje ono zespołowi dużą wartość, to nie jest to czas zmarnowany. Jeśli dyskusja ma dla zespołu duże znaczenie, to interesy osób, które próbują się w tym czasie z nim skontaktować schodzą na drugi plan. Dobrze jest wtedy wyznaczyć czas na przerwę w długim spotkaniu, by interesanci z zewnątrz mieli szansę zadać jakieś pilne pytania.
Na koniec dodam ostatnio przewijającą mi się wśród polecanych na YouTube prezentację z TEDx prowadzoną przez bardzo charyzmatycznego prelegenta, na temat prezentacji, szkoleń i rozmów, oraz wartości, które powinny ze sobą nieść. Smacznego 🙂
Jak nie robić prezentacji, które mogłyby być mailem? | Kamil Kozieł | TEDxKatowice