Zašto Enterprise Agilni tim ne uspijeva

Izvor: https://unsplash.com/@rawpixel

Prošli tjedan stajao sam u konferencijskoj sali u kompaniji vrijednoj 20 milijardi dolara, radeći na Agileu. Grupu koja je prisustvovala sačinjavali su direktori i voditelji svake funkcije u samo jednom proizvodnom programu unutar ove divovske tvrtke. Tih desetak lidera koji su izabrani iz UX-a, inženjeringa i upravljanja proizvodima predstavljali su širi tim od oko 150 drugih koji rade na ovoj liniji proizvoda. Kao jedinica, nedavno su krenuli na put kako bi postali "okretni."

Ovo nije situacija u Transformaciji poduzeća. Nemaju izričitu podršku ni obeshrabrenje starijih rukovoditelja. Službeni korporativni stav o Agileu u ovoj tvrtki najbolje se opisuje kao dobroćudna ravnodušnost. Dakle, oni su manje ili više sami da to isprobaju ili ili uspiju ili ne uspiju.

Jedini razlog što sam bio tamo, kao što je prilično tipično za mene, je taj što do sada nije išlo dobro. Moja uloga je bila da im pomognem da shvate zašto i kako bi ih se riješio. Kao što se događa, oni propadaju iz istog popisa razloga kao i svaki drugi tim s kojim sam se susreo u posljednjih 5 godina.

Evo tih razloga. Radi jednostavnosti, to su napisane kao nepristojne, stvarne izjave. Neće se svi odnositi na vašu situaciju.

1. Ne postoji jasna vizija proizvoda.

Ako biste zaustavili bilo koga od članova tima u hodniku i pitali, "što je dugoročna vizija našeg proizvoda", bi li oni mogli to artikulirati u jednoj ili dvije rečenice? Naravno da ne. Možda znaju malo o ciljnom kupcu. Oni se zasigurno mogu pontificirati svjesno o značajkama rješenja. Ali mogu li stvarno reći kakvu točku boli ima kupac koju pokušava riješiti? Valjda ne.

"Ideju" je predao neki visoki rukovoditelj temeljen na epifaniji tijekom povlačenja rukovodstva. To je bačeno na Thunderdome-ovu sjednicu planiranja proračuna, a ova je izvršna vlast pobijedila u bitci za utjecaj i financirala njihov projekt za kućne ljubimce 12 mjeseci. Vijesti su vam dostavljene kao stvarno usklađena Power Point prezentacija sa svim unaprijed planiranim resursima, značajkama i vremenskim rokovima. Rečeno vam je učinkovito samo „nastavite graditi“. Sada pokušavate povući taj nemogući zadatak i nadajući se da će vam Agile pomoći.

Rješenje: potrošite neko vrijeme artikulirajući jasnu viziju proizvoda. Upotrijebite poslovni model ili mršavo platno da biste zabilježili svoje pretpostavke. Pozovite sve u timu da sudjeluju. Vratite te pretpostavke višem rukovodstvu (ako je odbio prisustvovati sebi) i uvjerite se da ste na istoj stranici.

PS: Ako vam ugriznu glavu, nazovite me.

2. Poslovni pokazatelji su zamagljeni.

Tim ne razmišlja o troškovima i prihodima svakodnevno. Zapravo, tim vjerojatno ne zna koliko košta tvrtku da bi sve ostale u njoj. Oni ne znaju koliko kupaca trebaju, plaćajući koliko u vremenskom razdoblju, kako bi se slomili čak i na ovoj ludoj ideji. U osnovi, ne razmišljaju puno odakle dolaze njihove plaće.

Ako biste tražili većinu startupa, oni imaju puno bolju predodžbu o njihovoj ukupnoj stopi spaljivanja i prodajnom učinku, jer su prihodi i profitabilnost uvijek vrhunski. To je rijetko ikad točno u poduzećima.

To u svakom slučaju nije tako teško izračunati. U stvari, kad se pritisnu, voditelji linija obično za nekoliko minuta mogu doći do točne brojke za brzinu opeklina svog inženjerskog tima. Kad zatim usporedimo tu cifru (što zapravo koštamo) s našim trenutnim podacima o prodaji (koliki prihod zapravo ostvarujemo kao tim), to je potpuno nova igra s loptom.

Rješenje: izračunajte prihode i troškove svog tima koji su potrebni za uspješnost vašeg proizvoda i pobrinite se da to svi znaju. Može biti prilično otvoreno za oči. Pokušajte to pokušati sa svojim timom na sljedećem sastanku planiranja.

