Agile dla biznesu: Wybór frameworka Scrumban dla startupu

„Agile” jest nie nakazowe co oznacza, że samo w sobie nie określa dokładnie JAK uzyskać zwinność. W ciągu ostatnich 40 lat istniało wiele podejść (z lepszymi i gorszymi wynikami) do stworzenia konkretnego przewodnika lub framework który powie dokładnie, jak uzyskać zwinność w organizacji.Niektóre z tych ram zostały sformalizowane jeszcze przed Agile Manifesto (2001), ale w swoich najbardziej zaktualizowanych wersjach są zgodne z przesłaniem manifestu.

>

Co to jest Scrum Ban?

Koncepcja ScrumBan została po raz pierwszy sformalizowana w “Scrumban: Essays on Kanban Systems for Lean Software Development” napisanej przez praktyka inżynierii oprogramowania Coreya Ladasa w 2009 roku.

>

W swoich esejach Corey stwierdził, że adaptacja frameworka Scrum jest z pewnością dobrym pierwszym krokiem do wprowadzenia koncepcji LEAN w rozwoju oprogramowania. Stwierdził również, że pierwszy krok  musi być poprzedzony kolejnymi krokami, ponieważ każdy proces LEAN jest ciągły. Stosowanie każdego szczegółu ze Scrum Guide (zwłaszcza z pierwszych wersji Scrum Guide) bez rozpoznania, że być może ten framework ma pewne wbudowane ograniczenia, może zatrzymać zdolność zespołu do opracowywania lepszych produktów.

>

Co jest wyjątkowego w ScrumBanie?

Możemy usunąć te wbudowane ograniczenia Scrum poprzez zastosowanie Kanban “wewnątrz” Scrum i powoli rozpoznać, które elementy/artefakty/spotkania Scrum przynoszą największą wartość, a które są potencjalnym marnotrawstwem i mogą być ewentualnie zakończone. 

Możemy określić kilka kroków, które są potrzebne do przekształcenia Scrum w Scrumban. W niektórych punktach będziesz musiał zdecydować, czy chcesz “złamać” niektóre zasady Scrum.

>

1. Wizualizuj pracę.
2. Wprowadź limity WiP & dodaj więcej kolumn do rejestru sprintu.
3. Zatrzymanie szacowania pozycji zaległości

.

4. Pozbądź się niektórych “niepotrzebnych” zdarzeń Scrum
5. Uruchom Planowanie Sprintu, czyli przestań używać timeboxów

.

Ad. 1 Wizualizacja pracy

Na początku musisz być w stanie zobaczyć cały przepływ pracy, aby zapewnić niezbędną przejrzystość & wzajemne zrozumienie procesu rozwoju. Nawet podstawowa tablica KanBan jest do tego świetnym narzędziem.

Ad. 2 Nałożenie limitów WiP & dodanie większej liczby kolumn do rejestru sprintu.

Ten krok jest zarówno najważniejszy, jak i najtrudniejszy. Limity pracy w toku to coś, co wskaże Pull System do bieżącego przepływu pracy w sprincie. Aby zarządzać tymi “pociągnięciami”, możesz dodać oddzielną kolumnę do zrobienia/wykonania do każdej kategorii pracy.

>

Ad. 3. Przestań szacować elementy zaległości (jeśli nadal to robisz).

W tym momencie będziesz mieć tablicę KanBan dla Backlogu Sprintu, ale jak połączyć ją z Backlogiem Produktu? Planowanie Sprintu to wciąż coś, więc możesz wykorzystać to wydarzenie w najbardziej efektywny i wartościowy sposób. Szacowanie pozycji z Backlogu Produktu za pomocą niektórych narzędzi, takich jak planowanie pokera itp. może pomóc, ale jest powszechnie nadużywane. W sekcji “Przydatne linki” można znaleźć prezentację  Allena Holuba’“No Estimates”, która pokazuje, co mam na myśli mówiąc o niewłaściwym użyciu).

To, co może być pomocne w łatwym uniknięciu szacowania pozycji zaległości, to dodanie limitu nie tylko do kroków pracy w toku, ale także do Backlogu Produktu i Backlogu Sprintu. Na początek można zastosować dwie proste zasady:

