Najczęstszy błąd menedżerów: nie próbuj być wszystkim!
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”
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
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.
BYOP – ciekawe dyskusje o agile
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.
Spotkania BYOP
Na mapie ciekawych spotkań i źródeł wiedzy pojawia się nowa inicjatywa Code Sprinters – lidera rynku szkoleń Scrum/Agile w Polsce: spotkania Bring Your Own Problem. Są to spotkania, których celem jest wymiana informacji i doświadczeń między praktykami Scrum/Agile. Spotkania mają być moderowane przez trenerów Code Sprinters (a z czasem zapewne także i innych), są więc również okazją do uzyskania ich rady i pomocy. Spotkania odbywać się będą raz w miesiącu, kolejno w różnych miastach Polski. Najbliższe spotkanie już 14 marca w Warszawie (szczegóły).
Więcej na stronach BYOP.
Zwinne praktyki dbania o jakość oprogramowania
Poniżej publikujemy nagranie ze styczniowego e-seminarium PSUG, które prowadził Paweł Lipiński. Mowa była o zwinnych praktykach dbania o jakość oprogramowania, przede wszystkim Test Driven Development i Behavior Driven Development.
Czytaj więcej
Polecamy!
Kalendarz
« kwietnia 
czerwca » maj 2013 P W Ś C P S N 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
