Podstawy zwinnego zarządzania wytwarzaniem produktów Flashcards
Zasady Programowania Zwinnego
- Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania
- Bądźcie gotowi na zmiany wymagań
nawet na późnym etapie jego rozwoju.
Procesy zwinne wykorzystują zmiany
dla zapewnienia klientowi konkurencyjności - Dostarczajcie funkcjonujące oprogramowanie często,
w kilkutygodniowych lub kilkumiesięcznych odstępach, im częściej, tym lepiej - Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania
projektu
Zasady programowania zwinnego c.d
- Twórzcie projekty wokół zmotywowanych ludzi.
- Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że
wykonają powierzone zadanie. - Najbardziej efektywnym i wydajnym sposobem przekazywania
informacji zespołowi deweloperskiemu i wewnątrz niego jest
rozmowa twarzą w twarz - Działające oprogramowanie jest podstawową miarą postępu.
Zasady programowania zwinnego c.d 2
Procesy zwinne umożliwiają zrównoważony rozwój.
Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie
utrzymywać równe tempo pracy.
Ciągłe skupienie na technicznej doskonałości i dobrym
projektowaniu zwiększa zwinność.
Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.
Zasady programowania zwinnego c.d 3
Najlepsze rozwiązania architektoniczne, wymagania i projekty
pochodzą od samoorganizujących się zespołów.
W regularnych odstępach czasu zespół analizuje możliwości
poprawy swojej wydajności, a następnie dostraja i dostosowuje
swoje działania do wyciągniętych wniosków.
Jak myślisz, kto najlepiej wskaże/zdefiniuje wartość twojego produktu?
Klient/użytkownik
Każda organizacja ma swój cel istnienia i uprośćmy, że dla firmy prywatnej będzie to zysk. Tak definiowany sukces kieruje nas ku satysfakcji klientów - odbiorców, którym dedykujemy produkt bądź usługę, jako podstawowej miary sukcesu.
Zatem definicja czym jest wartość oferowanego produktu leży w gestii jego użytkowników.
Co mamy na myśli mówiąc o dbałości o zadowolenie klienta w zwinnym środowisku wytwarzania oprogramowania?
- Wczesne osiąganie oczekiwanej wartości
- Regularne wdrażanie oprogramowania
Zgodnie z 1. zasadą manifestu Agile najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania. “Zwinnie” oznacza dążenie do wczesnego zbudowania wartości i nabudowywania kolejnych jej przyrostów, dzięki czemu utrzymujemy zadowolenie klienta na wysokim poziomie.
Co w zwinnym środowisku wytwarzania oprogramowania oznacza zmiana w późnym etapie rozwoju?
Niemal tyle, co gdyby jej potrzebę odkryto w początkowym stadium
Podejście zwinne wskazuje, że klient odkrywa, czego chce w miarę jak produkt powstaje. Oznacza to, że zmiany są nieuniknione, a gotowość na nie oznacza zadowolenie klienta, gdyż daje mu przewagę konkurencyjną. Gotowość ta wynika z faktu, iż proces wytwórczy jest podzielony na etapy, w których od razu zawiera się projektowanie, implementacja i testowanie. Koszt późniejszej zmiany jest dużo niższy, niż w podejściu kaskadowym, gdzie wymaga powtarzania wcześniejszych kroków. Patrz: Zasada 2. manifestu Agile
Klient proponuje, by spotkać się w “połowie projektu” i sprawdzić postępy. Co odpowiadasz?
Sugerujemy częściej i regularnie. Spotkajmy się za 2 tygodnie, powtórzmy to 2-3 razy w takim odstępie i sprawdźmy, czy taki tryb jest wartościowy.
Odwołaj się do 3. zasady manifestu Agile, która mówi o dostarczaniu funkcjonującego oprogramowania często, w kilkutygodniowych odstępach. Celem jest budowanie okazji do regularnego feedbacku postępów, dzielenia się informacjami ze zmiennego otoczenia biznesowego i finalnie do ataptacji kolejnych kroków. Obecnie odstępy te to często 1-2 tygodnie.
Które aspekty należy wziąć pod uwagę chcąc zbudować zespół pod zwinny proces wytwórczy?
- różnorodność kompetencji
- zdefiniowane role (np. osoby decydującej o kolejności rozwoju produktu)
- jasny, precyzyjny i mierzalny cel biznesowy
5 zasada manifestu Agile mówi o zmotywowanych ludziach, jako kluczu do sukcesu. Oznacza to zapewnienie zespołowi środowiska, które nie będzie ich demotywowało np. brakiem niezbędnych umiejętności, brakiem decyzyjności czy brakiem celowości
Co zaproponujesz nowemu klientowi twojego software house’u jako początek współpracy z zespołem deweloperskim?
Spotkanie na którym opowie o potrzebie i oczekiwaniach
Najefektywniejszym i najwydajniejszym sposobem przekazywania informacji jest bezpośrednia rozmowa. Można się przy tym wspierać dokumentacją i wizualizacją, jednak elementem niezbędnym w podejściu zwinnym jest budowanie relacji opartej na dialogu i wymianie myśli, w celu lepszego zrozumienia (patrz zasada 6. Manifestu Agile)
Pytasz lidera obszaru produktowego, jak mierzy postęp prac nad wytwarzanym oprogramowaniem. Która odpowiedź świadczy o zwinności podejścia?
Gdy spotykamy się (biznes z zespołem deweloperskim) to oglądamy działające oprogramowanie i na tej podstawie dyskutujemy, co dalej
Podstawową miarą postępu jest działające oprogramowanie (patrz. zasada siódma manifestu agile). Chcemy mieć pewność, że tak samo rozumiemy (biznes i zespół wytwórczy) aktualny stan. Dodatkowo warto posiłkować się innymi miarami, by dyskutować najlepsze kolejne kroki rozwoju produktu.
Założenia Manifestu
- Najwyższy priorytet ma dla nas zadowolenie klienta
dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania. - Bądźcie gotowi na zmiany wymagań
nawet na późnym etapie jego rozwoju.
Procesy zwinne wykorzystują zmiany
dla zapewnienia klientowi konkurencyjności - Dostarczajcie funkcjonujące oprogramowanie często,
w kilkutygodniowych lub kilkumiesięcznych odstępach.
Im częściej, tym lepiej. - Zespoły biznesowe i deweloperskie muszą ściśle ze sobą
współpracować w codziennej pracy przez cały czas trwania projektu. - Twórzcie projekty wokół zmotywowanych ludzi.
Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie,
że wykonają powierzone zadanie. - Najbardziej efektywnym i wydajnym sposobem przekazywania
informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz. - Działające oprogramowanie jest podstawową miarą postępu.
- Procesy zwinne umożliwiają zrównoważony rozwój.
Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie
utrzymywać równe tempo pracy. - Ciągłe skupienie na technicznej doskonałości i dobrym
projektowaniu zwiększa zwinność. - Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.
- Najlepsze rozwiązania architektoniczne, wymagania i projekty
pochodzą od samoorganizujących się zespołów. - W regularnych odstępach czasu zespół analizuje
możliwości poprawy swojej wydajności,
a następnie dostraja i dostosowuje
swoje działania do wyciągniętych wniosków
Zwinność
to nieustanne zapewnienie satysfakcji klienta (użytkownika), poprzez zdolność do reagowania na wszelkie zmiany – od priorytetów, do warunków rynkowych.
Oznacza to osiąganie sukcesu
(biznesowego) dzięki:
- wysokiej produktywności (wczesne i regularne dostarczanie wartości, definiowanej przez
klienta) i - jakości dostarczanych rozwiązań (klient wraca, jest zadowolony z braku błędów; zyskujemy
nowych klientów).
Zwinność to innymi słowy organizacja zwinna pracuje w systemie adaptacyjnym. Adaptuje się do potrzeb, czy
zmian rynkowych zarówno wprowadzając zmiany w produkcie, jak i w procesie. Elastyczność i responsywność oznacza inwestycję w:
Pracę zespołową – tworzenie międzyfunkcyjnych zespołów pracujących z krótką pętlą informacji zwrotnej od klienta/użytkownika.
Proces wytwórczy nie podzielony na fazy według kompetencji (analiza, programowanie, testowanie), a ciągłe zapętlenie wszystkich tych kroków w małych iteracjach (1-4 tygodnie). Przy
tym każda kończących się przyrostem wartości w postaci stale działającego oprogramowania.
Nieustanne usprawnianie wszystkich elementów procesu wytwórczego, ze skupieniem na
efektywnym dostarczaniu wartości klientowi.
Pierwszy wymiar (stopień niepewności)
opisuje skala od blisko pewności do daleko od pewności. Zagadnienia z początku skali charakteryzuje znane połączenie przyczynowo-skutkowe. Najczęściej dotyczy to spraw, z którymi mieliśmy już do czynienia wcześniej. Korzystając z doświadczenia
możemy przewidzieć wynik podejmowanej akcji z dużą pewnością. Zagadnienia z drugiego końca
skali charakteryzuje unikalny charakter zdarzenia (w ogóle lub dla osoby podejmującej decyzję).
Ciąg przyczynowo-skutkowy jest nieznany i bazowanie na doświadczeniu nie pomoże. Drugi wymiar
(skala wertykalna, stopień porozumienia) jest związany z poziomem zgodności co do decyzji. Dotyczy
spraw dotykających daną grupę ludzie, zespół, czy całą organizację.
Blisko zgodności i blisko pewności
W takim systemie korzystamy z gromadzenia danych z przeszłości, by użyć ich do prognozowania przyszłości. Planujemy konkretne kroki i akcje by osiągnąć oczekiwane rezultaty. Monitorujemy postępy w celu porównania z założonym planem.
W tej domenie celem jest powtarzalność gwarantująca wzrost produktywności.
Daleko od zgodności, a blisko pewności
W takim systemie mamy do czynienia z dużą pewnością jak osiągać dane wyniki, jednak brakuje
jasności, które z nich są najbardziej pożądane. Plan traci znaczenie, ważniejsze stają się negocjacje, koalicje i szukanie kompromisów, by wyznaczyć kierunek działania. W tej domenie najczęściej odnajdujemy politykę.
Blisko zgodności, a daleko pewności (wysoka niepewność)
W takim systemie mamy do czynienia z wysokim poczuciem zgodności, przy braku jasności co
do ciągu przyczynowo-skutkowego. W tym wypadku dokładne planowanie jest zastępowane
poczuciem wspólnej wizji i misji, a realne postępy weryfikowane względem nich. Nie jesteśmy
w stanie określić dokładnej ścieżki kolejnych kroków, za to celem jest podążanie w kierunku
wcześniej określonego stanu. W tej domenie bazujemy na logice i ocenie względem idei.
Daleko od zgodności i daleko od pewności – anarchia, chaos
Wysoki poziom niezgody i niepewności prowadzi często do zachowań anarchicznych. Plany, wizje, czy negocjacje nie są wystarczająco determinujące dla decyzji. W tej domenie, w krótkiej
perspektywie może zadziałać unikanie, które w długiej będzie destrukcyjne.
Domena złożona, nazywana też niekiedy granicą chaosu
znajduje się pomiędzy anarchią, a obszarami tradycyjnego zarządzania. Skuteczność działania i podejmowania decyzji zapewnia tu kreatywność, innowacyjność, podejście empiryczne polegające na eksperymentowaniu i doświadczaniu. Deterministyczne modele przewidywania7 oparte na wcześniejszych doświadczeniach i danych tracą tu
na swojej skuteczności, gdyż pojawia się zbyt wiele różnych od siebie kontekstów.
Domena chaotyczna (Chaos) – wiadome jest bardzo niewiele
Jest to system, który na matrycy Stacey’ego cechował wysoki poziom niezgodności (braku porozumienia) i niepewności. Nie działają tu tradycyjne metody zarządzania – za mało wiemy, za mało
rozumiemy. Unikanie działania odsuwa jedynie w czasie blokadę decyzyjną.
Najlepszym zachowaniem jest funkcjonowanie według schematu: działaj – odczuwaj – reaguj
(act – sense – respond). Działanie jest intuicyjne i oparte na reagowaniu na zmiany, które się pojawią
w następstwie naszego działania. Praktyki dopiero się pojawiają. Przykładem systemu opartego na
takim schemacie podejmowania decyzji są inicjatywy startupowe w pierwszym okresie funkcjonowania, gdzie następuje eksploracja zarówno w sensie produktu, jak i procesów.
Domena złożona (Complex) – więcej jest niewiadomych, niż wiadomych.
W sytuacji, w której niewiadome przewyższają wiadome zarówno w aspekcie technologicznym, jak
i oczekiwań, mamy do czynienia ze złożonością. Należy przy tym pamiętać, że niepewność wynika
z dużej ilości zmiennych w czasie kontekstów – ludzie zdobywają doświadczenie i wiedzę, zmienia się
skład zespołów, zmieni się otoczenie biznesowe, etc. Cechuje ją to, że ten sam efekt końcowy będzie
osiągnięty za każdym kolejnym podejściem w inny sposób, gdyż zmieni się choć jeden z kontekstów.
W tej domenie systemy naturalne radzą sobie samoorganizacją – mniej wymuszonego porządku,
wystarczają znane i jasne ramy oraz atraktory do działania.
Zatem sugerowanym sposobem funkcjonowania w biznesie jest eksperymentowanie: zbadaj
(próbkuj) – odczuwaj – reaguj (ang. probe – sense – respond). Oznacza ono umiejętność ustalenia ram eksperymentu i nazwanego celu, a zatem umiejętność interpretacji wyników.
Przykładem systemu opartego na takim schemacie podejmowania decyzji jest większość organizacji
IT tworzących oprogramowanie.
Domena skomplikowana (Complicated) – więcej wiemy niż nie wiemy.
System w tej domenie cechuje możliwość zarządzania ograniczeniami, gdyż je znamy i rozumiemy.
Mamy tu do czynienia z niską niepewnością technologiczną, bądź jasnością zrozumienia co do wymagań. Potrafimy nazwać dobre praktyki, praca ekspertów domenowych jest skuteczna i efektywna.
Domena prosta (Simple, Obvious) – wszystko jest znane.
W sytuacji niskiej niepewności (technologicznej) i wysokiego porozumienia (co do wymagań i rezultatu)
mamy do czynienia z systemem prostym. Analizując problem/zadanie jesteśmy w stanie je skategoryzować w celu zastosowania najlepszych, znanych nam i wykorzystane już wcześniej praktyki.
podejście kaskadowe
Cechuje się ono:
* Planowaniem detalicznym i życzeniowym, opartym o zadania (czynności).
* Wiarygodnością planu zależną od skali przedsięwzięcia.
* Wysokimi kosztami związanymi z przygotowanie i utrzymanie planu.
* Kosztownymi odstępstwami od planu.
* Zdefiniowanymi i powtarzalnymi procesami.
* Silnie wyodrębnioną fazą produkcji (implementacji).
* Strukturą organizacji sprzyjającą powstawaniu silosów kompetencyjnych.
DevOps
Kluczowym aspektem jest położenie nacisku na jakość u źródła, czyli w zespołach wytwórczych.
Oznacza to poszerzenie kompetencji i odpowiedzialności zespołu oraz maksymalnie krótkie informacje zwrotne co do jakości wprowadzanych zmian w produkcie poprzez wsparcie technologiczne (automatyzacja, wizualizacja).
Podejście DevOps to technologiczna forma realizacji zwinnego zrywania z silosami kompetencyjnymi,
w celu zwiększenia jakości wytwarzanych produktów, dbania o zadowolenie klienta i wczesne dostarczanie wartości biznesowej. Praktyki DevOps mocno czerpią z XP w domenie inżynierskiej i z Lean
w domenie procesu, wprowadzając element automatyzacji i samoobsługi (self-service: brak zależności i czasu oczekiwania etc.). Bazują na wielu, częstych pomiarach i transparencji wyników.
Samoorganizacja
to proces, w którym struktura albo wzorzec działania (proces) pojawiają się w systemie
bez centralnego sterowania, czy zewnętrznego elementu narzucającego je za pomocą planowania. Stanowi ona normę w systemach złożonych: od atomów, cząsteczek, gatunków, po przedsiębiorstwa.
Najważniejszymi składowymi wspierającymi samoorganizację w kierunku efektywnego tworzenia
oprogramowania są:
* z punktu widzenia struktury:
− zespołowość (nie indywidualizm) i
− przywództwo (nie zarządzanie),
− role (nie stanowiska);
Najważniejszymi składowymi wspierającymi samoorganizację w kierunku efektywnego tworzenia
oprogramowania są:
z punktu widzenia wzorców działania:
− procesy adaptacyjne,
− zasady (nie reguły),
− poczuć i reagować (zamiast przewidzieć i zaplanować).
Dowodzenie i kontrola
- kontrola przełożonego
- informacje płyną od pracowników do
przełożonego - polecenia i decyzje płyną od przełożonego do pracowników
- wykorzystanie reguł dla utrzymania
zgodności i powstrzymywania
Dowodzenie i kontrola
Ograniczenia systemu:
- reguły
- wyszczególnione, indywidualne odpowiedzialności
- dokładne opisy stanowisk pracy
Dowodzenie i kontrola
Komunikacja między zespołami:
- koordynacja to zadanie wybranej osoby
(często managera projektu) - często połączona z funkcyjnym podziałem zespołów (ograniczona odpowiedzialność za wycinek procesu wytwórczego).
Samoorganizacja
samoregulacja wewnątrz zespoły
* kontrola na bazie przejrzystości i dostępu do informacji
* presja współpracowników
* jasne, zrozumiałe i współdzielone zasady
Samoorganizacja
Ograniczania systemu:
przejrzystość
* zasady
* role
* współdzielone cele
Samoorganizacja
Komunikacja między zespołami:
koordynacja jest jednym z działań zespołu zarówno wewnątrz (pełna odpowiedzialność za wartość), jak i na zewnątrz zespołu (współpraca przy produkcie).
Zarządzanie oparte na dowodach (evidence-based management)
polega na podejmowaniu decyzji
przy świadomym, zdecydowanym i rozsądnym użyciu czterech źródeł informacji. Są nimi ekspertyza
i ocena praktyków, dowód z lokalnego przykładu (kontekstu), krytyczna ocena najlepszych dostępnych dowodów badawczych i perspektywy osób, których może dotyczyć decyzja.
PDCA
Pod akronimem “PDCA” kryje się opracowana przez Edwarda Deminga metoda podejścia do wdrażania zaplanowanych działań. Cykl Deminga zakłada eksperymentowanie w myśl powiedzenia „kto
nie sieje ten nie zbiera”. Metoda ta składa się z cyklu 4 kroków, podczas których weryfikowana jest
postawiona hipoteza.
Etapy cyklu „PDCA” to:
* Plan (zaplanuj) – Etap stawiania hipotezy. Należy precyzyjnie określić plan działania (co chcemy
zrobić), nakreślić cele i przedstawić spodziewane rezultaty (co spodziewamy się osiągnąć).
* Do (zrób) – test postawionej hipotezy. Należy wdrożyć zaplanowane działania, po czym poddać
proces dokładnym obserwacjom, a zebrane dane dokładnie przeanalizować.
* Check (sprawdź) – porównanie faktycznych wyników uzyskanych przy testowaniu postawionej
hipotezy, ze spodziewanymi rezultatami.
* Act (działaj) – jeżeli nie osiągnięto zakładanych rezultatów rozpocznij cykl od nowa. Zweryfikuj
plan, założone cele i sposób działania. Wprowadź do niego niezbędne poprawki. Przetestuj hipotezę i porównaj wyniki. Jeżeli okaże się, że założenia zostały spełnione należy zadziałać w kierunku utrzymania opracowanego rozwiązania – np. opracować standardy do praktyk będących
wynikiem cyklu.
Przejrzystość
stanowi fundament empirycznej kontroli procesu – wiedza, którą posiadamy, oraz
decyzje, które podejmujemy, wynikają z naszych doświadczeń. Przejrzystość oznacza, że wszystkie
aspekty związane z naszą pracą są widoczne, dostępne oraz tak samo zrozumiałe dla wszystkich
zaangażowanych. Umożliwia tym samym stosowanie dwóch kroków empirycznej kontroli procesu:
inspekcji i adaptacji.
Inspekcja
krok poddawania kontroli postępów pracy i procesu, by wykryć ewentualne odchylenia
od oczekiwań i problemów. Inspekcja umożliwia adaptację. Inspekcja bez adaptacji jest uznawana
za bezcelową.
Adaptacja
jeśli jakikolwiek jego aspekt wykracza poza dopuszczalne limity lub jeśli uzyskany
produkt jest niemożliwy do zaakceptowania (co wykryliśmy w wyniku inspekcji) – stosowany proces
lub wytwarzane materiały należy odpowiednio skorygować. Zmian tych należy dokonać jak najszybciej, aby zminimalizować dalsze odstępstwa.
Organizacje czerwone
oparte na silnej władzy, bezwzględnym posłuszeństwie i strachu,
których celem jest przetrwanie w chaotycznym i niebezpiecznym środowisku,
− przykłady: gang, mafia,
− metafora: wataha wilków.
Organizacje bursztynowe
zhierarchizowane, oparte na wyraźnych formalnych rolach
i odgórnych dyrektywach, czy rygorystycznych regułach, nastawione na stabilność przez budowanie przyszłości powtarzaniem przeszłości,
− przykłady: kościół katolicki, publiczne systemy szkolne, agencje rządowe,
− metafora: wojsko.
Organizacje pomarańczowe
oparte na rywalizacji i zwiększaniu produktywności, podporządkowane idei zysku, celem jest pokonanie konkurencji, a drogą do celu innowacyjność,
swoboda w zakresie wyboru strategii i narzędzi realizacji narzuconych celów,
− przykłady: międzynarodowe korporacje, szkoły niepubliczne,
− metafora: maszyna.
Organizacje zielone
skupione na kulturze pracy, oparte na idei wzmacniania i dobrych
relacjach, podważanie hierarchii i formalnych ról, nastawione na interesariuszy,
− przykłady: organizacje pozarządowe, organizacje o kulturze opartej na wartościach
(np. Southwestern Airlines)
− metafora: rodzina
Organizacje turkusowe
oparte na autonomii, pełni i realizacji ewolucyjnie donośnych celów. Nie ma tu hierarchii ani określonej centrali zarządzającej. Każdy bierze odpowiedzialność
za siebie i za organizację, która stanowi żywą całość zorientowaną na realizację swojego
potencjału. Elastyczne reagowania jako odpowiedź na złożoność,
− przykłady: firmy „nowej generacji” (np. BSO/Origin – konsulting IT, czy Sounds True
– media),
− metafora: żywy organizm.
matryca pojemności
powstał na poziomie
strategicznym (portfolio) – obrazował inicjatywy biznesowe, w których wartość dokładały ww. zespoły, a którymi zarządzało grono Product Managerów. Narzędzie w postaci matrycy w ogólnodostępnym środowisku skupiało się na sprawdzaniu pojemności przerobowych zespołów w porównaniu
z potrzebami biznesowymi i idącym za nimi obciążeniem. Wizualizacji była aktualizowana na bieżąco
i grono Product Managerów oraz przedstawicieli każdego z zespołów spotykało się raz w tygodniu,
by przyjrzeć się sytuacji.
matryca planowania
dotyczył poziomu taktycznego (program). Obrazował koordynację pracy zespołów na poziomie najbliższych Sprintów (horyzont trzech miesięcy). Ponownie wykorzystano ogólnodostępną matrycę i regularne jej przeglądy
– jak nietrudno się domyśleć, tygodniowe i dzień przed spotkaniem przy poprzedniej wizualizacji.
Tym razem kolumny obrazowały czas – przypomnę: zespoły pracowały w dwutygodniowych iteracjach i taki okres czasu przyjmowały jako podstawy planowania. Kolory wykorzystano do wskazywania pracy nad tą samą wartością produkty (np. funcjonalnością). Zakres prac mógł rzecz jasna wykraczać poza jeden Sprint, dlatego tablica przypominała poukładane klocki. Pierwsza kolumna oznaczała zawsze aktualny tydzień, zatem im dalej na osi czasu, tym więcej zmian, na które można było
reagować. Reakcje na tym poziomie (taktycznym) miały wpływ na wizualizację ryzyk (docelowo:
minimalizowaniu ich występowania) na poziomie strategicznym.
klientocentryczność,
czyli niemal obsesyjne dążenie do umiejętnego zdefiniowania wartości i optymalizowanie procesu pod jej wczesne (nie szybsze!) dostarczanie
