Od idei do wdrożenia w 1 tydzień – co to znaczy prawdziwy agile?

Szybkie dostarczanie wartości w agileCzy da się wdrożyć zmianę w jeden tydzień? Czy to w ogóle jest możliwe? Zaczynając pracę w scrumie często zadawałem sobie to pytanie. A jako Scrum Master zastanawiałem się, jak zainspirować zespół, aby dostrzegł, jakie możliwości daje praca w tak krótkich iteracjach. Praca bynajmniej nie oznacza tutaj pociętego projektu i robienia czegoś przez tydzień, ale wyjścia od idei do wdrożenia w ciągu dosłownie jednego sprintu.

W 2013 roku miałem okazję uczestniczyć w warsztatach prowadzonych przez Ariadnę Font,  specjalistę User Expierience. Ariadna podczas warsztatów, poza pokazaniem nam wielu narzędzi UX, podzieliła się również wizją projektowania i tworzenia oprogramowania w bardzo krótkich iteracjach zgodnie z duchem Agile. Podsumowaniem dyskusji o podejściu inspection & adaption, angażowaniu całego zespołu oraz – chyba co najważniejsze – angażowaniu użytkownika i zbierania od niego informacji zwrotnej (feedbacku) było zaprezentowanie nam krótkiego filmiku:

Film stał się, jak sądzę nie tylko dla mnie, inspiracją do rozszerzenia horyzontów zespołu na tworzenie nowych funkcjonalności dla użytkownika. Szczęśliwie w warsztatach uczestniczył także specjalista UX z mojego zespołu (gdzie byłem Scrum Masterem), więc naturalnie było nam we dwójkę łatwiej zainspirować nasz zespół.

Zaczęliśmy wspólnie ewangelizację zespołu. Trwało to „x” tygodni, było także związane ze zmianą podejścia do wdrożeń i przejściem poprzez continous integration do continous deployment (no prawie:)- o tym ostatnim napiszę w jednym z kolejnych artykułów). Okazją do zastosowania inspirującego podejścia do tworzenia oprogramowania, pokazanego na załączonym filmie, była zmiana jednego z parametrów wyszukiwania w serwisie, nad którym aktualnie pracowaliśmy.

Gdybyśmy podeszli do tego tradycyjnie, zmiana ta zapewne wyglądała by mniej więcej tak: PO (a może nawet analityk) wymyśla zmianę, grafik ją projektuje, trafia to do zespołu na refinement jako gotowa do wdrożenia makieta z komunikatem, że mamy jako zespól napisać User Story i weźmiemy to na następnym sprint do wyprodukowania. Pytanie tylko brzmi, gdzie w tym wszystkim użytkownik i jego potrzeby, skąd wiemy, czy to jest akurat najlepszy możliwy wariant tej zmiany i jak zbudować zaangażowanie zespołu, „rzucając mu na stół” gotowy do wykonania zakres?

Ale nie podeszliśmy to tego tradycyjnie. Wspólnie jako zespół powiedzieliśmy sobie, że może pora spróbować innego podejścia do rozwijania naszego produktu. Plan był prosty – Product Owner przyszedł z problemem, pewna ideą jego rozwiązania oraz KPI i celem na nim opartym, który w konsekwencji miał zostać zrealizowany. Zespół nie wiedział jeszcze wtedy, jak zamierza rozwiązać ten problem. Refinement skończył się zapisaniem User Stories opisujących problem i oczekiwaną funkcjonalność wraz z uzasadnieniem, po co to robimy.

W trakcie planningu zespół przygotował plan realizacji zakresu, a celem było osiągnięcie konkretnego poziomu KPI. Jak wyglądał wysokopoziomowy plan? Zakładał, że:

  • zrobimy burzę mózgów,
  • stworzymy makiety,
  • przygotujemy scenariusz badania,
  • przeprowadzimy badanie,
  • zaimplementujemy wybrane przez użytkowników rozwiązanie,
  • wdrożymy.

I to wszystko w trakcie jednego, jednotygodniowego sprintu!

Czy nam się to udało? Jasne! W trakcie sprintu zespół przeprowadził badania 33 osób (pracowników firmy, niezwiązanych z naszym serwisem). Zrealizował to dzieląc się na trzy zespoły badawcze (po 2 osoby). Wybraną przez użytkowników opcję (głosowali, ale również zostawiali nam bardzo cenne swoje uwagi) zespół zaimplementował, przeprowadził demo zmiany dla Product Ownera i interesariuszy na środowisku testowym, po czym ją wdrożył. Na review przyszliśmy porozmawiać o produkcie, a nie aby „odbierać historyjki”.

Dlaczego nam się to udało? Na pewno mieliśmy okoliczności temu sprzyjające – dojrzały zespół (2-3 lata w agile’owym środowisku), funkcjonalność związaną stricte z interfejsem użytkownika, Product Ownera przychodzącego do zespołu z problemem, a nie rozwiązaniem, środowisko programistyczne umożliwiające continous integration i wdrożenia praktycznie każdego dnia oraz narzędzia do „łapania” opinii użytkowników, zarówno tych jakościowych jak i ilościowych.

Refleksje, jakie mnie nachodzą jako Scrum Mastera, to na pewno niewiarygodny wzrost zaangażowania w zespole. Obawiali się „wyjścia na korytarz” do użytkowników, ale okazało się, jak sami później mówili, że to niezwykłe, otwierające oczy doświadczenie. Poza tym tworzenie papierowych makiet jest wręcz doskonałe – mogliśmy razem z UX’em zaangażować cały zespół w ich przygotowanie, odrywając ich od komputerów i dając im równocześnie przestrzeń do kreatywnego myślenia.  

Cel, jaki został przed zespołem postawiony, został zrealizowany, również ten wyrażony w postaci KPI, co mogliśmy zweryfikować dopiero po zakończonej iteracji (potrzebowaliśmy kilku dni, aby zebrać większą ilość danych/opinii).

PS. Oczywiście, że nie wszystko da się tak zrobić i nie w każdych szeroko rozumianych warunkach. No ale chyba powinniśmy stawiać sobie ambitne wyzwania?

Źródło zdjęcia: https://flic.kr/p/4vg5r4

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x