Astăzi, în mediul de afaceri, colaborarea nu mai este opțională— este un avantaj competitiv și factor critic pentru inovare. Cu toate acestea, multe organizații se confruntă cu o abordare compartimentată/izolată (mentalitate de solz), în care departamentele sau echipele operează izolat, nereușind să împărtășească informații, să se alinieze la obiective sau să colaboreze eficient.
Liniște. Se aud doar tastele apăsate. Oamenii în birou lucrează. E dimineață, a trecut ora de cafea, toată lumea e conectată.
Se aude o voce. E Vlad, care tocmai iese dintr-o sală de ședințe: "Ați auzit? Trecem la Agile, începem de pe 1 octombrie."
Andrei întreabă: "Ce presupune asta? O să fim mutați din echipele din care suntem?"
Lumea începe să discute din ce în ce mai interesată de subiect.
În ultimii șase ani am aplicat Design Thinking în diferite contexte, de la proiecte greenfield pornite de la zero, la modernizări de soluții existente sau în procesul de inovație. Ne-am lovit de multe piedici și priviri întrebătoare, dar am avut colegi și clienți care ne-au spus “Aha, acum înțeleg de ce ați procedat așa.” Poate cel mai important lucru pe care l-am demonstrat aplicând aceste principii și instrumente se referă la faptul că este mult mai valoros să începi să testezi ceva imperfect cu utilizatori reali și să afli cât mai repede ce nu funcționează - principiul agil de a eșua rapid (fail fast). Odată cu democratizarea instrumentelor AI, acest lucru a devenit mult mai rapid și mai simplu, iar validarea ideilor se face acum mult mai rapid.
În timp ce design thinking a câștigat apreciere pe scară largă ca o abordare puternică, inovatoare, centrată pe utilizator, popularitatea sa a condus și la o dependență excesivă care poate, uneori, să împiedice mai degrabă decât să ajute procesul de dezvoltare a produsului. Promovată ca o metodologie accesibilă și aplicabilă universal, design thinking dă adesea impresia că oricine o poate implementa eficient și că rezultatele vor fi mereu de înaltă calitate.
În cadrul metodologiei Agile, și mai ales în Scrum, Scrum Master-ul are un rol cheie în buna funcționare a echipei. Nu este doar un facilitator al proceselor, ci un lider servant care inspiră, sprijină și ajută echipa să-și atingă obiectivele. Cu toate acestea, opiniile despre acest rol sunt diverse: unii îl văd ca pe un aliat de încredere, mereu gata să dea o mână de ajutor, în timp ce alții îl percep ca pe o provocare suplimentară sau o piedică administrativă.
Oboiul și locurile sale limitate în orchestre sunt exemplu folosit pentru a ilustra o situație în care există mai mulți oameni calificați decât oportunități disponibile într-un anumit domeniu sau loc de muncă. În acest context, exemplul se referă la dificultatea pe care o au muzicienii de a-și găsi un loc într-o orchestră, deoarece există foarte puține poziții disponibile pentru fiecare instrument în comparație cu numărul mare de muzicieni talentați. Soluțiile propuse pentru astfel de situații se concentrează pe extinderea oportunităților și pe diversificarea rolurilor. În cazul orchestrelor, aceasta ar putea include crearea de noi ansambluri muzicale, promovarea educației muzicale pentru a dezvolta abilități complementare sau explorarea unor cariere alternative legate de muzică, cum ar fi predatul sau compoziția. În general, soluțiile se bazează pe adaptarea la contextul limitat al locurilor disponibile și pe găsirea unor alternative care să permită valorificarea talentelor în alte moduri.
În ultimul timp, vorbim tot mai des despre schimbări și incertitudini, nu doar în industria IT, ci în multe alte domenii. Deși traversăm o perioadă dificilă la nivel global și local, este important să conștientizăm că, în funcție de anumite caracteristici, astfel de momente pot trece mai ușor sau chiar pot deveni oportunități de creștere și dezvoltare.
Mă uit la un film. Oamenii se ceartă, la muncă, de nu mai știu de ei. Mă uit la ei și mă gândesc: “Ce faini sunt oamenii aștia! Ce legătură puternică între ei! Mi-e dor să mă cert fain cu cineva la lucru. Să mă cert cu folos!”. Știu că pare ciudat ce am zis, dar voi explica imediat. Anul trecut am scris despre cât de important este umorul ca parte a unei culturi de lucru performante. Azi, am să țin o pledoarie pentru ceartă, dar nu orice fel de ceartă, ci una constructivă.
Estimarea în proiectele Agile este un subiect controversat și parte a unei dezbateri nesfârșite. O bună parte dintre cei care activează în diverse echipe de proiect nu înțeleg de ce anume avem nevoie de o abordare diferită în estimare. De ce estimarea în timp (și eventual în valoarea în bani asociată acestui timp) nu este una potrivită într-un context agil. De-a lungul timpul s-a vorbit de tehnici și instrumente tot mai sofisticate sau chiar exotice, începând cu binecunoscutele Story Points, T-shirt Sizes, Planning Poker sau Estimarea prin Afinitatea și continuând cu mult mai neobișnuitele Puncte Zoo sau #noestimates. În continuare nu este însă clar cum ar trebui să le integrăm în viața unei echipe Agile, care este valoarea pe care acestea o aduc unei astfel de echipe și cum afectează ele modul în care comunicăm clientului planul și progresul proiectului.
Reddit este o sursă inepuizabilă de onestitate contondentă. Comentariile despre muncă și proceduri nu sunt doar brutal de sincere, sunt și exprimate într-un limbaj colorat (ca să folosesc un eufemism). Nu face excepție nici subiectul Agile, sau Anti-Agile, așa că l-am folosit ca sursă de inspirație (ei, nu vă așteptați acum să fi preluat tot textul, l-am cenzurat, păstrând totuși esența). Cum Reddit nu dezamăgește niciodată când vine vorba de expresivitate, vă las să vă folosiți imaginația pentru părțile „bip-bip”.