Tag: transparencja

Jak dawać feedback?

Długi czas nienawidziłam sesji feedbackowych. Kojarzyły mi się z przymusową torturą. Już jako konsultant starałam się ich unikać. To przekonanie było wynikiem kilku źle przeprowadzonych sesji w których uczestniczyłam. Aż pewnego razu, w wyjątkowo trudnych dla mojej firmy warunkach, Filip Czapeczka przeprowadził dla nas naprawdę dobrą sesję. Od tego czasu komunikacja w naszej firmie osiągnęła niespotykanie wysoki poziom, który utrzymuje się do tej pory.

Continue reading

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!

Scrum Guide Wytłumaczony – Część 5

preco

Przejrzystość

Słownik i dostęp do informacji

Wszystkie istotne aspekty procesu muszą być widoczne dla osób odpowiedzialnych za osiągane rezultaty. Reguła przejrzystości wymaga, by te aspekty były opisane dla osób zaangażowanych jasnymi standardami, tak by wszyscy obserwatorzy tak samo rozumieli to, co obserwują.

Przykładowo:

  • uczestnicy danego procesu muszą posługiwać się wspólnym nazewnictwem elementów tego procesu,
  • osoby wykonujące pracę i osoby akceptujące wyniki tej pracy muszą posługiwać się wspólną definicją „Ukończonej” pracy.

Tym razem weźmy na warsztat przejrzystość, czyli to, co stoi u podstaw wszelakiej komunikacji, artefaktów czy zdarzeń w Scrumie. Mówi się o niej zdecydowanie za mało.  Czym w takim razie jest przejrzystość? Otóż przejrzystość ma dwa główne aspekty: słownik i dostęp do informacji.

Continue reading

Mentorka o niezwykłej charyzmie. Jeden z najbardziej doświadczonych ekspertów Scruma i pierwszy trener Scaled Professional Scrum w Polsce.

Co to jest Scrum i inne podstawowe pojęcia – Scrum Guide Wytłumaczony – część 1

pablo (1)

Scrum (rzecz.): ramy postępowania (ang. framework), dzięki którym ludzie mogą z powodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości. 

Wartość

Scrum to sposób wytwarzania produktów, o możliwie największej wartości.

Zacznijmy od najważniejszego.

Scrum to sposób wytwarzania produktów, o możliwie największej wartości.

Weźmy mój ulubiony przykład: rower.

Po co ludzie kupują rowery? Dla oszczędności. Albo dla lansu. Albo dla zdrowia. Jest pewnie jeszcze kilka powodów. I to jest właśnie wartość – spełnienie potrzeby użytkownika końcowego. Ktoś może teraz zapytać – a czemu nie sponsora? Jeśli rodzic kupi dziecku rower, to rodzic ma święty spokój, a nie dziecko. Jasne – odpowiem – ale jeśli dziecku rower się nie spodoba, bo na przykład nie będzie miał „lansu” i będzie „żal.pl”, to rodzic nie będzie miał spokoju. Więc nawet sponsor musi się zatroszczyć o spełnienie potrzeb użytkownika końcowego.

Przyjrzyjmy się też cenie. Ktoś może powiedzieć, że cena jest kolejnym składnikiem wartości. Otóż – jest drugą stroną tej samej monety. Cena to to, co płacimy, a wartość to to, co za nią otrzymujemy. Czy natomiast jest to dobra wartość za tę cenę, to już inna bajka. Continue reading

Mentorka o niezwykłej charyzmie. Jeden z najbardziej doświadczonych ekspertów Scruma i pierwszy trener Scaled Professional Scrum w Polsce.

Po co nam dobry Product Backlog?

Po co nam dobry Product Backlog?

W Scrumie za jakość odpowiada zespół deweloperski.

Dobre i złe strony równouprawnienia.

Własnie tak. Dobrze czytacie. Zespół. Nie manager. Nie Produkt Owner. Nie Scrum Master.Zespół deweloperski. Czas zdjąć koronę niewiniątek z tych na dnie łańcucha pokarmowego i przyjąć zarówno dobre i złe strony równouprawnienia.

Dobre?

  • Decyzyjność. To zespół decyduje jak wykonane zostanie rozwiązanie i nikt nie ma prawa się w te decyzje wtrącać. Dzięki pracom Dana Pinka opisanym w jednym z moich poprzednich artykułów (klik) wiemy że jest to coś krytycznego dla naszej motywacji.
  • Profesjonalizm. Zespół już nie jest tylko wykonawcą czyiś poleceń, tworzy autonomiczną samo-zarządzającą jednostkę. Mini firmę, która jako jedyna jest w stanie stworzyć inkrement.
  • Szacunek. Jeżeli oba powyższe udało się osiągnąć szacunek pojawi się jako konsekwencja.

Złe?

  • Za te wszystkie decyzje które od teraz podejmuje zespół trzeba wziąć odpowiedzialność. Co to znaczy? To znaczy że zespół chyli głowy jeżeli coś z jakością jest nie tak. To zespół mówi w jakim czasie da się to naprawić. To zespół dba o to żeby mieć możliwość zadbania o jakość i domaga się od Product Ownera i Scrum Mastera aby wypełniali swoje odpowiedzialności.

Jeżeli zespół nie podźwignie z ziemi tej odpowiedzialności innym trudno będzie pozostawić mu decyzyjność.

