Ovo je priča koja pokazuje kako jedan Agile framework, iako veoma popularan i široko korišćen, nije univerzalno rešenje. Ne postoji framework koji je panacea – koji leči sve bolesti i odgovara svakom razvojnom timu.

Iako je danas „u trendu” kritikovati Scrum i naglašavati (često i preuveličavati) njegove slabosti, ovo nije takav tekst. Naprotiv, moj stav o Scrumu je veoma pozitivan. To što ga ljudi ponekad pogrešno tumače kao checklistu, metodologiju ili recept za uspeh u biznisu, softveru ili životu – nije problem Scruma. Scrum nikada nije tvrdio da rešava sve probleme u svim kompanijama za sve ljude. Niti je ikada tvrdio da će bilo kakva implementacija automatski doneti uspeh. Ipak, često čujem upravo takva očekivanja.

U ovom case study-ju istražujemo zašto Scrum nije bio dobar fit za ovaj tim, koje je probleme izazvao i kako je Kanban ušao u priču.

Takođe ćemo videti kako je tim prešao na novi framework i šta su iz toga naučili.

Upoznajte našeg klijenta

Naš klijent je IT kompanija koja razvija aplikaciju i web portal, kao i podcast posvećen sportskim vestima i događajima. Kompanija ima između 100 i 300 zaposlenih – uglavnom inženjera, ali i product i project menadžera. Zaposleni su geografski rasuti i većinom rade remote.

Tim koji je u fokusu ovog case study-ja radio je na Android aplikaciji i back-end platformi (content management system).

Na početku su usvojili Scrum kao framework i on je funkcionisao dok platforma nije lansirana. Međutim, nakon lansiranja, sa rastom broja korisnika i povećanim apetitom za monetizaciju oglasnog prostora, tim je počeo da posrće.

Izazov

U razgovoru sa stakeholder-ima saznali smo da tim nije uspevao da ostvari Sprint ciljeve. Zadaci su se prenosili iz jednog Sprinta u drugi, stvari nisu bile završavane, roadmap je bio ugrožen, a sa njim i ciljevi cele organizacije.

Tim je otkrio da su pod konstantnim pritiskom ključnih korisnika koji su zahtevali hitne zadatke – neplanirane, ali izuzetno važne i visoke poslovne vrednosti. Ovo je izazvalo tenzije između tima i Product Owner-a. PO je bio optuživan da ne razume vrednost proizvoda, da ne zna da prioritizuje i da nema dobar odnos sa klijentima. Sa druge strane, PO je tvrdio da klijenti prijavljuju zahteve tek kada dobiju pritisak od oglašivača – što je već kasno.

Važno je naglasiti da je Scrum do nedavno funkcionisao – proizvod je tek bio lansiran.

Dodatno, korisnici su smatrali da je razvoj feature-a konfuzan i da se njihovi zahtevi uzimaju u obzir tek nakon eskalacija ka senior management-u.

Gde je bio problem?

Radi boljeg razumevanja, kratko ćemo objasniti osnovu Scruma.

Scrum je Agile framework koji definiše:

• uloge (Product Owner, Scrum Master, Developers)
• događaje (Sprint, Sprint Planning, Daily, Sprint Review, Retrospective)
• artefakte (Product Backlog, Sprint Backlog, Increment)

Rad se odvija u vremenski ograničenim periodima – Sprintovima. Tokom Sprinta tim radi isključivo na stavkama koje su planirane u Sprint backlog-u. Sve što se pojavi nakon početka Sprinta mora da sačeka sledeći Sprint. U praksi, to znači čekanje od 2 do 4 nedelje.

Ovaj pristup donosi fokus, transparentnost i predvidivost – ali samo ako sistem funkcioniše disciplinovano.

U ovom slučaju, tim je počeo da primenjuje Scrum dok proizvod još nije bio na tržištu. Nije bilo realnih klijenata ni spoljašnjih pritisaka. U takvom okruženju Scrum je funkcionisao.

Međutim, kada su se pojavili realni korisnici, stvari su se zakomplikovale.

Tim je imao roadmap sa novim feature-ima – to je bilo pod kontrolom. Imao je i bugove – brojni, ali upravljivi.

Ono što je situaciju učinilo neodrživom bili su nepredvidivi zahtevi korisnika. Urednici i novinari su dolazili sa hitnim zahtevima, često vezanim za marketinške kampanje oglašivača. Pokušaji da se uvede predvidivost u proces zahteva su propali iz političkih razloga.

U takvom kontekstu, Sprintovi su postali besmisleni. Planiranje je trajalo par dana pre nego što bi se sve promenilo. Sprint ciljevi su postali formalnost, jer su svi znali da neće biti ispunjeni.

Moral tima je pao. Izgubili su osećaj svrhe i vrednosti. Delovalo im je kao da samo rešavaju nasumične zadatke bez stvarnog doprinosa.

Kako smo pomogli?

U tom kontekstu predloženo je da tim pređe sa Scruma na Kanban – Agile framework koji je fleksibilniji po pitanju vremenskih ograničenja, ali stroži kada je u pitanju rad u paraleli (Work in Progress).

Odluka je imala smisla s obzirom na kontekst rada.

Tim nije imao iskustva sa Kanban-om, pa je organizovan Kanban Fundamentals trening, prilagođen njihovoj situaciji.

Tokom jednog dana tim je:
– razumeo osnovne koncepte Kanban-a
– naučio razlike i sličnosti sa Scrum-om
– shvatio važnost limitiranja Work in Progress-a
– radio praktične vežbe

Nakon treninga, bilo je potrebno postaviti Kanban kao novi način rada. To je uključivalo i change management u organizaciji.

Pomogli smo na tri načina:

1. Kreirali komunikacionu strategiju za uvođenje Kanban-a – objašnjenje framework-a, primeri dobre prakse, plan implementacije, transparentna komunikacija ka celoj organizaciji i klijentima.
2. Organizovali radionicu od sat i po sa klijentima, kako bi razumeli novi način rada i kako njihove potrebe ulaze u sistem.
3. Postavili novi Kanban projekat u alatu koji tim koristi za praćenje rada.

Tim je bio spreman da krene. Naravno, prelazak nikada ne ide bez izazova, ali su imali energiju i spremnost da unaprede rad i povrate osećaj svrhe.

Learnings

Dobiti su bile višestruke.

Za tim:

• Veća fleksibilnost u radu sa nepredvidivim zahtevima
• Manje frustracije
• Jasniji tok rada
• Stabilniji ritam isporuke

Za organizaciju:

• Transparentniji proces
• Bolje upravljanje hitnim zahtevima
• Smanjenje konflikata

Za mene:

• Potvrda da je Kanban izuzetno efikasan u dinamičnim i nepredvidivim okruženjima.

U situacijama sličnim ovoj, podrška iskusnog mentora je posebno važna – naročito kada je u pitanju change management i postavljanje novog sistema rada.

Ako se i vi suočavate sa sličnim izazovima, javite se – možemo razgovarati o tome kako da unapredimo rad vašeg tima i podignemo performanse na viši nivo.