Idzie nowe! Ale jak bardzo nowe?

sierpień 2, 2013 by Jakub · Skomentuj
Filed under: Artykuły 

Wchodząc na Scrum.org możemy zobaczyć, że wszystkie wersje językowe Scrum Guide’ów zostały przeniesione na osobną, własną stronę.

Ale to nie wszystko – od dziś możemy przeczytać i pobrać nową edycję Scrum Guide, oznaczoną July 2013. Na nową wersję czekaliśmy od października 2011, ale by przekonać się o rozmiarze i zasięgu zmian zachęcamy do samodzielnej lektury i przemyśleń. Uspokajamy, Guide dalej ma 16 stron.

Za niedługo opublikujemy dokładną analizę zmian wraz z komentarzami ekspertów.

Wartości w Scrumie

czerwiec 6, 2013 by kcienkosz · 2 komentarze
Filed under: Artykuły 

Scrum to nie metodologia. To proces o niepowtarzającym się przebiegu. To szkielet dla reguł, ról i zasad, które pomagają indywidualnym osobom i organizacjom stworzyć swój własny proces, odpowiadający ich konkretnym potrzebom. Scrum tworzy prostą podstawę działania, która zastępuje dotychczasowe procesy rozwoju produktu. Patrząc z perspektywy ScrumAnd (z ang. „Tak, pracujemy w Scrumie i…”), korzyści płynące ze Scruma są większe, jeżeli uzupełni się je o usprawnione lub zmienione praktyki w zakresie wytwarzania, zarządzania produktem, pracy zespołu czy funkcjonowania organizacji. Zmiana podstawowych założeń Scruma i nieprzestrzeganie jego reguł zatuszuje natomiast problemy i ograniczy, a nawet wyeliminuje, korzyści płynące z podejmowania dodatkowych działań.

Fakt, że podstawowe wartości Scruma są mało znane i prawdopodobnie za słabo podkreślane, wcale nie oznacza, że należy je pomijać.

Mimo że nie zostały one opracowane specjalnie na potrzeby Scruma i na jego wyłączny użytek, to jednak nadają one kierunek pracy i wpływają na nasze zachowanie i działania. Podejmowane decyzje i kroki, sposób realizacji procesu, poszerzanie Scruma o dodatkowe zadania, a także wszelkie towarzyszące jemu czynności powinny przyczyniać się do wzmacniania tych wartości, a nie je umniejszać czy podważać.

Nawiązywanie do nich w celu oceny wartości dodanej naszych działań okazuje się niezwykle przydatne. Stanowią one pomoc już na etapie samego rozważania, czy zastosować reguły Scruma, czy nie. Można co prawda stosować Scruma jako metodologię (organizować spotkania, instruować wszystkich graczy co do każdego szczegółu kolejnego zadania), ale czy takie jest jego właściwe przeznaczenie? Czy nie okazałoby się, że daje to danej osobie, zespołowi czy organizacji tylko połowiczne możliwości odniesienia sukcesu? Dobrym zobrazowaniem tej sytuacji są moje obserwacje dotyczące codziennych spotkań zespołów scrumowych. Każdy uczestnik odpowiada na nich na trzy pytania (Co zrobiłeś wczoraj? Co zrobisz dzisiaj? Czy istnieją jakieś przeszkody?) w sposób mało przygotowany lub, w najgorszym wypadku, tylko będąc spytanym przez Scrum Mastera. Czy takie spotkanie (mające umożliwić jak najlepsze wykorzystanie sprintu i przybliżenie się do jego celu) na pewno służy dzieleniu się informacjami, współpracy w planowaniu pracy na dany dzień oraz upewnieniu się, że nikt po prostu nie pójdzie na żywioł? A może uczestnicy mówią raczej do tablicy niż rozmawiają ze sobą nawzajem? Czy nie jest tak, że spotkanie służy tylko temu, by umieścić na tablicy wszystkie zadania i odhaczyć swoje obowiązki?

Oto szczegółowe spojrzenie na wartości i na to, jak mogą one pokierować naszymi krokami i zachowaniem w kontekście Scruma:

Zaangażowanie

