Pracując jako konsultant, często spotykam się z sytuacją, że moi klienci dokonują kosztownych zmian w projektach, które koniec końców nie przynoszą zbyt wiele wartości. Zainwestowanie wysiłku w innym obszarze dałoby o wiele lepsze efekty. Aby zrozumieć gdzie leży problem i działać w sposób efektywny należy zapoznać się z Teorią Ograniczeń (Theory of Constraints).
Teoria Ograniczeń
Każdy system istnieje po to, aby realizować swój cel. W przypadku firmy może to być zarabianie pieniędzy albo misja społeczna. Teoria ograniczeń zakłada, że zawsze istnieje tylko kilka obszarów, których poprawa spowoduje, że cel będzie osiągany na wyższym poziomie (np. większy zysk). Obszary te nazywa się ograniczeniami (constraints). Najważniejsze jest tutaj założenie, że jeżeli wykonujemy pracę nad czymś co ograniczeniem nie jest, tak naprawdę nie spowodujemy, że nasz system będzie działał lepiej. Takie usprawnienia noszą nazwę optymalizacji lokalnych.
Przykład:
Wyobraźmy sobie sklep spożywczy. Zdefiniujmy cel jako zarabianie pieniędzy teraz i w przyszłości. Mamy tylko jednego sprzedawcę, regularne dostawy zapewniają, że produktów nigdy nie brakuje. Natomiast klientów, którzy przychodzą do naszego sklepu jest więcej niż jesteśmy w stanie obsłużyć.
Optymalizacją lokalną będzie inwestowanie w marketing, aby zwiększyć liczbę potencjalnych klientów oraz budowa dodatkowego magazynu, aby gromadzić więcej produktów na sprzedaż. To jednak nie zwiększy zysków sklepu.
Ograniczeniem jest natomiast sprzedaż. Przykładem działania wzmacniającym obszar, który jest ograniczeniem będzie zakupienie kasy, która pozwoli na szybszą obsługę klientów. Dzięki temu sklep będzie zarabiał więcej1.
Identyfikacja ograniczenia
W czasie, gdy poznawałem Teorię Ograniczeń największym olśnieniem było dla mnie to, że jeżeli wykonamy pracę nad ograniczeniem, możemy je „podnieść” do takiego poziomu, że przestanie nim być. Jednak zgodnie z definicją zawsze jakieś ograniczenia istnieją. Aby ponownie podnieść efektywność całego systemu musimy zidentyfikować nowe ograniczenia.
Przykład:
Zakup nowej kasy przyspieszył pracę sprzedawcy na tyle, że obsługuje na bieżąco wszystkich klientów, którzy przychodzą do sklepu. W tym przypadku dalsze próby zwiększenia efektywności sprzedaży to już optymalizacja lokalna. Aby nasz sklep zarabiał więcej pieniędzy trzeba zidentyfikować ograniczenie w innym obszarze. Być może będzie to ilość towaru albo ilość klientów?
Scrum a Teoria Ograniczeń
Patrząc przez pryzmat Teorii Ograniczeń, Scrum Team2 też jest systemem, który posiada cel. Celem tym jest stworzenie oprogramowania dostarczającego jak największą wartość biznesową. Zgodnie z Teorią Ograniczeń, aby zwiększyć tą wartości, jedynym sposobem jest praca na ograniczeniach. Niestety bardzo wielu Scrum Masterów z którymi pracuje skupia się na optymalizacjach lokalnych.
Przykład:
Scrum Master pomaga zespołowi developerów rozwijać coraz bardziej samoorganizację. Zespół już nawet sam prowadzi sobie retrospektywy. Dodaje się też kolejne elementy do Definition of Done, aby zwiększyć już całkiem wysoką jakość. Równocześnie Product Owner nie zna technik do skutecznego zarządzania Product Backlogiem i nie ma porządnej wizji produktu. Często są tworzone feature’y, które nie przynoszą zbyt wiele wartości biznesowej. Aby naprawdę zwiększyć efektywność całego Scrum Teamu, Scrum Master powinien skupić się na edukacji Product Ownera albo rozwiązaniu problemów ograniczających jego pracę.
Inspect & Adapt a Teoria Ograniczeń
Scrum jest podejściem bardzo mocno empirycznym. Ciągle należy dokonywać inspekcji tego „jak jest teraz” oraz wykonywać akcje adaptacyjne, które nas zbliżają do tego „jak chcemy, aby było”. Odbywa się to na wielu obszarach – począwszy od procesu wytwarzania oprogramowania po wizję biznesowej produktu.
Inspekcję i adaptację procesu często realizuje się na retrospektywie3, a wizję produktową na Sprint Review i planowaniu Sprintu. Jednak nie należy ograniczać się tylko do tych spotkań, wszystko w Scrumie bezpośrednio albo pośrednio powinno temu służyć.
Teoria Ograniczeń do Inspect & Adapt podchodzi w dosyć charakterystyczny sposób. Nosi on nazwę „Five Focusing Steps”4 albo Process of Ongoing Improvement5 – w skrócie POOGI. Jest to cykl 5 kolejnych kroków służących do optymalnego usprawniania systemu w trybie ciągłym.
1. Zidentyfikuj ograniczenie
Zanim rozpocznie się jakiekolwiek działania. Należy zlokalizować, co jest w danym momencie ograniczeniem. Warto ustalić też, czy aby na pewno zlokalizowaliśmy przyczynę źródłową, a nie tylko objaw.
Przykłady:
Niska jakość oprogramowania, konflikt w zespole, brak spójnej wizji produktu.
2. Eksploatacja ograniczenia
Gdybyśmy porównali nasz system do połączonych rur, to eksploatacja ograniczenia jest „przepchaniem rury” w przeciwieństwie do „poszerzenia rury”. Na tym etapie używamy często tego, co już mamy w naszym systemie. Nie dodajemy do niego nowych zasobów/nakładów.
Przykład 1:
Gdy w projekcie ograniczeniem jest niska jakość oprogramowania, możemy zmodyfikować Definition of Done np. dodać Code Review.
Antyprzykładem jest zatrudnienie od razu 3 testerów (wymaga to znacznych zasobów).
Przykład 2:
Product Owner nie ma czasu na zarządzanie Product Backlogiem. Może to wynikać z tego, że musi uczestniczyć w licznych spotkaniach z zarządem firmy. Rozwiązaniem może być redukcja albo eliminacja takich spotkań.
Jeżeli działania na tym etapie pomogły i obszar, na którym wykonaliśmy pracę przestał być ograniczeniem to wracamy do punktu 1, jeżeli nie przestał być ograniczeniem to przechodzimy do kolejnego punktu.
3. Podporządkuj wszystko ograniczeniu
Podporządkowanie wszystkiego jest swojego rodzaju „przekierowaniem sił” do ograniczenia z obszarów które ograniczeniem nie są.
Przykład 1:
Niska jakość oprogramowania – testerzy nie nadążają z testowaniem oprogramowania. Developerzy zaczynają robić testy.
Przykład 2:
Product Owner nie ma czasu na zarządzanie Product Backlogiem z powodu spotkań. Scrum Master, który jest mniej przeciążony reprezentuje go na tych spotkaniach.
Jeżeli te działania pomogły to wracamy identyfikacji ograniczenia.
4. Wzmocnij ograniczenie
Jeżeli poprzednie kroki nie były wystarczające to dopiero na tym etapie używa się dodatkowych zasobów, aby wpłynąć na obszar będący ograniczeniem. Jest to „poszerzenie rury”.
Warto pamiętać, aby nie zaczynać usprawnień właśnie od tego kroku. Niestety często spotykam się z sytuacją, że zanim w ogóle zostanie zlokalizowane prawdziwe ograniczenie, ogromne pieniądze są inwestowane w poszerzanie czegoś, co tak naprawdę ograniczeniem nie jest. To oczywiste marnotrawstwo.
Przykład 1:
Product Owner nie ma czasu na zarządzanie Product Backlogiem. Należy zatrudnijć mu asystenta/asystentkę.
Przykład 2:
Niska jakość oprogramowania – należy zatrudnić dodatkowe osoby: testerów albo programistów.
5. Powrót do kroku „1”
Jeżeli „pokonaliśmy” ograniczenie powinniśmy zlokalizować kolejne i zacząć cykl od nowa. Ważne aby pamiętać o tym, że ograniczenia, które występują, często wynikają z ludzkich nawyków. Inercja systemu może spowodować, że szybko wrócą, jeżeli się przed tym nie zabezpieczymy.
***
Teoria Ograniczeń dostarcza nam narzędzi zwanych Logical Thinking Process (Narzędzia Myślowe). Pozwalają one w sposób systematyczny przejść przez: definiowanie celu systemu, lokalizację ograniczeń, planowanie akcji usuwających ograniczenie oraz zapobieganie skutkom ubocznym naszych działań. Niewątpliwie ich stosowanie dostarcza ogromną wartość. Napiszę o nich w kolejnym poście.
Terminologia i dodatkowe uwagi:
1. Jest to oczywiście duże uproszczenie nie biorące pod uwagę kosztów. Użyłem go, aby zobrazować ideę. Aby stworzyć model biorący pod uwagę zachęcam do zapoznania się z „Rachunkowością Przerobową”.
2. Scrum Team to: Scrum Master, Product Owner i zespół developerów.
3. Sprint Retrospective
4. Five Focusing Steps – Pięć Punktów Skupienia
5. Process of Ongoing Improvement – Proces Ciągłego Doskonalenia