8. Sebastian Kulpa | Softnet: Large-Scale Scrum w bankowości.

W momencie, kiedy podjęliśmy próbę stworzenia jednego wspólnego backlogu i przyszło mi zarządzać tym backlogiem, zmieniać priorytety, ustalać je, przygotowywać je pod kolejne sprinty. To nie wspólny backlog, on był w zasadzie na początku tylko w teorii wspólny, bo tak w rzeczywistości Tych backlogów w głowie ja musiałem mieć kilka, bo musiałem pamiętać o tym, że tutaj są osoby, które są specjalistami w danym temacie, w danym systemie, w danym jakimś feature'ze i pomimo tego, że my to mieliśmy wszystko ustrukturyzowane w jeden sposób, no to tak naprawdę i tak trzeba było mieć w głowie to,

I nie musiałem właśnie myśleć o tym, że mamy jakąś grupę osób, które się specjalizują w jakimś tam elemencie systemu i na siłę powiedzmy czasami szukać im zajęcia. Często kończy się to tym, że po prostu wytwarza się jakieś feature'y które nie do końca są potrzebne, a powodują tylko w przyszłości problemy w utrzymaniu. I jeszcze powodują zajętość pozostałych ludzi, którzy się powinni zajmować rzeczami, które są priorytetowe, no bo najczęściej to trzeba zintegrować. Fajnie. Dobra, czyli teraz tak, macie te trzy zespoły deweloperskie, rozumiem, że następna przeszkoda to, która przed Wami stoi. Tak, no i jak nam się udało posprzątać powiedzmy większość rzeczy, które byliśmy w stanie w tym gronie, w którym pracowaliśmy poukładać,

Dokładnie tak. No często, ja sam jeszcze, dewelopując mnie, prawdopodobnie to było jedną z przyczyn, dla których poszedłem w tym kierunku, w którym poszedłem, było to, że Irytował mnie taki głuchy telefon, czyli ja byłem gdzieś tam którymś elementem w łańcuszku, który dostał jakieś zrębki informacji, realizował to według tego co otrzymałem, no i później się okazywało, że to jednak nie spełnia oczekiwań osoby, która była źródłem tego głuchego telefonu, w związku z czym Wydaje mi się, że łącząc właśnie tą całą grupę osób, które nad tym pracują dużo lepiej rozumiemy potrzebę klienta i osoba później dewelopując danego feature'a wie tak naprawdę jaki problem rozwiązuje, a nie tylko dostaje jakieś rozwiązanie, które ma do zaimplementowania.