Warto więc Product Ownerowi ułatwić przekazanie decyzyjności pokazując się z jak najbardziej odpowiedzialnej strony i zadbać o dobry Product Backlog. Product Owner potrzebuje od zespołu informacji zwrotnej aby taki stworzyć. Zespół bez dobrego Product Backlogu nie stworzy właściwego inkrementu. Dzięki tej współpracy redukujemy złożoność i tak już skomplikowanego problemu tworzenia oprogramowania.

Product Backlog for Dummies

Co więc na temat Product Backlogu wiedzieć należy:

  1. Jest to JEDYNE źródło informacji na temat tego co będzie robił zespół deweloperski. Trzymamy w nim WSZYSTKIE rzeczy do zrobienia. Tak, aby każdy mógł sprawdzić co będzie robione i co jest od czego ważniejsze (wiem wiem, nie wszystko interesuje wszystkich, dlatego dobry mechanizm filtrowania może się przydać).  
  2. Trzymamy w nim porządek! To znaczy:
  3. Jest SPRIORETYZOWANY. Czyli elementy mają określoną kolejność, mam tu na myśli porządek zupełny: nie ma dwóch elementów na tym samym poziomie. Czemu tak? Bo tak jest prościej. Niewielkim wysiłkiem Product Ownera skracamy dyskusje, które mogłyby wybuchnąć pod jego nieobecność.  To w jakiej kolejności spod rąk zespołu będą wychodzić gotowe funkcje jest tak kluczowe, że warto aby było tak jasne i przejrzyste jak tylko się da.
  4. Jest KRÓTKI. Wydaje się sprzeczne, mamy tam trzymać tam wszystko co jest ważne i jednocześnie dbać o to żeby był krótki? Ta dyscyplina się opłaca. Zmusza nas do realnego planowania na rozsądny(tzn. rozsądnie krótki) okres czasu. Tak, żeby plan nam służył, a nie siedział w Backlogu i się kurzył. Na górze rzeczy drobne i dobrze rozpisane. Na dole duże i niedopracowane, ale te które chcemy nieustannie rewidować i uzupełniać bo są ważne. Na trzymanie mglistych planów, które może zrealizujemy a może o nich zapomnimy też warto mieć jakiś sposób. Jeden z fajniejszych, które widziałam to trzymanie ich wszystkich w ostatnim elemencie Product Backloga. W ten sposób nie przeszkadzają i jednocześnie o nich nie zapominimy.
  5. Jest CZYTELNY. Kolejny banał, nad którym naprawdę warto się pochylić. Z Backloga ma korzystać każdy zainteresowany produktem, szkoda marnować czas tych wszystkich osób. Szczególnie swój własny, zdarzyło wam się ślęczeć nad własnymi notatkami próbując je zrozumieć? A co dopiero osoby które ich nie tworzyły. Backlog jest dokumentem publicznym, służy wszystkim osobom zaangażowanym w tworzenie produktu. Jest narzędziem nieustannej komunikacji Product Ownera z resztą świata. Nieczytelny nie będzie używany. Drogi Product Ownerze, jeżeli nie dostajesz od zespołu tego o co prosisz, sprawdź czy jasno wyrażasz swoją prośbę (zanim zdążysz jasno wyrazić swoją opinię o produktywności zespołu…). Czytelny Backlog skoncentruje uwagę osób zaangażowanych w tworzenie produktu na kluczowych dla niego rzeczach. Każdy z deweloperów podejmuje dziesiątki decyzji w ciągu dnia: Jak podzielić funkcjonalności? Gdzie umieścić przycisk? Jak zoorganizować informacje? Jak nazwać zbiór testów? Do kogo dzisiaj zadzwonić itd. Każda z tych decyzji może wspierać obecny plan rozwoju produktu lub się z nim mijać. Znajomość i zrozumienie planu jest podstawą tego aby mu służyła.
  6. Jest DOSTĘPNY. Najgorsza wersja nieczytelności to niedostępność. Backlog ma być tam gdzie większość osób się go spodziewa. Tam gdzie się przyzwyczaili że jest. A jeżeli się jeszcze nie przyzwyczaili, to tam gdzie się o niego będą potykać (jak trzeba to dosłownie). Ludzie nie pytają gdzie jest? To albo jest tam gdzie trzeba, albo z niego nie korzystają. Jak nie korzystają to produkt się nie rozwinie. Bo każda z dziesiątek małych decyzji jakie deweloperzy podejmują każdego dnia będzie podjęta na podstawie złych przesłanek.  
  7. Jest WYESTYMOWANY. Podobnie jak z priorytetyzacją. Łatwe do osiągnięcia, np. za pomocą białych słoni (klik: http://tastycupcakes.org/2009/09/sizing-game/). A dając z kolei Product Ownerowi lepszy obraz sytuacji i skracająca mnóstwo niepotrzebnych dyskusji.
  8. Jest AKTUALNY i UŻYWANY przez wszystkich zainteresowanych projektem. To jest nagroda za powyższe.

we-can-do-it

Tak jest po prostu łatwiej!

Wygoda i zwinność jaką osiągamy za zachowanie powyższych jest nieoceniona.

Szczególnie dla zespołu deweloperskiego. Niestety wymaga mnóstwo pracy od Product Ownera. A to co wymaga pracy wymaga i motywacji. Na niespełnieniu tych kryteriów cierpi odpowiedzialny za jakość zespół. Bo bez dobrego Backloga nie ma dobrego jakościowo produktu.

Dlatego namawiam was zespoły. Zadbajcie o siebie i otwarcie informujcie swoich Product Ownerów o tym jak wam się korzysta z Produkt Backloga!

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!

© 2017 Brass Willow Blog

Theme by Anders NorenUp ↑