3. Nastavljate se miješati.

Kad ste posljednji put prekinuli normalan tijek posla zbog neke hitne promjene smjera. To bi moglo biti bilo što, od nedavne žalbe ili zahtjeva kupca, do snažno e-pošte od CEO-a o shemi boja korištenoj na prošlotjednoj demonstraciji proizvoda.

U svakom slučaju, ako redovito prekidate tijek, izazivate ogroman stres na tim. Taj se stres pretvara u sporiji protok, niži moral, veći promet, odgode isporuke, nespretnu izradu i općeniti utjecaj na rad tima.

Dakle, izrezati. Ne možete dobiti posebne privilegije u shemi prioriteta samo zato što ste važniji na org ljestvici.

Rješenje: Svaki tjedan izdvojite neki kapacitet za neplanirani rad, recimo 20% vašeg ukupnog kapaciteta. To znači, zakažite samo 80% vremena svog tima, a ostatak ostavite neplanirano. Taj se kapacitet može primijeniti u slučaju "hitnih slučajeva" bez utjecaja na raspored. Koristite ga za otplatu tehničkog duga kad god to zatraži. Za to možete rotirati članove tima.

4. Vaši timovi nisu posvećeni.

Ovo je velika stvar za mene. Svaka velika tvrtka s kojom radim ima ovaj problem. Većina ljudi na projektu dodijeljena je višestrukim drugim projektima. Na pitanje tko je u timu, dobivam odgovore poput da je inženjer So-i-So dodijeljen 50%, a inženjer Što je njeno ime je s nama 20% svog vremena. Više od polovice ljudi na projektu troši više od polovice svog vremena na druge projekte. Nije ni čudo što je olupina vlaka!

Ovaj. Ne. Raditi.

Agilni timovi moraju biti posvećeni. Koliko startup timova znate odakle polovina inženjera radi u nekom drugom startup-u 50% vremena? Odgovorit ću vam. NIŠTA!

Razvoj proizvoda je timski sport. Potrebna je velika usredotočenost i puno komunikacije i koordinacije između članova tima. Svaka osoba iz vašeg tima, koja je također dio određenog projekta dio svog vremena, dodaje značajno kašnjenje na datum isporuke, mjereno vjerovatno u tjednima ili mjesecima.

A budući da me menadžeri u poduzeću sada više guraju nego bilo koji drugi, dat ću vam konkretan primjer:

Vi pitate: "Trebamo li zaista posvećenu NX osobu u timu? Što ako miruju pola vremena? Zar ne gubimo novac? Priznajte, to ste već rekli.

Razmislimo.

Imate deset inženjera i jednog dizajnera interakcija (ne biste trebali imati ovaj omjer 1/10, ali vjerovatno jeste, pa idemo s tim). Dizajner gradi žičane okvire koje će inženjeri implementirati, recimo 100 njih. Sada imate 10 inženjera koji prolaze, a dizajner se vraća svojim drugim projektima.
Gotovo odmah, inženjeru je potrebno pojašnjenje. Uputili su zahtjev dizajneru, ali dizajner je vezan, pa inženjer mora čekati (odgoditi). Možda inženjer otvori neki drugi zadatak i počne raditi. Kad se dizajn vrati na mrežu, inženjer će morati zadati taj drugi zadatak kako bi ponovno otvorio prvi (kašnjenje).
Sada, drugom inženjeru treba pomoć. A po mogućnosti i trećinu. Oboje čekaju previše (kašnjenje). Dizajner je ponovno dostupan i počinje raditi s prvim inženjerom, dok ostala dva čekaju u redu (kašnjenje). Zadaci druga dva sjede nedovršeno (kašnjenje). Sva tri inženjera izgubila su dio konteksta onoga na čemu su radili (kašnjenje).
U radu s prvim inženjerom, dizajner otkriva pogrešku u dizajnu i mora ažurirati svih 100 žičnih okvira (velika kašnjenja). Svaki inženjer sada mora zaustaviti i ponovno provjeriti svoj rad u skladu s novim dizajnom (velika kašnjenja). Dio koji je već obavljen mora se ukinuti i započeti iznova (veća kašnjenja).

Ideš li ili bih trebao nastaviti? Možete zamijeniti dizajnera u gornjem primjeru za pomoćnog programera API-ja za podupiranje, a on postaje još gori.

Rješenje: Organizirajte se u male, cross-funkcionalne, namjenske timove. Radite na malom nizu zadataka zajedno kao jedinica, a međusobno dobivajte povratne informacije i pojašnjenja.

