Optimizacija jednog dela procesa/sistema je u Lean pristupu poznata kao lokalna optimizacija. U slučaju agilne transformacije lokalna optimizacija bi bila odluka da na primer tim krene da radi po Scrum framework-u, bez da je analizirano koliko su svi učesnici u procesu razvoja softvera spremni da usvoje novi način rada. U ovom članku ću pokušati da objasnim zašto je takva odluka loša i dam odogovor na to šta kompanija koje želi da se transformiše treba da uradi.

Zašto samo Scrum nije rešenje?

Prvo pitanje koje obično postavim kompanijama koje zanima Scrum trening je: “Kako ste odlučili da je Scrum rešenje za problem koji imate?”. Po mom dosadašnjem iskustvu ovo je veoma moćno pitanje i otvara veoma širok dijalog. Problem sa identifikacijom Scrum-a kao polaznom osnovom za transformaciju je u tome što Scrum kao framework zahteva promenu u organizaciji za koju ta kompanija možda nije spremna. Umesto da se kompanija odluči za Scrum, ja obično savetujem da pre svega dođe do razumevanja kako ona u stvari trenutno funkcioniše i gde želi da ide. Scrum ne može biti cilj, jer Scrum ne rešava problem. U nekim situacijama Scrum može da učini problem vidljivim i da donese kratkotrajni pomak napred.

Primenom Scrum-a optimizuje se samo jedan deo kompanije. Problem koji je u razvoju softvera česta pojava, a koju Scrum ne može da reši je situacija u kojoj je tim na dobar način isporučio nešto što krajnji korisnik ne želi da koristi. Dobar primer za ovo je Nokia koja je izgubila trku na tržištu pametnih telefona i pored toga što su proizvodili najkvalitetnije telefone i dugo vremena bili vodeći u svojoj oblasti.

Zašto samo eXtreme Programming nije rešenje?

XP se pre svega zasniva na veoma dobrim praksama koje omogućavaju kreiranje i isporuku softvera visokog kvaliteta. Sa te strane retko ko može da nađe ozbiljnu zamerku na prakse koje promovišu ljudi oko XP pokreta.

Organizacije kao što su banke i druge velike kompanije imaju finansijske mogućnosti da zaposle i/ili obuče ljude za sve ove prakse. Čak i kada svi ljudi dobiju edukaciju ovog tipa problem nastaje zbog neefikasnosti celog sistema. Neefikasan sistem prouzrokuje da dobre prakse donose jako malo poboljšanje u ukupnom zbiru.

Zašto jedna metodologija nije rešenje?

Metodologije same po sebi nisu ni dobre ni loše. One nastaju u određenom trenutku u vremenu kao pokušaj odgovora na probleme koje organizacije imaju u datom kontekstu. Problemi sa metodologijama primarno nastaju iz dva razloga. Prvi razlog je što ljudi često krenu sa primenom neke metodologije bez dovoljno znanja i iskustva. Posledice ovakvog pristupa često budu kasno vidiljive, jer se desi da niko ne može da identifikuje šta tačno nedostaje. Drugi razlog za neuspešnu primenu je to što se metodologije često kopiraju po principu ako je radilo u jednoj kompaniji radiće i u nekoj drugoj. Čak i kad je u pitanju jedna ista kompanija, veoma teško je tvrditi da nešto što je dobra praksa u jednom timu, će biti dobra praksa u ostalim timovima.

Odabirom jedne metodologije organizacije često žele da smanje operativne troškove. Kratkotrajni efekti ovakvog pristupa mogu biti pozitivni po finansije, međutim oni gotovo uvek vode ka stvaranju kulture koje ima veliki otpor ka promenama. Otpor ka promenama ubija mogućnost inovacije. Organizacija koja ne inovira postaje troma i opet se vraća u stanje u kome je bila pre pokušaja transformacije.

Kad je promena teška, neka bude kontinuirana

 

Rešenje za ovaj problem je jednostavno za shvatati, a veoma često teško za implementirati. Prva stvar koju kompanija treba da uradi je da razume šta je to vrednost koju isporučuje krajnjem korisniku. Odmah posle bi trebalo da napravi mapu toka vrednosti. Na ovaj način se još ništa konkrento nije promenilo. Ono što se često tokom ovog procesa dogodi je da se identifikuju mesta na kojima dolazi do čekanja, blokade i gde nastaju uska grla u procesu. Kada je ovo poznato onda je lakše odrediti koja to mesta stvarno treba poboljšati.

Kada se odrede mesta čije poboljšanje stvarno dovodi do unapređenja celog procesa onda je potrebno formirati jednu ili više pretpostavki o akcijama za unapređenje. Svaka pretpostavka treba da može da se validira u kratkom vremenskom periodu. Pretpostavka koja ima najveću izvesnost da će doneti unapređenje se testira prva. Po završetku testiranja porede se rezultati i određuje se sledeći korak. Ovo može da znači da sve ostale pretpostavke nisu važne već da sada ponovo treba videti kom delu procesa treba unapređenje. Primera radi, pretpostavke mogu ići od toga da nekome treba trening, preko odustajanja od nekih projekata,  pa sve do toga da organizacija mora da promeni svoju strukturu kako bi efikasnije poslovala.

Tehnike koje mogu da pomognu da se uspostavi ovakav proces su:

• Value stream mapping
• A3 problem solving
• Popcorn flow

Kao što se iz svega može zaključiti kontinuiranim fokusiranjem na sistem u celini, umesto na lokalne optimizacije, ne nestaje potreba za dobrim praksama i metodologijama. Ono što se menja je stavljanje fokusa na to šta je to što će stvarno doneti poboljšanje u datom trenutku. Orijentisanjem na pretpostavke i njihovo dokazivanje kompanija postaje organizacija koja uči i stvara model koji je za nju samu najprikladniji, a ne promovisan od strane raznih konsultanata.

Slika preuzeta sa: http://blog.aclairefication.com/wp-content/uploads/2013/10/WritingPrompt.jpg