Dugo sam odgađao ovaj članak. Prošao sam desetke draftova. Brisao sam cijela poglavlja. Zašto? IT infrastruktura i pojam agilno nisu u najboljim odnosima. Infrastruktura se, u većini organizacija, smatra “keep-the-lights-on” uslugama. I to je istina.

Ali da bi došli do tog potreban je i razvoj IT infrastrukturne usluge. Infrastrukturnog produkta. Kao i svakog drugog produkta. Klijenti nisu krajnji korisnici organizacije, osim ako je to core business organizacije. Ali i dalje postoji korisnici usluge. Klijenti. Sa svim svojim zahtjevima, željama, problemima i bolnim točkama. I za njih održavamo ali i razvijamo infrastrukturne produkte. Za potrebe klijenata. I potrebe organizacije.

Na spomen “agilnog” u krugu IT infrastrukture, kolege će pozeleniti od muke. Vjerujem da sam shvatio i zašto. Održavanje postojeće usluge, tj. run faza, teško funkcionira prema agilnim principima. U najboljem slučaju prema Kanban metodologiji. Ali nikako prema Scrum. Prevelik je broj ceremonija i utrošenog vremena na day-to-day operativno izvršavanje zahtjeva. Nema smisla. Međutim, prilikom većih promjena i uvođenja potpuno nove usluge tj. produkta – ima smisla. Ima puno smisla.

Samo da se ogradim u startu: ovo nije pokušaj uvođenja pune agilne metodologije u procese IT infrastrukture. To bi bio fail. Ovo je pokušaj pronalaska zlatne sredine. Pokušaj osvještavanja svih sudionika da su i IT usluge produkti. I da kao takvi prolaze isti životni ciklus kao i bilo koji drugi produkt. Produkti koji nisu tu da bi držali svjetla upaljena nego produkti koji rješavaju probleme korisnicima te doprinose poslovnim ciljevima organizacije.

Kako IT infrastrukturu voditi kao produkt? Puna produktna struktura i organizacija rada moguć je “overkill”. Pogotovo na početku uvođenja ovakve promjene. Pokušao sam naći neku sredinu za primjenu produktnih/agilnih principa i metoda za IT infrastrukturne produkte. Pokušat ću opisati što sam smislio, i od nedavno primijenio, u narednim poglavljima.

Što želim postići ovim eksperimentom:

• ownership – kada je kolega Product Owner, stvarno smatram da je vlasnik tog produkta. Nadam se da i kolege to vide tako.
• legacy – ne u smislu da je produkt “legacy” već ponos da je kolega izgradio taj produkt od nule do pune funkcionalnosti i ostavio iza sebe nešto na što može biti ponosan.
• sloboda – svaki tim ima punu slobodu odabrati kako će riješiti zadani problem. Naravno u zadanim okvirima (najčešće vremenskim i financijskim).
• osvještavanje – da su IT usluge produkti. I da kao takvi imaju klijente.
• suradnja – na svaki produkt je dodijeljen po jedan djelatnik iz svakog odjela. Produkt ih povezuje.
• rast – svaki voditelj inicijative produkta ima priliku rasti. U organizacijskim sposobnostima (vođenje tima), prezentacijskim sposobnostima (priprema za steering), itd.

Dvotjedni steering

Svaka dva tjedna voditelj produktne inicijative (product owner) ima 15-minutnu prezentaciju s Voditeljima odjela i Direktorom direkcije (business owner i stakeholders). Cilj steeringa je da svi uključeni budu upoznati s napretkom i planovima. Najvažnije je da PO može izraziti svoje probleme – u obliku prepreka i rizika – tako da BO i stakeholderi mogu ukloniti prepreka i pomoći minimizirati rizike. Prezentacija je minimizirana na dva slidea:

1. odrađeno u prethodnom periodu i plan za naredni period
2. rizici i prepreke

Ideja je smanjiti extraenous kognitivno opterećenje na najmanju moguću mjeru. Moguće da dio čitatelja ovo protumači kao da je minimalan utjecaj. I u pravu su, minimalan je utjecaj. Ali ciljam na sumu minimalnih utjecaja da stvore velik rezultat.