1. “pulling” nie więcej niż X pozycji do Backlogu Sprintu z Backlogu Produktu (podczas planowania sprintu)
2. nie posiadanie więcej niż Y najważniejszych elementów pracy w pełni opisanych  na “TOP” backlogu produktu (elementy, które potencjalnie zostaną wyciągnięte przez programistę’s

.

Jeśli jesteś purystą Scrum lub kroki 1-3 są dokładnie tym, czego potrzebujesz w procesie rozwoju produktu, nie musisz nawet wykonywać kroków 4 i 5. W tym momencie masz KanBan, który jest określony w czasie i utrzymywany przez framework Scrum. Nadal nic nie powstrzymuje Cię przed przeniesieniem uwagi z dostarczania większej wartości do klienta w każdym sprincie do dostarczania wartości do klienta częściej poprzez opanowanie limitów WiP.

>

Ad. 4. Pozbądź się niepotrzebnych wydarzeń i spotkań Scrum

Zawsze odniesiesz korzyści ze skupienia się na jakości wydarzeń/spotkań scrum&non scrum. Po dokładnej ocenie i wysłuchaniu informacji zwrotnych od zespołu możesz dojść do jednego z wniosków:

1. Efekty tego spotkania nie mają jeszcze wystarczającej wartości. Postarajmy się, aby następnym razem to spotkanie było lepsze.
2. To spotkanie nie ma celu z powodu wprowadzenia KanBan. Pozbądźmy się go i wykorzystajmy czas w sposób, który w rezultacie przyniesie więcej wartości.

Ad. 5. Uruchom Planowanie Sprintu, czyli przestań stosować timeboxing

Końcowym rezultatem “wstrzyknięcia” KanBana do Scruma może być rezygnacja ze sprintów time-boxowych. Nadal można je planować podczas Planowania Sprintu, ale moment tego Planowania Sprintu nie będzie już ustalony tak jak wcześniej. Moment planowania następnego sprintu zostanie uruchomiony, gdy na przykład w bieżącym Backlogu Sprintu pozostanie mniej niż Z elementów roboczych.

Podsumowanie: Plusy i minusy ScrumBan

ScrumBan wykorzystuje znaną powłokę frameworka Scrum do “wstrzyknięcia” KanBan. Strategia ta skutkuje minimalnym wysiłkiem organizacyjnym potrzebnym do uzyskania zwinności. Teoretycznie ScrumBan daje możliwość czerpania korzyści ze wszystkich cech Scrum & KanBan

Zalety KanBan:

• ScrumBan zapewnia przyzwoitą elastyczność. Jeśli twój proces rozwoju korzysta z time boxingu (na przykład twój klient ciągle zmienia wymagania i naprawdę chcesz go “zatrzymać”), możesz zastosować Sprinty o tej samej długości. Z drugiej strony, jeśli opanowałeś już swój przepływ pracy, możesz zacząć eksperymentować z łamaniem niektórych zasad przewodnika Scrum (planowanie sprintu z wyzwalaczem itp.).
• Jeśli Scrum framework został już wprowadzony i zastosowany w twoim procesie rozwoju, całej organizacji będzie o wiele łatwiej zrozumieć i dostosować się do ScrumBan. (i w końcu KanBan, jeśli jest to celem).

Konsekwencje KanBan:

• ScrumBan zapewnia przyzwoitą elastyczność. Jeśli twój proces rozwoju korzysta z boksów czasowych, możesz zastosować Sprinty o tej samej długości. Z drugiej strony, jeśli opanowałeś już swój przepływ pracy, możesz zacząć eksperymentować z łamaniem niektórych zasad Scruma (planowanie sprintów z wyzwalaczem itp.).
  

.

• Musisz pamiętać, że zastosowanie jakiejkolwiek ilości elastyczności w twoim procesie rozwoju samo w sobie nie wyleczy istniejących problemów.  Na przykład, jeśli programiści ciągle nie dostarczają ilości wartości uzgodnionej podczas Planowania Sprintu, powinieneś zawsze dokładnie przeanalizować, co jest główną przyczyną takiego problemu, zamiast natychmiast proponować planowanie wyzwalane lub pozbycie się szacunków jako jedynego rozwiązania.
• Jeśli framework Scrum został już wprowadzony & zastosowany w twoim procesie rozwoju, całej organizacji będzie o wiele łatwiej zrozumieć & zaadaptować się do ScrumBan.
• To prawda, jeśli Twoja organizacja została wprowadzona do Scrum z należytą dbałością o przejrzystość/inspekcję/adaptację i wartości Scrum. Jeśli istniejący Scrum jest już niczym więcej niż kultem cargo, jakakolwiek zmiana obecnej sytuacji będzie bardzo trudna ze względu na brak zrozumienia, co naprawdę oznacza Agile.