Zaangażowanie w kontekście Scruma jest powszechnie źle interpretowane. Bierze się to stąd, że kiedyś oczekiwano od zespołów scrumowych zobowiązania się do zrealizowania celu danego sprintu i wybranych elementów z rejestru produktu. Z powodu przestarzałego, przemysłowego sposobu myślenia (które niestety zbyt długo pokutowało w obszarach związanych z wytwarzaniem oprogramowania) oczekiwano dostarczenia całości za wszelką cenę. „Zobowiązanie” zostało uznane za sztywny wymóg, choć miało ono znaczyć tylko tyle, że zespół będzie maksymalnie przykładał się do swojej pracy w sprincie i dostarczał przejrzystych informacji co do postępu prac. Zresztą w złożonym, kreatywnym i nieprzewidywalnym świecie wytwarzania oprogramowania jakiekolwiek zobowiązania odnośnie zakresu prac są po prostu niemożliwe.

Definicja słowa podana przez Oxford Dictionaries najlepiej oddaje jego „scrumowe” pierwotne znaczenie:

Zaangażowanie – stan lub cecha bycia oddanym jakiejś sprawie, działaniu, etc.

zaangażowanie się firmy w dostarczenie jakości

Nie mogłem obwiniać swoich graczy o brak zaangażowania.

A zatem poprzez „zaangażowanie” należy rozumieć aktywne uczestnictwo odnoszące się do podejmowanych działań i włożonego wysiłku, a nie ostatecznego produktu.

W Scrum Guide zastąpiliśmy słowo „zaangażowanie”, wynikające z planowania sprintu, hasłem „prognoza”. Dzięki powiązaniu prognozy z zakresem prac unikamy błędnej interpretacji. Dodatkowo świetnie współgra ona z faktyczną naturą Scruma.

Zaangażowanie wciąż pozostanie jednak jedną z kluczowych wartości.

Angażujemy się w pracę zespołu, w podnoszenie jakości, we współpracę, w uczenie się nowych rzeczy. Angażujemy wszystkie siły, by każdego dnia dawać z siebie wszystko. Angażujemy się, by osiągnąć cel sprintu i by działać profesjonalnie. Angażujemy się w samo-organizację, dążenie do doskonałości i przestrzeganie zwinnych wartości. Angażujemy się, by stworzyć działające oprogramowanie. Angażujemy się w poszukiwanie ulepszeń i przestrzeganie reguł Scruma. Angażujemy się, by spełnić definicję ukończenia, by działać zgodnie z wartościami i ukończyć pracę. Angażujemy się w badanie rzeczywistości i dostosowywanie się do niej. Angażujemy się, dążąc do przejrzystości. Angażujemy się, by zmierzyć się z panującym status quo.

Skupienie się na najważniejszym

Charakterystyczna w Scrumie praca w iteracjach, polegająca na dostarczaniu kolejnych przyrostów, i narzucone ramy czasowe pracy pomagają się skoncentrować. Skupiamy się na tym, co istotne tu i teraz, bez zastanawiania się na tym, co może stać się ważne za jakiś czas. Skupiamy się na tym, co wiemy w danej chwili bez analizowania zbędnych alternatyw. Skupiamy się na najbliższej przyszłości, ponieważ ta dalsza jest zbyt niepewna, a my chcemy uczyć się dziś, aby zdobyć doświadczenie niezbędne do przyszłych zadań. Skupiamy się na pracy, by wykonać to, co do nas należy. Skupiamy się na najprostszych rzeczach, które mogą zadziałać.

Otwartość

Empiryzm Scruma wymaga przejrzystości i otwartości. Chcemy badać rzeczywistość, aby móc się do niej przystosować w rozsądny sposób. Jesteśmy otwarci na uwagi dotyczące naszej pracy, dokonywanych postępów, sposobu uczenia się i napotykanych problemów. Jesteśmy także otwarci na ludzi i współpracę z nimi. Postrzegamy innych jako rzeczywiste osoby, a nie zasoby, roboty czy części większej machiny, które łatwo zastąpić – ostatecznie tworzenie oprogramowania nadal pozostaje domeną człowieka. Jesteśmy otwarci na współpracę ze specjalistami z różnych dziedzin, posiadającymi różne umiejętności. Jesteśmy otwarci na współpracę z interesariuszami i szerszym otoczeniem. Jesteśmy otwarci na krytykę i wzajemne uczenie się. Jesteśmy otwarci na zmianę, gdyż organizacja i rzeczywistość, w której ona funkcjonuje, zmienia się ciągle w sposób nagły i trudny do przewidzenia.

Szacunek