Steering je također prilika da se svi ključni sudionici upoznaju sa statusom i napretkom inicijative produkta. Najvažniji cilj, meni osobno, je steeringa je graditi product owner kroz mentoriranje i usmjeravanje. Međutim, cilj steeringa je i na vrijeme prepoznati da produkt se ne razvija u ispravnom smjeru. Tu je moguće više opcija: promijeniti smjer, pauzirati ili u potpunosti stopirati inicijativu. Nije nužno da je svaka inicijativa uspješna. To su iluzije. Fail Fast and Fail Cheap. Cilj je zaustaviti inicijativu, ako se pokaže neispravnom, dok još nije utrošeno previše resursa – kako financijskih tako i vremenskih.

Landing Page

U knjizi The Culture Code jedna od osnovnih metoda izgradnje zdrave kulture u organizaciji je definiranje svrhu zašto tim radi to što radi (eng. Purpose). Definirati svrhu nije lagan zadatak, a još teže je kontinuirano tu svrhu komunicirati.

Jedan od pojmova koji mi se urezao u pamćenje je “stealth expectations” za koji sam prvi put saznao u knjizi Atlas of the Heart. Stealth expectations je efekt koji se dogodi kada se ne komunicira dovoljno informacija čime očekivanja ostanu “sakrivena”. Ako očekivanja nisu komunicirana, rezultat rada tima neće biti u skladu. Slijedi razočaranje. S obije strane.

Cilj landing pagea svake inicijative je anulirati gore navedene probleme. Problem skrivenih očekivanja i manjka izraženosti svrhe rada. Landing page sadržava sve relevantne informacije koje su potrebne temu da riješi zadan problem i komunicira svrhu. Sve ne znači romane od desetke stranica dokumentacije. Sve znači jasne ali sažete informacije. Cilj je da svatko može u dvije minute saznati:

• koji problem tim rješava
• zašto tim rješava taj problem
• kako će tim riješiti taj problem
• kada će tim riješiti zadani problem
• koji je očekivani outcome inicijative
• gdje je tim sada
• tko su članovi tima i tko radi na kojem zadatku
• koja su zadana ograničenja

Velik sam pobornik ideje davanja timu problema s kojim smo suočeni umjesto liste funkcionalnosti i zadataka. Ostavljam timu da sam pronađe optimalno rješenje. Sigurno su kompetentniji u tome od mene. Moram priznati da se ne držim uvijek toga ali se kontinuirano trudim razvijati u tom smjeru.

Tim kroz odjele

Produktno orijentirana organizacija gradi timove različitih profila koji su potrebni da se izgradi produkt, u protivnom produkt koji dobijemo je slika i prilika organigrama. Kako su i IT infrastrukturne usluge produkti, timovi su izgrađeni da maksimalno kontribuiraju produktu. Kompetencije članova tima su, prilikom odabira, bile ključne. Uz kompetenciju drugi bitan faktor prilikom organizacije tima je da se članovi tima, koliko god je moguće, ne angažiraju na više inicijativa. Zvuči utopijski. I trenutno nisam u mogućnosti to u potpunosti provesti. Ali ne odustajem od ove vizije. Nisam pobornik multi-taskinga. Jednostavno ne funkcionira, ništa se ne napravi kvalitetno. Sve se napravi ali površno. Vjerujem u ekspertizu a to zahtijeva fokus.

Šestomjesečni review

Ovaj princip vođenja incijativa – kao produkta – nov je kako i meni tako i mojim kolegama. Učimo po putu. Zamislio sam da se svakih 6 mjeseci svi relevantni sudionici (PO, BO, itd) nađemo i da prođemo kroz the good, the bad and the ugly ovog eksperimenta. Neka vrsta retrospektive na cijelu ovu ideju i koncept. Niti jedan proces nije savršen i ako ga ne unaprjeđujemo kontinuirano – degradirat će vremenom. Ako bi izdvojio najvažniju pouku iz Toyota Kata principa je da kontinuirano i u malim iteracijama poboljšavamo sustav. Pa tako i ovaj.

Da li vi vidite IT infrastrukturne usluge kao produkte? Da li ste voljni pokušati ovaj princip vođenja inicijativa – kao produkta? Ja jesam. Krenuli smo u ovaj eksperiment. Kako će završiti, moramo čekati. Učiti po putu. Iterativno poboljšavati i korigirati. Javim rezultate :)