Jak rozpocząć pracę, jako Zespół Scrumowy?
Nie jest to takie łatwe, jakby mogło się wydawać. Jeszcze trudniej wejść nowej osobie do zespołu, który już wcześniej pracował razem. Na początku warto zadać sobie podstawowe pytania: jaki jest cel zespołu, po co został on zbudowany, jakim produktem ma się opiekować, jaki(e) projekt/projekty ma realizować i jakie potrzeby biznesowe zespół ma zaspokajać; a jeśli zespół wcześniej nie pracował scrumowo, to jaki jest poziom wiedzy na temat frameworku Scrum?
Założenie, że członkowie zespołu znają podstawy pracy w Scrumie, może okazać się błędne. Uzupełnienie wiedzy w tym zakresie jest istotne, ponieważ wspólne działania nie mogą bazować na złych wzorcach. Jednocześnie warto ustalić zasady pracy zespołu, jego kulturę, przyzwyczajenia, metody działania. Pomocny w tym zakresie jest kontrakt zespołowy. To nic innego, jak nazwanie i ustalenie kilku istotnych reguł, które muszą być przestrzegane w trakcie wspólnej pracy. To oznacza dyskusję o wartościach i oczekiwaniach teamu. Nawet jeżeli będą to oczywiste sprawy, warto wypowiedzieć je „na głos”, tak by cały zespół potwierdził wolę ich przestrzegania. W trudnych sytuacjach będzie można się do tych słów odwołać.
Jaką wybrać nazwę?
Tożsamość zespołu jest istotna, dlatego tego kroku nie można pominąć. Tu liczy się oryginalność i niesztampowe podejście do tematu; pozwoli to lepiej spoić członków zespołu. Gdyby udało się wybrać nazwę nawiązującą do historii zespołu, to zyskamy dodatkową wartość dającą mu poczucie przynależności do bractwa wtajemniczonych. Gdy umiejętności zespołu na to pozwalają, to warto przygotować logo.
Kto wchodzi w skład teamu?
Ważne jest ustalenie, kto wchodzi w skład zespołu deweloperskiego, jakie są umiejętności i predyspozycje jego członków, tzn. czy są one wystarczające, aby skutecznie realizować wyznaczony na początku cel i czy koniecznym jest szukanie szczególnych kompetencji poza zespołem? Żeby określić skład zespołu, trzeba też znać odpowiedzi na dodatkowe, istotne pytania, tj.: jakie kompetencje koniecznie musimy zdobyć, aby skutecznie pracować, jaka wiedza jest niezbędna, jakie książki należy przeczytać i w jakich kursach wziąć udział.
Kto będzie pełnił rolę Właściciela Produktu?
Zespół potrzebuje osoby decyzyjnej, która ma wizję na temat produktu i przejmie za niego odpowiedzialność. Jeżeli nie jesteście w stanie wybrać osoby, która przyjmie na siebie tę rolę, praca w Scrumie przestaje mieć sens. Bez osoby, która wie, jak kształtować produkt, jaka jest jego rola na rynku i co chcemy osiągnąć, nie damy rady go efektywnie stworzyć.
Kto zostanie Scrum Masterem?
Nie da się pracować w Scrumie bez tej ważnej roli, dlatego wybierzcie spośród siebie Scrum Mastera, który będzie odpowiadać za przestrzeganie procesu. Trzeba dodać, że taka osoba jest liderem, ale nie ma formalnej władzy nad zespołem; pomaga mu dostarczać produkt i dochodzić do porozumienia między członkami zespołu. Ważne, aby osoba ta chciała tę rolę pełnić. Jeśli w zespole nie znajdzie się dobry kandydat, to konieczna będzie rekrutacja wewnątrz organizacji lub zewnętrzna.
Co z Definicją Ukończenia?
Zanotujcie Wasz pomysł na Definicję Ukończenia. Zaakceptować ją muszą wszyscy członkowie zespołu. Od początku konieczne jest jej przestrzeganie. Od pierwszego dnia pierwszego Sprintu. Warto zapytać Właściciela Produktu, czy nie jest konieczne uzupełnienie tej listy o kilka dodatkowych punktów (bardziej biznesowych niż technicznych). Uwzględnijcie w swojej Definicji Ukończenia wytyczne organizacyjne (standardy co do procesu wytwórczego, standardy kodowania).
Jaki jest przebieg wydarzeń scrumowych?
Ustalcie długość Sprintu oraz terminy wydarzeń: codziennego Scruma oraz planowania Sprintu, przeglądu Sprintu i retrospektywy Sprintu. Warto uzgodnić to z Właścicielem Produktu, ponieważ być może Sprint Review będzie trzeba dopasować do możliwości wzięcia udziału w nim jakiegoś ważnego interesariusza. Umówiona osoba (np. ochotnik z zespołu) wrzucać będzie cykliczne zaproszenia na wszystkie ustalone wydarzenia do kalendarza. Nie wolno zapomnieć o cyklu Doskonalenia Rejestru Produktu – zwłaszcza, jeśli zespół dopiero zaczyna i trzeba będzie zbudować go praktycznie od zera.
Co stanowi pierwsze elementy Rejestru Produktu?
Najpóźniej podczas pierwszego planowania Sprintu Właściciel Produktu powinien przedstawić wstępny pomysł na elementy Rejestru Produktu. Zespół przecież potrzebuje zadań do realizacji, aby mógł rozpocząć pracę. Zbudowanie pierwszych elementów może się odbyć w ramach warsztatu, który można odbyć wraz z klientem/klientami lub najważniejszymi interesariuszami.
Czy zespół może liczyć na wsparcie?
Ustalcie wszelkie drogi wsparcia dla Waszych prób wdrażania Scruma, tzn. kto może wspomóc Scrum Mastera, służyć mu wsparciem w rozwoju i wiedzą, oraz kto pomoże całemu zespołowi w zastosowaniu Scruma (o ile czujecie, że nie macie wystarczającego doświadczenia). Zorientujcie się, na co możecie liczyć ze strony menedżerów i innych zespołów. Upewnijcie się, jak organizacja może pomóc w rozwiązaniu problemów, jakie napotkacie i rozpoznacie w ramach pierwszych Retrospektyw.
Kilka ogólnych zasad przy startowaniu nowego zespołu, o których warto pamiętać.
- Nie ma idealnego rozwiązania. Wszystkie możliwe sposoby podejścia, które ustalicie na początku, mogą ulec zmianie w ramach kolejnych Retrospektyw. Nie musicie szukać rozwiązań idealnych; to, co ustalicie, powinno zostać zaakceptowane przez członków zespołu jako punkt wyjścia.
- Zaufajcie empiryzmowi – nie martwcie się z góry. Rozpocznijcie pierwszy sprint i zobaczcie, jaki będzie jego efekt. Niektóre wyobrażenia i tak okażą się przesadzone, na pewno wydarzą się niespodziewane sytuacje.
- Jeśli nikt z Was nie ma doświadczenia w Scrumie, warto zadbać o to, by ktoś doświadczony mógł pomóc na początku. Zadbajcie w trakcie rozpoczynania pracy o udział osoby spoza zespołu, która posiada takie doświadczenie (np. Agile Coach spoza firmy lub Scrum Master z innego zespołu). Do podejmowania niektórych decyzji przyda się rozpoznanie różnych możliwości, o których osoby bez doświadczenia mogą nawet nie pomyśleć.
- Postarajcie się przyjąć realistyczne założenia. Oprzyjcie się o obecny sposób funkcjonowania zespołu albo organizacji. Nie próbujcie naprawiać całego wszechświata za jednym razem.
- Pamiętajcie, że zwinność to nieustanne zmiany. To ciągły proces, a nie osiągnięty stan. Zawsze jest coś do weryfikacji i poprawy. Nie spoczywajcie na laurach, szukajcie nowych rozwiązań, próbujcie, eksperymentujcie, pozwólcie sobie na błędy. Porażka to punkt wyjścia do dalszych usprawnień.