Okazujemy szacunek ludziom, ich doświadczeniu i pochodzeniu. Szanujemy różnorodność, która sprawia, że stajemy się silniejsi. Szanujemy odmienne zdanie, które pozwala nam się uczyć. Okazujemy szacunek naszym sponsorom, nie tworząc funkcjonalności, z których i tak nikt nie będzie korzystał. Okazujemy szacunek, nie marnując środków na coś, co jest nic niewarte lub nigdy nie będzie wdrożone czy wykorzystane. Okazujemy szacunek użytkownikom, rozwiązując ich problemy. Szanujemy zasady, którymi kieruje się Scrum. Okazujemy szacunek otoczeniu, nie zachowując się jak samotna wyspa. Szanujemy umiejętności, specjalistyczną wiedzę i intuicję innych. Szanujemy podział ról w Scrumie.

Odwaga

Mamy odwagę, by nie tworzyć czegoś, czego nikt nie chce. Mamy odwagę przyznać, że wymagania nigdy nie będą idealne oraz, że nawet najlepszy plan nie uwzględni w pełni rzeczywistości i stopnia jej złożoności. Mamy odwagę, by traktować zmianę jako źródło inspiracji i motywacji. Mamy odwagę, by nie dostarczać oprogramowania, które nie jest skończone. Mamy odwagę, by dzielić się wszystkimi informacjami (przejrzystość), które mogą pomóc zespołowi i organizacji. Mamy odwagę przyznać, że nikt nie jest doskonały. Mamy odwagę, aby zmienić obrany kierunek. Mamy odwagę, by informować się nawzajem o ryzyku i korzyściach. Mamy odwagę promować Scruma oraz podejście empiryczne w procesie radzenia sobie ze skomplikowanymi zadaniami. Mamy odwagę, by wznieść się ponad zwodnicze pewniki przeszłości. Okazujemy odwagę, by działać zgodnie z wartościami Scruma.

O autorze

Gunther Verheyen do niedawna był globalnym Liderem Scrum w firmie Capgemini i Kierownikiem ds. tworzenia wartości zwinnych w dziale Usług Finansowych na obszar Belgii i Holandii. Odpowiadał tam za przekształcenia wewnętrzne i zewnętrzne. Szkolił, pomagał i trenował zespoły scrumowe i trenerów Scruma. Obszarem eXtreme Programming i Scrumem zajmuje się od 2003 roku. Obecnie jako jeden z najbliższych współpracowników Kena Schwabera pracuje bezpośrednio dla Scrum.org odpowiadając za rozwój szkoleń Scrum.

Tłumaczenie Krzysztof Cienkosz.

Najczęstszy błąd menedżerów: nie próbuj być wszystkim!

marzec 1, 2013 by Jakub · Skomentuj
Filed under: Artykuły 

Artykuł jest tłumaczeniem tekstu Andy’ego Brandta Managers’ common errors: trying to be everything, zamieszczonym na jego blogu.

Niedawno spotkałem się z zespołem, którego menedżer usiłował być dla nich Product Ownerem, Scrum Masterem (pierwotny SM ich grupy niespodziewanie „zmył się” kilka miesięcy wcześniej), ich liderem technicznym – i w tym samym czasie planował przyszłość ich działu, lobbował za produktem który wtedy tworzyli (wewnętrzny system z dedykowanym frameworkiem) i ogólnie zapewnić wsparcie od strony “politycznej”. Jeden z naszych trenerów prowadził retrospekcję, a ja przysłuchuwiłam się temu, co team mówił menedżerowi od dłuższego czasu: daj nam decydować, pozwól nam robić po naszemu, nawet gdyby miało to skutkować potknięciem. Co było najbardziej zdumiewające to to, jak te wszystkie prośby i wnioski się od niego odbijały – tak jakby oni mówili po mandaryńsku, a on w ogóle nie rozumiał.

Często obserwuję taką praktykę: menedżer który próbuje być wszystkim w “swoim” zespole, sprawować każdą z ról po trochę – i w efekcie żadnej nie wykonać dobrze. Sądzę, że powody takich zachowań są różne w zależności od danej sytuacji (przykładowo: ten facet nie jest żądny władzy, ale tylko intelektualnie związany z każdym z tych zagadnień, wszystko go ciekawi i chce to poznać, choćby miał jedynie uszczknąć kawałek), ale rezultaty są zawsze te same: kreatywność pracowników jest ograniczona, po kilku próbach zarzucają własną inicjatywę, a wówczas zdrowa samoorganizacja nie ma szans zaistnieć.

