Go to Top

Zwinna (r)ewolucja

Scrum

Czyli jak to było ze Scrumem w Kroll Ontrack w ciągu ostatnich lat. Z czymś, z czego byliśmy (i nadal jesteśmy) dumni i przez co jesteśmy rozpoznawani na rynku.

Zaczęło się wręcz idealnie, czyli odgórnie.

W 2012 roku zapadła decyzja, że przechodzimy ze słynnego „waterfalla” na Scruma, a zarząd zapewnił pełne wsparcie transformacji. Jak najlepiej to zrobić w dużej organizacji? Metodą małych kroków. Wybrany został jeden zespół w USA, ówczesny menadżer został Scrum Masterem (nie jest to najlepsze rozwiązanie, ale na początek wydało nam się sensowne). 3-tygodniowe sprinty. W tym samym czasie zaczęło rozwijać się także polskie biuro, które takie rozwiązanie przyjęło z dużym entuzjazmem. Po krótkim czasie mieliśmy już drugi zespół scrumowy – tym razem w Polsce. Pierwsze retrospektywy, pierwsze eksperymenty, ale także pierwsze porażki. Nie jest ważne, czyja to była wina, ale to czego się nauczyliśmy i czego musimy unikać w przyszłości. Ciągłe eksperymenty i ciągła edukacja. W trakcie kolejnych miesięcy na Scruma zaczęły przechodzić następne zespoły. Po roku mieliśmy ponad 15 zespołów i cały departament „w Scrumie”.

To był dopiero początek.

Niemal równolegle pojawiły się następujące pytania i wyzwania:

  • Kto może i powinien być Scrum Masterem, a kto Product Ownerem?
  • Jak skutecznie przeprowadzać wydarzenia w Scrumie? Począwszy od Daily Scruma i kuriozalnych spraw – stać, czy nie stać? Czy 15 minut wystarczy? A co w sytuacji, kiedy spotkanie się przeciągnie? Tylko słynne 3 pytania, czy może coś więcej? Mówić szczerze, czy może lepiej coś pominąć? Retrospektywa – w biurze, czy poza nim? Jakie ćwiczenie tym razem? Itp., itd…
  • Jak pogodzić prace nad projektami z ciągłym rozwojem biura i zatrudnianiem nowych osób, które trzeba wdrożyć w projekty?
  • Skąd wiemy, że coś jest skończone? A więc Definition of Done (DoD), które rodzi kolejne implikacje w stylu co zrobić, gdy kilka zespołów pracuje nad jednym systemem, odrębnymi modułami i mają zupełnie rozbieżne DoD?
  • Dotknęliśmy również skalowania Scruma, na długo przed ogłoszeniem Nexusa. Na przykład – 4 zespoły w 3 krajach i 3 strefach czasowych, jeden backlog, jeden PO i mnóstwo zależności.
  • Jakość, automatyzacja, release’y – temat rzeka…
  • Naturalnie zrodziła się potrzeba wymiany wiedzy i doświadczenia – na każdym szczeblu organizacji – testerzy, jakościowcy, deweloperzy, Scrum Masterzy, Product Ownerzy.
  • Leadership w zwinnym świecie, czyli częste pytanie: co ma robić menadżer w zwinnej organizacj? No właśnie – to, co powyżej. I jeszcze więcej.

Zaufanie to podstawa.

Po kilku miesiącach pracy role zaczęły kształtować się naturalnie, w zgodzie z osobowością poszczególnych osób. Niektóre z nich zostawały Scrum Masterami, inne PO, a jeszcze inne z radością mogły wrócić do kodu lub testów. Głównym zadaniem kierowników i menadżerów stało się „prowadzenie” organizacji i stopniowe uzwinnianie kolejnych jej obszarów. Wzorując się na najlepszych, powstał backlog tematów „organizacyjnych” inspirowany życiem zespołów i projektów, które liderzy zaczęli rozwijać z udziałem inżynierów. Pojawiły się iteracje, planowanie prac i przegląd dokonań. Mijały miesiące, niemal każdy obszar departamentu został dotknięty zmianą. Autonomia, którą daliśmy zespołom, potrafi zdziałać wielkie rzeczy dla organizacji. Bazujemy na zaufaniu.