5. Vaše ekipe nisu kolocirane.

Veliki poslovni timovi obično se sastoje od "resursa" (molim vas, pucajte mi jer ljude nazivam "resursima") iz velikog geografski raspoređenog bazena. Kao rezultat, timovi poduzeća za proizvode imaju članove u različitim vremenskim zonama. To koordinaciju čini vrlo sporom i skupom. Gornji primjer mogao bi se lako napisati kao primjer kroz geografske zone.

Ono što se događa kao rezultat je puno čekanja i slabe komunikacije. Vjernost komunikacije na daljinu nikada nije dobra kao licem u lice. Videopozivi to čine malo lakšim, ali to nije isto kao kad biste mogli zajedno pristupiti bijeloj ploči i skupiti stvari.

Rješenje: Stavite sve članove vašeg tima u istu sobu ili barem isti kat iste zgrade. Ako morate raditi s udaljenim ljudima, razdvojite zadatke prema Conwayevom zakonu, što znači da se zemljopisno podijelite na komponente (moduli s jasno definiranim sučeljima), a ne po funkcijama (dizajn, inženjering).

6. Vaš je tim prevelik.

Tipično je pronaći ogromne timove u poduzećima koja grade proizvode koji iskreno nisu tako sofisticirani. Timovi su toliko veliki iz različitih razloga, uglavnom imaju veze s činjenicom da rukovoditelji grade svoj ego oko zapovijedi velikim skupinama ljudi.

100 inženjera za izgradnju SaaS proizvoda? Ozbiljno?

Veći timovi su sporiji jer su troškovi koordinacije ogromni. Potrebno vam je više slojeva upravljanja, više sastanaka i više dokumentacije. Negativni učinak velikog tima na njegovu brzinu pogoršava se asimptotski kako raste.

Rješenje: Za izgradnju proizvoda u poduzeću trebali biste koristiti najmanji mogući tim. Ako to uspijete srušiti na nekoliko desetaka, ili čak jednu desetak, super vam ide.

7. Imate previše tehničkog duga.

Poduzeća imaju tendenciju da imaju puno starijih baza podataka. To nije stvarni razlog zašto se tehnički dug gomila za Agile poslovne timove. Kladio bih se da je većinu tehničkog duga u vašem trenutnom projektu tamo postavio vaš tim od početka vašeg trenutnog projekta, a ne da ga naslijedim pomoću starijih naslijeđenih sustava.

To je zato što, unatoč 15 godina ponavljanja zajednice Agile o važnosti tehničkih praksi (1) programiranja parova, (2) razvoja vođenog testom i (3) stalne integracije u pogledu kvalitete koda, vrlo je malo poslovni timovi zapravo rade bilo koju od ovih stvari.

Iz različitih razloga (što se uglavnom odnosi na prodaju „Agile“ rukovoditeljima velikih konzultantskih kompanija koje se usredotočuju na proces, ali ne i na tehničku izvrsnost), poduzetnički Agile timovi rijetko su prihvatili osnovne tehničke prakse koje Agile čine tako velikim na prvom mjestu.

Kao rezultat toga, imate velike inženjerske timove koji otjeraju loše dizajnirane i izvedene sustave, a zatim se sudaraju jedan u drugog tijekom svojih dugotrajnih i bolnih ciklusa otpuštanja.

Rješenje: U osnovi zaposlite "Ekstremno programiranje". Koristite tehničke prakse Agile, za ime Petea !! Nadalje, koristite moderne tehnološke alate i jezike izgrađene na umu Agile. Ako ste previše zabrinuti zbog rizika upotrebe ovih novih alata, jer smo "javna kompanija", Amazon vas već ruši. Sretno s tim.

8. Radite previše stvari istovremeno.

Upravo tamo s posvećenim timovima kritičnost je raditi nekoliko stvari istodobno i raditi ih vrlo dobro. Većina korporativnih timova, vjerojatno zato što imaju previše ljudi, imaju tendenciju da rade na desetinama značajki istovremeno.

Bilo bi vam puno bolje ograničenje ponavljanja ograničiti na nekoliko ključnih značajki na kojima svi u timu rade zajedno. Kanbanski jezik nazivamo ograničenjima „Rad u procesu“ (WIP). U suštini, stvarate okruženje za suradnju prisiljavajući brojne ljude da rade zajedno na istim stavkama. Zbog ograničenja WIP-a nitko ne smije pokrenuti novu stvar.

