Automaytczne KPI w Jira

Skoro już mamy wszystkie dane pod nosem, to można wprowadzić stare dobre performance management. Patrząc tylko i wyłącznie w Jira można wnioskować na prawo i lewo oraz porównywać i oceniać zespoły. Niektóre firmy . W tym miejscu chciałbym “podziękować” firmie Atlassian za wyświetlanie na raporcie Velocity szarych słupków jako Committment. Gdyby to było Planned versus Done to można by ten wykres traktować jako ważną informację na temat planowania. Teraz management wykorzystuje go jako bicz na zespół, bo przecież committment oznacza, że się “zobowiązaliście dowieźć”!.

Niektórym organizacjom nie wystarcza standardowy zbiór raportów i widoków Jira, więc idą krok dalej. Można doinstalować narzędzia analityczne takie jak eazyBI albo dopisać własne pluginy To jest zresztą doskonały argument do konieczności posiadania specjalnego zespołu od Jira. W ten sposób możemy zbudować przepiękny dashboard porównujący wszystkie zespoły w jednym widoku. W jednej z organizacji stworzono system KPI prosto w Jira i po zamknięciu Sprintu pojawiały się raporty typu traffic lights czyli Red Amber Green. Velocity musi rosnąć o 5% co Sprint. Ma być wzrost Velocity o 5%.Dokładność oszacowań może mieć najwyżej wahanie 10%. Czas w statusie to maksymalnie jeden dzień, czyli codziennie trzeba przesunąć gdzieś taska. Burndown musi być idealny, bo inaczej nie robicie dobrego Scruma. Jakie to ma efekty na ludziach? Zespoły bardzo szybko skupiają się na ograniu systemu i zbudowaniu alternatywnej rzeczywistości. Co jest mierzone jest natychmiast manipulowane.
A co z przejrzystością procesu? Gdzie jest transparentność postępów i możliwość reakcji na zmiany?

Komunikacja tylko przez Jira

Kiedy życie organizacji opiera się na issue w Jira, to cała komunikacja musi odbywać się właśnie tam. Nie mam czegoś napisanego w Jira? Nie istnieje. Nie było rozmowy. Jak to zrobić? Wpisz wszystko co wiesz w polu Opis (ang. Description). Wklej tam kilka stron z opisem wymagania i dodaj załączniki. W treści opisu możesz odnieść się do załączników. Na przykład, “Szczegóły na stroni 272 specyfikacji wymagań”. Skomponowanie idealnego opisu issue dużej ilości czasu i wysiłku. Trzeba zapewnić, żeby ludzie z tego korzystali. Zatem odsyłaj wszystkich, którzy zadają pytania do Jira. ”Przecież tam jest WSZYSTKO napisane!”. Z drugiej strony pojawi się siła o takim samym kierunku, ale przeciwnym zwrocie “Nie było napisane, to nie zrobiłem”.

Pojawia się też przekonanie, że jak tak już super dobrze wszystko się opisze, to nie trzeba rozmawiać. Cytat z open space: “Napisałam im w Jira. Mam jeszcze do nich przyjść? Po co?”. Rozmowa poza Jira staje się zagrożeniem. Teraz nie wiadomo, które ustalenia są wiążące. Co z tym możemy zrobić? Resztę można dodać w komentarzach. Właściwie każdą rozmowę można odbyć przez komentarze w Jira. Wszelkie ustalenia i zmiany koniecznie zapisuj w komentarzach. Teraz developer, żeby zrozumieć co jest do zrobienia musi przeczytać opis, przejść przez załączniki i sprawdzić historię komentarzy. Jeszcze jedno. Po co powielać informację raz napisaną. Linkuj inne issue mające jakikolwiek związek z tym issue i powołuj się na nie “ekran tak jak w RBS-1324 biorąc pod uwagę RBS-815. Workflow spójny z RBS-1012”.

Idąc dalej koordynację pracy w zespole też można oprzeć o Jira. Najlepiej jakby każdy miał zapewniony kawałek pracy dla siebie. I tak na przykład tylko tester może przesuwać elementy do Testing. Tylko inny niż przypisany developer może przesuwać rzeczy na Review.
A co z rozmową w cztery oczy? Czy przypadkiem nie tworzymy zbędnej dokumentacji i kontraktów na pracę w Jira?

Jira Driven Development

Niektóre zespoły z czasem zaczynają składać hołd bogowi Jiry. Wszystko co robimy musi być zgodne z tym jak Jira działa. Zaczyna się praca w podejściu Rozwój Sterowany Jirą, czyli po angielsku Jira Driven Development. Na przykład dodawanie zadań po starcie Sprintu powoduje to, że nie będą pojawiały się w raportach. Można usłyszeć „Nie możemy dodać tego do Sprintu, bo Jira nie wyświetli.” Zdarza się też argument „Nie możemy przenosić pomiędzy Sprintami, bo zepsuje się to w Jira”. “Nie możemy dodać defektów prosto do Sprintu, bo Jira to wyświetli w grupie pod wszystkimi swimlanes.” Narzędzie zaczyna zarządzać sposobem pracy w organizacji i wkrada się do umysłów zespołu.

Co jest na prawdę ważne? Czy mamy nową, nadającą się do wdrożenia wersję produktu? A co z wartością? Jaka jest wartość w trzymaniu się kurczowo Jiry? Co jest ważniejsze? Ludzie i ich interakcje czy procesy i narzędzia.

Podsumowanie

Bycie zajętym taskami to nie to samo, co bycie produktywnym i dostarczanie wartości.
Zacznij z najprostszym schematem i czystą Jirą.
Jira należy do zespołu.Pozwól zespołom eksperymentować i dostosowywać narzędzie. Jira nie zastępuje rozmowy w cztery oczy. Jira służy do zarządzania issue, a nie ludźmi. Skup się na zespołach, nie na poszczególnych ludziach. Agile to podejście empiryczne a nie predykcyjne, więc niemożliwe jest zaplanowanie 100% pracy, odpuść sobie. Jira to tylko narzędzie, które może przeszkadzać, albo pomagać. Opisane tutaj anty-wzorce można uzyskać przy użyciu innych narzędzi takich jak na przykład RedMine, Rally, VersionOne. Wiele zależy od Ciebie. Myśl o tym czego potrzebujesz a nie co jest możliwe do zrobienia w Jira.

Mały smaczek na zakończenie. Firma Atlassian, producent Jira przyznaje się otwarcie, że dla własnych potrzeb korzystają z karteczek papierowych na ścianie. A gdyby tak usunąć Jira?