SAFe® wyjaśnione: Wartość „Przejrzystość"

SAFe opiera się na czterech centralnych wartościach. Dwie pierwsze – Alignment i wbudowana jakość – zostały już przez nas opisane. Trzecia z tych wartości to „Transparency" – po polsku: „Przejrzystość". Dlaczego jednak przejrzystość jest tak ważna, że zostaje zapisana jako centralna wartość – i co się za nią kryje? Choć istnieje wiele obszarów, w których przejrzystość pomaga, w tym artykule chcemy pokazać jedynie kilka kluczowych aspektów, w których jej brak tworzy poważne przeszkody dla skutecznego tworzenia produktów.

Na poziomie strategicznym omawiane są ważne tematy dotyczące rozwoju portfolio:

Decyzja jest szybko podjęta – a reszta to przecież „tylko" realizacja. Ale tę „trywialną realizację" ktoś musi oczywiście wziąć na siebie. I tak odpowiedzialność przejmuje Portfolio Manager:

Temat trafia więc jako Epic do Portfolio Management. Jego swoboda decyzyjna jest cenna, ale rodzi też problemy, które trzeba rozwiązać:

Decyzja portfelowa ma oczywiście potem daleko idące konsekwencje dla pracy zespołów w ramach ART:

Możemy uważać się za szczęśliwych, gdy w ogóle ma miejsce tyle komunikacji, że na poziomie portfolio istnieje rozumienie tego, które prace są jeszcze realizowane równolegle i jakie konsekwencje mają nowe Epiki dla dostawy każdej pojedynczej funkcji. I tak też jest planowane:

Zespoły przystępują do pracy, każdy robi, co może – bolesne przebudzenie przychodzi podczas demo z klientem:

Opinia klienta musi być oczywiście traktowana poważnie, więc Product Ownerzy przekazują ją z powrotem do zarządzania:

I tak toczy się dalej "głuchy telefon":

Powstałe nieporozumienia prowadzą potem do tego, że uspokaja się klientów, przerywa już rozpoczęte prace i odkłada na później częściowo ukończone tematy. Nie jest to ani pożądane, ani zrównoważone.

Aby zapobiec sytuacji, w której tak naprawdę nikt nie wie, co, dlaczego i kiedy jest ważne, potrzebna jest wysoka przejrzystość.

Działania SAFe na rzecz zwiększenia przejrzystości:

• Istnieje jedno, centralne Portfolio Kanban. Dzięki temu jest jednolity widok na to, które Epiki są aktualnie realizowane, które są następne w kolejce – a które są już ukończone.

• Cele Program Increment są wspólnie ustalane podczas PI Planning jako PI Objectives i są w każdej chwili widoczne dla wszystkich uczestników.

• Zespoły zobowiązują się do krótkoterminowych, jasnych celów i zwykle je realizują.

• Gdy zespoły odbiegają od swoich celów, komunikują to nie tylko wewnętrznie, ale również między sobą – i to odpowiednio wcześnie.

• Widok na Program- i Architecture-Kanban jest dostępny dla wszystkich, którzy mają do czynienia z Agile Release Train (ART).

• To samo dotyczy backlogów wszystkich zespołów w ramach ART.

• Postęp programu jest weryfikowany podczas Iteration i System Demos. Dzięki temu szybko widać, gdzie pierwotny plan wymaga dostosowania.

• Harmonizacja strategii z rzeczywistą pojemnością zespołów deweloperskich

• Istnieje wspólne rozumienie pojęcia "Velocity" aż do poziomu zarządzania

• Panuje jasność co do WIP na poziomie zespołu i programu – w szczególności co do tego, że WIP powinno się ograniczać.

Te działania w żadnym wypadku nie pretendują do pełnej kompletności, stanowią jednak niezbędne minimum, aby zapobiec najczęstszym problemom.

SAFe stawia na to, że każda osoba wie, jak może przyczynić się do jak najszybszego dostarczenia najwyższej wartości – a także na zaufanie, że każdy wniesie swój wkład w sukces. Czwartą wartość, Program Execution, wyjaśnimy w kolejnym artykule.