Rezultati su manje stvari u isto vrijeme što bolje i brže. Više timskog rada i suradnje. Viša kvaliteta i veći moral. Manje prepravki i manje pogrešaka.

Rješenje: Odmah implementirajte WIP ograničenja. Ako imate tim od 10 osoba, postavite WIP ograničenje na 5 stavki tako da su svi prisiljeni upariti se s nekim drugim. Vjerujte mi, bit ćete zaprepašteni.

9. Preduvijek je potrebno za implementaciju novog softvera.

Problem dugotrajne primjene povezan je s problemom onih naslijeđenih sustava za koje se većina poduzeća nalazi. Poduzeća obično imaju operativni tim koji je odgovoran za unos koda u proizvodnju. Ovi ljudi su obučeni kako bi osigurali da je kôd siguran, uspješan i funkcionalan prije nego što je odobreno za život na poslužiteljima tvrtki.

Opet, dok ste maziti ruke oko puštanja običnih smrtnih inženjera da rabe vlastiti kod u proizvodnji, tvrtke poput Amazona brzo kradu vašu tržnicu. Možda želite procijeniti rizik otvaranja proizvodnog pristupa inženjerskom timu s rizikom da nestanu na tržištu jer ste previše spori da biste reagirali na konkurentne prijetnje.

Rješenje: DevOps. Bilo koji inženjer trebao bi biti u mogućnosti pokrenuti novu razvojnu i testirajuću infrastrukturu u bilo kojem trenutku. Pokreti na proizvodnju trebali bi proći automatizirani postupak koji sadrži sve potrebne testove i odredbe.

10. Ostatak poduzeća je nesvjestan.

I konačno. Vaš "eksperiment" u Agileu, toliko važan za vas i tim, potpuno je isključen s bilo kojeg broja kritičnih funkcija koje će vam trebati kako biste obavili svoj posao. Govorim o nabavi, pravnom, marketinškom, kadrovskom i sličnom. Ako se morate pravovremeno uskladiti s nehiljivim dijelom organizacije, pred vama je svijet ozlijeđenih.

Mora postojati način rada s grupama izvan vašeg tima na način koji u potpunosti ne usporava vaše napore.

U zajednici Agile primjećujemo da naredbe odozgo prema dolje, isporučene iz C-paketa, Agile transformacija ne funkcioniraju. To je zato što osim ako ljudi na terenu ne budu kupljeni i uzbuđeni zbog promjene, to se neće držati. A niti jedno od drugoga odozdo, bez podrške izvršne vlasti.

Rješenje: U osnovi imate tri strategije za rješavanje Agile ne-Agile prijevoda, a sve morate raditi istovremeno.

  1. Vodite kontinuiranu kampanju utjecaja u vašoj organizaciji kako biste osvojili ključne pristaše na visokoj razini. Jamčim da u vašem poduzeću postoje drugi rukovoditelji i rukovoditelji koji također pokušavaju, ili razmišljaju o tome, da pokušaju Agile u nekom opsegu ili mjeri. Idi ih pronađi i sklopi saveze. To je, na kraju krajeva, kako se stvari događaju u velikim ljudskim institucijama. Korporacije nisu iznimka.
  2. Otkrijte što vam treba od ne-agilnih funkcionalnih grupa u vašoj organizaciji i obavezno razgovarajte s njima prije vremena. Recite im što radite, kako to funkcionira i najvažnije - kako će im posao olakšati posao s vama na način na koji tražite.
  3. Nemilosrdno je presjekao svoje ovisnosti. Ovaj dio je manje ili više pod vašom kontrolom. Nastojte upotrebljavati alate, infrastrukturu, marketinške materijale, pravni jezik ili bilo što drugo što vi i vaš tim možete sami izraditi, posuditi ili kupiti. Trebat će vremena da se to nastavi, pa biste trebali početi odmah.

Agile, Gotovo, super je

Ne, nisi lud što ovo pokušavaš. Zapravo, tvrdim da je to jedini način na koji ćete svoju tvrtku dovesti u konkurentnu poziciju, što ona treba biti za sljedeću generaciju. Alternativa je lagana - ili brza - smrt zbog manjih, bržih konkurenata.

Ako želite dobiti pomoć, uvijek me zanima kava ili telefonski poziv. Pusti mi crtu.

Budite bolji tehnološki lider

Prijavite se na majstorsku klasu za pokretanje modela za nove tehnološke lidere. Roll priznanja, ali prostor je ograničen. Primijeni sada.