Warto wspomnieć, że wprowadziliśmy wspólną definicję Definition of Done składającą się z kilku poziomów. Każdy zespół dziedziczył po niej i pojawiła się zdrowa rywalizacja między zespołami, zainwestowaliśmy w automatyzację testów i releasów. Scrum Masterzy i PO potwierdzali swoje doświadczenie kolejnymi certyfikatami scrum.org, a grupy zainteresowań (community of practice) zaczęły się spotykać i dzielić wiedzą. Pojawili się Agile Coachowie wspierający zespoły i kierownictwo. W większości zespołów pojawili się „mistrzowie” ds. bezpieczeństwa i architektury, którzy odpowiedzialni byli za propagowanie wiedzy i uwspólnianie podejścia do ww. tematów. Zobaczyliśmy, że dział IT wspólnie z działem Rozwoju Oprogramowania potrafią świetnie współpracować, jeżeli tylko wspólnie skupiamy się na najważniejszych tematach. To zainspirowało organizację, aby zacząć pracować wg priorytetów projektowych, czyli taki Product Backlog w skali makro.

Dość wcześnie zaczęliśmy zadawać sobie pytanie: skąd wiemy, jak nam idzie? Co prawda mieliśmy poczucie, że nie najgorzej, ale szukaliśmy potwierdzenia. Zaczęliśmy mierzyć się z mierzeniem, czyli metryki. Kolejny temat rzeka – prawie 3 lata prób implementacji różnych metryk, z których jedne się przyjęły, a inne nie. Ostatecznie zatrzymaliśmy się na 3 metrykach – SLA, Time to market i zadowolenie klientów, czyli Net Promoter Score.

„Stała jest tylko zmiana”

Pewnego grudniowego dnia przyszło olśnienie. Zadaliśmy sobie pytanie: czy to już nie rutyna? Zewsząd słyszeliśmy, że „stała jest tylko zmiana”, więc spojrzeliśmy na nasz świat z zupełnie innej perspektywy. I co zobaczyliśmy? Sprinty mogłyby być z powodzeniem krótsze, niektóre zespoły mogłyby pracować w duchu kanbana, by lepiej reagować na potrzeby „biznesu”. Część zespołów mogłaby być mniejsza, co pozwoliłoby nam bezpiecznie zwiększyć WIP, czyli ilość inicjatyw toczących się równolegle. Mimo inwestycji w automatyzację release’y mogłyby być jeszcze krótsze i częstsze, refinement’y i retrospektywy stały się rutynowe i nic nowego już nie wnosiły… Zatem nadeszła zmiana. Wszak jest stała.

W tych kilku akapitach starałem się opisać naszą kilkuletnią przygodę ze Scrumem, który – jak napisał mój poprzednik Karol – jest naprawdę dobry. Nie sposób tego wszystkiego streścić w kilku akapitach, jednak doświadczenie, jakie zdobyliśmy, jest bezcenne. Scrum nie jest jednak lekarstwem na wszystko. Jest raczej soczewką, przez którą można zobaczyć problemy organizacji. Wiele z nich na książkowym Scrumie się zatrzyma. Dla innych będzie to tylko wstępem do kolejnych etapów ewolucji, które prawdopodobnie nie będą miały końca w poszukiwaniu tej najlepszej metody. Najgorzej jednak byłoby zatrzymać się stwierdzając „przecież tak robimy od lat”… – tego Wam nie życzymy. Udanych eksperymentów!

Centrum Rozwoju Oprogramowania zaprasza w swoje progi!

W związku z dynamicznym rozwojem naszej firmy i rosnącą liczbą projektów, poszukujemy 20 osób, od stażystów po doświadczonych testerów automatycznych i programistów z obszarów C#, C++, SQL oraz technologii internetowych – Angular i TypeScript. Aktualne oferty pracy możesz znaleźć tutaj. Nie zwlekaj – wyślij swoje CV na adres praca@krollontrack.pl i dołącz do Kroll Ontrack!


PS: Dzisiaj obchodzimy Międzynarodowy Dzień Programisty! Tutaj możesz poczytać o historii tego święta 😉

, , , ,

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *