W INCAT rozpoczęliśmy przygodę z podcastami. W efekcie przygotowaliśmy dla Was rozmowę z naszym incatowym Scrum Masterem, Karolem Kłaczyńskim, z którym omawiamy temat Scruma w dużych projektach bankowych. Odnośnik do podcastu znajdziecie poniżej, a jeśli nie macie tyle czasu by przesłuchać całość, zapraszamy do poniższego artykułu, w którym zebraliśmy dziesięć kluczowych wskazówek i ważnych stwierdzeń, które padły w podcaście. Bierzcie więc i czytajcie z tego wszyscy :).

O zwinności biznesowej

Zwinność biznesowa to swoisty mindset, sposób myślenia nastawiony na ludzi, na dostosowywanie się do zmian. Scrum z kolei to framework, który promuje podejście zwinne, czyli jest to zestaw pewnych zasad, zdarzeń, ról i artefaktów, które można obudowywać swoimi elementami i który pomaga sobie radzić ze skomplikowanymi projektami biznesowymi i tworzeniem rozbudowanych systemów. Zwinny sposób myślenia pomaga się dostosowywać do wymagań klienta i, w efekcie, tworzyć lepsze rozwiązania.

O zwinności w projekcie i zwinności na poziomie organizacji

Zwinność na poziomie tworzenia produktu jest kluczowa, ale równie ważne jest, aby zwinne podejście prezentowała cała organizacja. Najlepiej widać tę zależność na przykładzie. Problem, który może się pojawić, to na przykład kwestia tego, że potrzebujemy nowego sprzętu w projekcie. I jeśli organizacja nie działa zwinnie, a osoby, które odpowiadają za tego rodzaju sprawy są swoistym wąskim gardłem organizacji, to nawet jeśli na poziomie projektu zespoły działają zwinnie, niewiele to pomoże, jeśli na trzy monitory i dwa notebooki będziemy czekać trzy-cztery tygodnie. Zespół jest zblokowany zewnętrznymi zależnościami, co odbija się na powodzeniu projektu.

O transformacji w organizację zarządzaną zwinnie

Ważne jest zrozumienie i wola ze strony zarządu. Zrozumienie, że jeśli organizacja nie będzie działać zwinnie, to efekty będą ograniczone. Warto też wybrać “agentów zmiany”, czyli osoby, które mają doświadczenie w pracy zwinnej i mają na tyle duże poważanie oraz posłuch u pozostałych członków organizacji, by móc tę zmianę propagować i przeprowadzać. Na początku kluczowe jest jednak, aby ustalić zasady, reguły i proces przejścia na agile w organizacji, w taki sposób, by był on jak najbardziej dopasowany do specyfiki i wymagań danej firmy. Stworzenie kontraktu w takiej sytuacji może być dobrym pomysłem, natomiast warto pamiętać o tym, by raczej go nie spisywać – określić i zobowiązać się do jego przestrzegania, ale niekoniecznie traktować jak pisemnej umowy. To jest na początku bardzo trudne, ale z mojego doświadczenia wynika, że im większy poziom zaufania w zespole/ organizacji, tym z czasem jest łatwiej trzymać się opracowanych postanowień.

O projektach, w których scrum się nie sprawdza

Bardzo małe produkty, albo tworzenie proof of concept to coś, do czego scrum niespecjalnie przystaje i może być czymś w rodzaju armaty na wróble. Inwestycja w scruma w małych, niewymagających projektach może być wyższa niż oczekiwane korzyści. Jeśli produkt jest oczywisty i mamy bardzo dokładnie opisane wymagania i pewność, że założenia biznesowe raczej się nie zmienią, to w takiej sytuacji wprowadzanie scruma nie jest dobrym pomysłem. Scrum dobrze radzi sobie w projektach rozbudowanych, dynamicznych, z często zmieniającymi się zarówno oczekiwaniami klienta, jak i warunkami rynkowymi.

O narzędziach, które daje scrum

Scrum daje pewne zasady, definicje, nadaje role w projekcie. Cele poszczególnych ról i wydarzeń są dobrze i jasno opisane w Scrum Guide, co bardzo ułatwia promowanie zwinności w organizacji. Jeśli się wczytamy w Scrum Guide’a, zobaczymy w jaki sposób każdy ten element wspiera zwinność. Na przykład Daily Scrum tę zwinność wspiera w ten sposób, że de facto cały czas planujemy i mamy pod kontrolą to co robimy jako zespół na bieżąco, dostosowujemy się natychmiast do nowych wymagań, od razu rozwiązujemy problemy, wyciągamy je “na wierzch” każdego dnia, a nie raz na dwa tygodnie, gdy zdążą już urosnąć do niebotycznych rozmiarów. Backlog z kolei pokazuje jaki mamy plan na najbliższy czas, a dostosowanie backlogu do nowych warunków pomaga łapać szerszą perspektywę nie tylko na najbliższy sprint, ale także na miesiąc, czy dwa do przodu.

O relacji Scrum Mastera z Product Ownerem

Rola Scrum Mastera wobec Product Ownera to przede wszystkim nauka pracy w ramach zespołu scrumowego, wsparcie w kwestiach budowania backlogu i tworzenia analizy biznesowej. Product Owner to taka osoba, która musi dużo mówić “nie”, bo, zwłaszcza w dużych organizacjach, istnieje sporo stakeholderów i osób decyzyjnych, a każdy z nich jest tak samo mocno przekonany o tym, że jego pomysł, jego funkcjonalność jest kluczowa. I jakoś trzeba tym zarządzić, w czym czasami nieodzowna jest pomoc i wsparcie Scrum Mastera.

O wyzwaniach scruma w dużych projektach

Sporym problemem jest to, że wiele organizacji chce zbyt szybko skalować swoje bardzo zaawansowane produkty, bez podchodzenia do tematu iteracyjnie. Podejście iteracyjne to takie, w którym mamy jeden zespół, on pracuje na zwinnych zasadach, a następnie rozwijamy kolejny, w którym umieszczamy agentów zmiany i oni uczą ten nowy zespół przestrzegania zasad agile. Niestety, zazwyczaj jest tak, że mamy jeden zespół, dorzucamy osiem kolejnych, nikt nie rozumie na czym polega zwinność, ale liczy się sam fakt, że “pracujemy w scrumie”. Inna sprawa to fakt, że w dużych, wielozespołowych projektach planowanie odbywa się na wyższym poziomie, czasami trzeba je organizować pomiędzy reprezentantami poszczególnych zespołów. Jest też kwestia komunikacji wewnątrz zespołów – problemy jednego zespołu wpływają na pozostałe. Wyobraźmy sobie, że mamy jakiś wspólny komponent, czy bibliotekę z której korzystają wszyscy w projekcie i nagle zmieniamy jej wersję. Pozostałe zespoły muszą o tym wiedzieć, przygotować się na to, zsynchronizować działania. Jeśli komunikacja pomiędzy zespołami zawodzi, takich procesów nie da się przeprowadzić bez wpadek. Mówiąc krótko – wszystkie problemy, które występują na poziomie jednego zespołu, w przypadku kilku lub kilkunastu mocno się skalują – i to w postępie geometrycznym.

O zwinności w branży bankowej

Zwinność w branży bankowej już jest. Jeszcze nie na poziomie systemów centralnych, ale na poziomie np aplikacji czy portali, podejście zwinne całkiem nieźle się przyjęło. Klienci w branży bankowej niejako wymagają tych zmian – istnieją rozwiązania typu Revolut, które świetnie i szybko odpowiadają na zmiany w obrębie wymagań biznesowych i to sprawia, że branża bankowa musi się szybciej dostosowywać do klienta, bo konkurencja, nierzadko bardziej elastyczna, nie śpi.

O procedurach w bankowości

Zwinność i Scrum może w pewien sposób uświadomić decydentom w projektach bankowych po co istnieją wybrane procedury. I ze względu na transparentność, rozwiązywanie problemów i reagowanie na bieżąco, nierzadko może się okazać, że praca w Scrumie identyfikuje, które procedury są przestarzałe, nieadekwatne, niepotrzebne. Scrum pyta “dlaczego” i “po co” i dzięki temu pomaga uporządkować pracę, oszczędzać czas i w efekcie pieniądze.

O pogodzeniu monolitu ze Scrumem

Monolity nie lubią zmian, to rzecz oczywista. Ale, zazwyczaj monolity mają takie elementy, które można powoli wydzielać i przekształcać je w elementy zwinne. Oczywiście, można mieć ambicję, by projektem monolitycznym zarządzać całkowicie zwinnie, natomiast wiąże się z to dużymi wyzwaniami typu koszty, czas, nieodporność na zmiany. Wydaje się więc, że strategia wolniejsza, ale pozbawiona tych wszystkich ryzyk, polegająca na wydzielaniu modułów które da się elastycznie zarządzać jest lepszą opcją.

Chcesz sięgnąć po więcej? Całą rozmowę z Karolem znajdziesz tutaj: