K85.pl - Agile i takie tam sprawyPraktyczne porady, pomysły, eksperymenty dotyczące pracy z zespołami deweloperskimi, rozwijaniem produktów cyfrowych, warsztaty, historyjki użytkownika i duuużo więcej :)
Widzisz problemy w swoim zespole, ale każda Twoja próba ich rozwiązania kończy się porażką? Zaczyna Cię to frustrować, bo widzisz ewidentną potrzebę zrobienia retrospektywy, ale zdaje się, że nikt inny tego nie rozumie? I co teraz? Jak ich przekonać? W tym artykule przedstawimy Ci kilka wskazówek, które pomogą przekonać zespół do robienia retrospektywy (praktyki, pomagającej zespołom IT wprowadzać wiele usprawnień).
Agile zatacza coraz szersze kręgi. Zwinnych praktyk jest całe mnóstwo i mogą pasować do wielu inicjatyw – tam gdzie mamy do czynienia z projektami, z zespołową pracą, planowaniem itp. Już nie tylko zespoły typowo deweloperskie chcą być zwinne, ale także HR, marketing i inne. Razem z Agnieszką, mieliśmy okazję przeprowadzić szkolenie w firmie AirHelp, w której wówczas wspólnie pracowaliśmy, dla działu HR właśnie. W tym poście piszemy o tym jak takie szkolenie wyglądało i co wg naszych doświadczeń może przydać się takiemu zespołowi.
Czy zgodzisz się ze stwierdzeniem, że gdy pracownicy identyfikują się ze swoimi kolegami, zespołem, produktem, to ich praca jest łatwiejsza, przynosi lepsze efekty? Ja tak 🙂 Zatem jak ułatwić taką identyfikację, zespołowi? Możemy pomóc mu wytworzyć artefakt, w postaci zespołowego logo. Rzecz, która będzie wizualną manifestacją wartości i relacji, łączących tę grupę ludzi.
Bugi to naturalna sprawa. Niestety, nie da się ich całkowicie uniknąć. Czasami możemy mieć proces pierwszej klasy i produkować ich ledwie ociupinkę, ale najczęściej jednak produkujemy ich trochę więcej 😎 Każdy zespół ma swoje podejście do tego jak radzić sobie z błędami, gdy zostaną odkryte. Najczęściej nie ekscytują one programistów. Product Ownera czy Project Managera też nie. Raczej lądują w grupie “katorga”. Dużo rzadziej ktoś powie “ale wspaniały błąd, chcę to naprawiać” 🤪 Od tego już mały krok, aby zacząć je skrupulatnie kolekcjonować w backlogu i… zaczyna nam rosnąć niezły bałagan 😮
Wizualizacja to jest to! Pisałem już o tym kilkukrotnie – np. w poście o planowaniu kwartałów oraz w poście o historyjkach użytkownika. Można ją wykorzystać także w trakcie planowania Sprintu! Taki zabieg pomaga przygotować sobie grunt pod udany przebieg :)
Krótkie i wyraziste zdania mają siłę. Długie i rozbudowane nas usypiają. Skoro tak, to jak podejść do opisów projektów, historyjek użytkownika itp.?