Idź do:
Data pierwszej publikacji: 09.09.2020
Ostatnia aktualizacja: 06.09.2023
Po pierwsze: transparencja, czyli przejrzystość
Dotyczy to wszystkich elementów, procesów i postaw.
- Backlog Produktu musi być przejrzysty i znany wszystkim członkom Zespołu.
- Musi być dostępny dla wszystkich zainteresowanych.
- Musi być jeden, wspólny dla nas i dla klienta.
Bo w Scrumie podstawą jest relacja oparta na zaufaniu i dobrych intencjach. Jesteśmy szczerzy w relacji ze sobą i z klientem. Także w tych trudnych chwilach. Postęp naszych prac jest mierzalny i widoczny dla wszystkich zainteresowanych. Problemy komunikujemy jasno, ale oczekujemy też jasnych wymagań. Precyzyjnych celi i znajomości kontekstu.
Bez wiarygodnych danych „wejściowych” nie będziemy w stanie spełnić oczekiwań. Nie będziemy też w stanie rzetelnie ocenić procesu, którego częścią jesteśmy.
Transparentność oznacza też, że wszyscy członkowie zespołu muszą porozumiewać się wspólnym językiem. Terminologia nie może pozostawiać miejsca na domysły. Ważne jest także, aby na różnych poziomach procesu istniała wspólna płaszczyzna komunikacji.
Jednym ze zdarzeń w Scrumie, gdzie transparentność ma najwyższe znaczenie, jest Retrospektywa Sprintu. To właśnie podczas tego spotkania powinniśmy powiedzieć sobie wszystko.
Za każdym razem, kiedy z różnych powodów milczymy o problemach, odbieramy Zespołowi szansę, by się rozwijać.
Transparentność jest wartością, nad którą trzeba pracować na każdym poziomie organizacji. Od relacji w Zespole, z Managementem, jak również z klientem.
Jednym z podstawowych aspektów budowania kultury przejrzystości jest otwartość na porażkę. Próby i błędy są naturalnym elementem procesu uczenia. Dopiero wtedy mamy szansę działać w oparciu o to jak jest, a nie o to, jak nam się wydaje, że jest. Lub jeszcze gorzej, jak byśmy chcieli, żeby było.
Po drugie: inspekcja
W swoich założeniach Scrum opiera się na obserwacji. Na każdym poziomie i na każdym kroku zastanawiamy się, jak działamy. Taka refleksja powinna dotyczyć wszystkich i towarzyszyć nam każdego dnia.
Regularnie mierzymy prędkość i efektywność. Weryfikujemy, czy Backlog jest czytelny. Weryfikujemy Przyrost produktu (Increment) i jego zgodność z wymaganiami. Czy Sprint przebiega w równym tempie i nie ma przeszkód na horyzoncie, które mogą zablokować realizację celu. Zastanawiamy się nad tym, co nam pomaga, a co przeszkadza.
Szukamy wąskich gardeł w procesie. Pamiętamy, że łańcuch jest tak słaby, jak najsłabsze jego ogniwo. Tak samo z procesami. Tylko usprawnienie najsłabszego elementu, usunięcie realnej przeszkody, ma szanse przynieść wymierne korzyści.
Niezwykle ważne jest to, że inspekcja jest życzliwa. Nie ma na celu wytykania słabości, ale identyfikację obszarów do wzmocnienia. Pozwala szybko wykryć niezgodność wymagań. Inspekcja nie jest w Scrumie rozumiana jako narzędzie kontroli czy represji. Jest narzędziem umożliwiającym zmianę. A tylko poprzez zmianę możliwy jest rozwój.
I po trzecie: adaptacja
Adaptacja to wszystkie działania usprawniające proces. Od zmiany formuły stand-upu, przez pracę nad Backlogiem po nowe narzędzia deweloperskie. Adaptacja jest kluczem do rozwoju.
Dla mnie adaptacja to umiejętność szybkiej diagnozy i wprowadzenia zmian, które są podyktowane zmieniającymi się warunkami projektowymi lub wynikają z przeprowadzonej inspekcji.
Są dwa podstawowe błędy w implementacji Scruma. Adaptacja bez przeprowadzenia rzetelnej inspekcji lub, co w moim odczuciu gorsze, przystępowanie do inspekcji, po której nie następuje adaptacja.
W pierwszym przypadku zmiany mogą być chaotyczne i nie odpowiadać realnym potrzebom. W drugim pozostaje poczucie zmarnowanej szansy na rozwój.
Podsumowanie
Scrum działa nie dlatego, że ma trzy role, pięć zdarzeń i trzy artefakty, ale dlatego, że jest oparty na empiryzmie, którego wyrażeniem są trzy powyższe filary. Oznacza to proces oparty na faktach, doświadczeniu i dowodach, w którym postęp opiera się na obserwacjach rzeczywistości, a nie na fikcyjnych planach.
