Przejrzystość jako fundament zwinności

Teamwork

Transparentność jest fundamentem zwinności. Co to oznacza? Pozwól, że wytłumaczę na przykładzie...

Transparentność jest fundamentem zwinności. Co to oznacza? Pozwól, że wytłumaczę na przykładzie.

Pewnego razu była sobie firma. Dyrektor firmy postanowił, że każdy zespół będzie od teraz pracował zwinnie. Zorganizował spotkanie z wszystkimi pracownikami przedsiębiorstwa, na którym ogłosił swoją decyzję. Kultura firmy mówiła jasno: nigdy nie kwestionuj decyzji zarządu. Dlatego każdy zaakceptował zmiany i wrócił do swoich codziennych obowiązków. Uważasz, że komunikat „od dzisiaj jesteśmy zwinni” pozwala firmie na skuteczne wprowadzenie zwinności? Odpowiedź jest oczywista – nie. Praktycznie nic się nie zmieniło, poza wprowadzeniem niezrozumiałego nazewnictwa takiego jak role i ceremonie. Nic więcej.

Transparentność ma zasadnicze znaczenie – jeżeli kultura Twojej organizacji nie pozwala Ci na zadawanie pytań, zapomnij o transparencji. Zapomnij o inspekcji i adaptacji. Zapomnij o zwinności.

Na szczęście nie wszystkie firmy pracują w ten sposób. Istnieją organizacje, które zbliżają się do zwinności w zupełnie inny sposób. Co to oznacza? Pozwól, że posłużę się kolejnym przykładem.

Pewnego razu w firmie istniał Zespół Scrum’owy. Podczas jednego ze sprintów, Zespół zdał sobie sprawę, że modyfikacja istniejącego raportu pozwoli dostarczyć wymaganą funkcjonalność. Ta informacja nie była znana podczas pielęgnacji Backlogu Produktu i późniejszego Planowania Sprintu. W konsekwencji zespół nie posiadał wymaganych kompetencji, aby samodzielnie modyfikować raporty zgodnie ze standardami firmy. W szczególności, zgodnie z Definicją Ukończenia przyjętą w zespole implementacja raportu oznaczało przejście testów akceptacyjnych wymaganych przez hurtownię danych. Cykl niezbędnych testów był zbyt obszerny, aby zrealizować go w bieżącym sprincie.

Zespół zdecydował się na rozmowę z Product Ownerem, podczas której wspólnie wypracowali możliwość podziału pracy na dwie iteracje. Podczas pierwszej iteracji, do raportu zostanie dołączona prosta notatka, o tym, że raport nie zwiera informacji związanych z nową funkcją produktu. W drugiej iteracji raport zostanie zmodyfikowany tak, aby zawierał nowe informacje wynikające z rozszerzenia definicji produktu, który miał być dodany w nowej wersji raportu.

Product Owner w transparentny sposób przedstawił interesariuszom propozycję dekompozycji prac i poprosił o informację zwrotną. W odpowiedzi interesariusze poinformowali Product Ownera, że raport jest wysyłany do dyrektora generalnego co tydzień i od niego należy uzyskać zgodę na proponowany podział prac.

Product Owner poprosił o spotkanie z dyrektorem generalnym, wspominając żartoblliwie że zajmie nie więcej czasu ile potrzeba na wspólne wypicie kawy. Po krótkiej rozmowie dyrektor generalny stwierdził, że raport został wygenerowany na prośbę jego poprzednika. Finalnie, panowie podczas kawy ustalili, że raport ten nie jest już przydatny dla firmy i może zostać usunięty.

Zachwyciła mnie ta historia. Pomimo typowych problemów związanych z komunikacją, transparencja zadziałała. Niepotrzebna praca nie została wykonana a Przyrost został ukończony zgodnie z Definicją Ukończenia. Wiele osób miało odwagę powiedzieć jasno – transparentnie – jak rzeczywiście wygląda sytuacja. Dlatego ta historia mnie inspiruje. Mam nadzieję, że zainspiruje ona również Ciebie.

Udostępnij ten artykuł

Ten portal używa cookies aby zapewnić jego sprawne działanie. Akceptacja cookies jest do tego wymagana. Można też odmówić zgody na użycie cookies i opuścić portal. Aby dowiedzieć się jak używamy cookies zapoznaj się z naszą Polityką Prywatności.
Akceptuję cookies Nie zgadzam się
Cookies utworzone podczas przeglądania portalu zostały usunięte i można go teraz bezpiecznie opuścić. Dalsze przeglądanie naszych stron spowoduje ponowne wyświetlenie monitu o akceptację cookies.