Oczywiście, to nic nowego: delegowanie zawsze było wyzwaniem dla liderów. Jednakże tradycyjna delegacja była delegacją zadań, a to o czym mowimy dziś to delegacja władzy i problemów do rozwiązania. To jeszcze większe wyzwanie – dlatego jeszcze więcej menedżerów ponosi porażkę, gdy chce zrobić to poprawnie.

Rada na koniec: Jeśli jesteś liderem, nie próbuj być wszystkim i wszędzie – skup się na wartości, którą ty jesteś w stanie dostarczać (np. strategiczne decyzje, tworzenie przekonujących wizji lub coaching) i nie przeszkadzaj zespołowi.

Andy Brandt

Książka “Agile w praktyce”

luty 21, 2013 by Jakub · 1 komentarz
Filed under: Artykuły, Wiadomości 

Andy Brandt od dwudziestu lat zdobywa doświadczenia w obszarze IT. Teraz postanowił zebrać je, przeanalizować w kontekście Agile i Scrum i podzielić się z innymi entuzjastami w książce “Agile w praktyce”, która jest już dostępna na platformie Leanpub.

Zapraszamy też do zapoznania się z udostępnionym tam darmowym rozdziałem, oraz przekazania feedbacku dla Autora.

Scrum i Bugi

październik 4, 2012 by andy · Skomentuj
Filed under: Artykuły 

Problemem, który jest często podnoszony przez uczestników szkoleń czy zespoły, w których Scrum jest wprowadzany jest to w jaki sposób pogodzić pracę nad funkcjonalnościami z naprawianiem błędów (bugów). Poniżej krótka prezentacja na ten temat, którą prowadzi Andy Brandt z Code Sprinters.

Czytaj więcej

BYOP – ciekawe dyskusje o agile

czerwiec 13, 2012 by andy · Skomentuj
Filed under: Kraków, Wiadomości 

Na ostatnim spotkaniu BYOP w Krakowie (12 czerwca) dyskusje koncentrowały się wokół agile – i jak zwykle przewijał się tam Scrum. Scrum jak wiadomo jest lekki i prosty w zrozumieniu, ale trudny w stosowaniu. Jest tak także dlatego, że Scrum koncentruje się na wąskim wycinku rozwoju oprogramowania – organizacji przepływu pracy i zarządzania wymaganiami. Dwa główne zagadnienia, o których rozmawialiśmy to motywacja pracowników w Scrum oraz skalowanie Scrum.

Dyskusja w tym pierwszym temacie szybko doprowadziła nas do wniosku, że Scrum pomaga utrzymywać motywację zespołu – usuwa niepewność co do terminów, pozwala ludziom zarządzać swoim czasem i swoimi zadaniami. Jednak problem motywacji jest oczywiście szerszy – ludzi motywuje się podobnie niezależnie od przyjętej metodyki.

Jeśli idzie o skalowanie to jest to temat nie do końca w Scrumie rozwiązany. Uczestnicy ostatniego BYOP omawiali przykład zastosowania metod agile w organizacji, w której tworzone jest jedno, składające się z wielu produktów, rozwiązanie. Andy Brandt z Code Sprinters zaproponował podział tego zagadnienia na trzy obszary – kwestię integracji technicznej, kwestie bieżącej koordynacji pracy zespołów oraz kwestię rozdzielenia wysokopoziomowych wizji i wymagań biznesu na konkretne backlogi dla zespołów argumentując przy tym, że tylko ten ostatni obszar jest nie w pełni rozwiązany. Marcin Dziedzic zaproponował rozwiązanie w postaci zespołu Enterprise Business Architects, który miałby pełnić wskazaną rolę, ale w dyskusji zgodzono się, że nie jest to jedyne możliwe rozwiązanie. Henryk Metz opowiadał o swojej metodzie LPDF oraz zastosowaniu metody Value Stream Mapping w tego rodzaju sytuacjach.

Nieubłagany upływ czasu nie pozwolił przedyskutować innych, ciekawych problemów przyniesionych na BYOP przez jego uczestników. Zapraszamy następnym razem – najbliższe spotkania BYOP to:

  • Szczecin 26.06.2012
  • Wrocław 13.07.2012
  • Warszawa 16.07.2012

Zapisy i więcej informacji na stronach BYOP.

Następna strona »