Znajdź inspirację i skuteczne narzędzia, które pomogą Ci w zarządzaniu projektami oraz zespołami. Nasze materiały dostarczą Ci wiedzy nie tylko na temat efektywnego planowania i realizacji zadań, ale także dotyczącej budowania silnych relacji w zespole.
Grooming w Agile – skąd się wzięło słowo, które Scrum porzucił w 2013 roku
“Grooming” brzmiało niewinnie – dopóki twórcy Scruma nie zmienili go oficjalnie na “refinement” w 2013 roku. Większość polskich zespołów IT wciąż używa starego słowa, nie zawsze wiedząc, co tak naprawdę kryje się za tą aktywnością. I czy w ogóle robią to dobrze.
Backlog spółki: ta sama nazwa, dwa zupełnie różne światy
Analitycy giełdowi mówią o backlogu Asseco wycenianym na 13,5 mld zł. Product Ownerzy mówią o backlogu w Jirze z 200 pozycjami, których połowa nie ma już sensu. To samo słowo, dwa zupełnie różne problemy i zadziwiająco rzadkie rozmowy między tymi dwoma światami.
CSF, czyli co tak naprawdę musi się udać
W 1979 roku John F. Rockart opublikował w Harvard Business Review artykuł, który miał rozwiązać jeden z klasycznych problemów zarządzania: skąd wiadomo, na czym naprawdę zależy sukces projektu. Czterdzieści kilka lat później większość organizacji wciąż odpowiada na to pytanie listą dwudziestu siedmiu punktów. CSF to coś innego niż KPI, coś innego niż lista ryzyk i coś innego niż cele strategiczne – choć wszystkie trzy lubią się z nim mylić.
CSF, czyli kilka rzeczy, których zawalenie położy cały projekt
W 1979 roku John Rockart opublikował w Harvard Business Review artykuł, który przez ponad cztery dekady będzie cytowany przez badaczy, project managerów i konsultantów na całym świecie. Nie dlatego, że był trudny, lecz dlatego, że opisał coś, co większość organizacji robiła źle, nie wiedząc nawet, że w ogóle to robi. CSF, czyli Critical Success Factors, to raczej nie kolejny framework do wdrożenia, lecz pytanie, na które wiele projektów IT nigdy nie znajdzie odpowiedzi na czas.
IT governance: kto naprawdę decyduje o technologii w twojej firmie
W 1996 roku ISACA opublikowała pierwszą wersję COBIT nie dla CIO ani architektów systemów, lecz dla audytorów finansowych, którzy nie mogli rozgryźć, kto właściwie odpowiada za decyzje technologiczne w dużych korporacjach. To chyba najuczciwsze wprowadzenie do tematu IT governance: zanim zapytasz, czym jest, zapytaj, dlaczego w ogóle powstało. I dlaczego większość firm odkrywa jego brak dopiero przy okazji jakiegoś spektakularnego fakapu.
Kamień milowy, czyli punkt na mapie, którego nikt nie widzi, dopóki projekt nie zaczyna się sypać
W harmonogramie wyglądają identycznie: data, nazwa, kolor w Jirze. Ale kamień milowy to albo punkt decyzji, który naprawdę coś zmienia, albo dekoracja, która pozwala raportować zielone statusy przy czerwonym projekcie. Fred Brooks opisał ten mechanizm w 1975 roku i od tamtej pory projekty IT wciąż popełniają ten sam błąd.
Proces iteracyjny: dlaczego najlepsze projekty IT wyglądają jak spirala, nie strzałka
Projekt IT zaplanowany od A do Z na samym początku brzmi jak marzenie każdego zarządu. Rzeczywistość wygląda jednak tak, że wymagania zmieniają się w trakcie pracy, a błędy odkryte po osiemnastu miesiącach kosztują wielokrotnie więcej niż te wykryte po dwóch tygodniach. Właśnie tu zaczyna się rozmowa o procesie iteracyjnym.
Trzy filary Scruma, które wszyscy znają i połowa zespołów ignoruje
Scrum Guide wymienia trzy filary, na których stoi cały framework: przezroczystość, inspekcja i adaptacja. Brzmią jak teoria, ale za każdym z nich kryje się konkretny mechanizm, który albo działa, albo sprawia, że sprint po sprincie coraz więcej się sypie. I wcale nie chodzi o brak ceremonii.
Backlog grooming: ceremonia, która w połowie zespołów istnieje tylko z nazwy
W 2005 roku Mike Cohn użył słowa „grooming” w kontekście backlogu i nikt nie podejrzewał, że stanie się to nazwą jednej z najbardziej zaniedbywanych ceremonii Scruma. W 2013 Scrum Guide zmienił nazwę na „refinement”, polska branża IT wzruszyła ramionami i używa obu. A tymczasem backlog rośnie.
Backlog produktu przykład: lista, która albo rządzi projektem, albo tylko zajmuje miejsce w Jirze
340 elementów w backlogu, połowa bez opisu, Sprint Planning trwa trzy godziny i nikt nie wie, skąd wzięła się pozycja numer 217. To nie jest wyjątek, to raczej standardowy wtorek w sporej części firm technologicznych. Backlog produktu jest albo najważniejszym narzędziem Product Ownera, albo listą, która zajmuje miejsce w Jirze.