Păcatul nu este întotdeauna o idee rea. Cu moderație, poate aduce valoare, dar odată practicat în exces devine un antipattern. Conform lui Jim Coplien, un antipattern este o categorie formală care identifică o soluție frecventă și uzuală la o problemă care generează consecințe negative evidente. Dezvoltarea agilă este despre învățare sau despre cum să ne valorificăm intelectul pentru a vedea cum putem să ne perfecționăm.
De multe ori, rapoartele de status arată că totul este "Verde", că progresul înregistrat este expresia celei mai bune forme posibile de progres. Dar o mentalitate agile aduce mai multă transparență privind livrarea muncii și furnizează incremental ceea ce aduce valoare. În acest sens, responsabilitatea de a identifica progresul nu-i revine doar Managerului de proiect sau Scrum Masterului, ci și echipei în ansamblu, implicată și ea în colectarea datelor care reflectă progresul.
De cele mai multe ori, enunțul de mai sus este acompaniat de satisfacția celui care și-a făcut partea lui de treabă. Și atât.. Dar principiile agile determină ca membrii echipei să colaboreze și să își împartă răspunderea, transformând un enunț precum "Partea mea este făcută" în "Ce altceva pot să fac pentru a ajuta echipa?"
Sursa: https://i.pinimg.com/originals/a0/c5/de/a0c5de80ea758f3254644b7d28370ac6.jpg
O viteză a sprint-ului mare și foarte mare este frecvent un obiectiv în sine. Atingerea unui asemenea obiectiv se înscrie frecvent în rândul preocupărilor principale. Se obține temporar o velocitate crescută. Dar prin sacrificarea calității. Echipele cu adevărat performante nu permit acest lucru, se concentrează pe stabilitatea pe termen lung și pe livrarea de calitate. A te concentra asupra creșterii velocității în detrimentul calității desemnează un antipattern evident.
Uneltele ne permit să facem atât de multe și ajungem să supra-utilizăm un instrument, pentru a îmbunătăți rapoarte și documentele, când tot ce are nevoie businessul este de a livra produse. Iterațiile sunt artefacte, iar ceea ce obținem prin releaseuri este chiar să dăm ceva funcțional în mâna clientului.
Am constatat că este o provocare faptul că alegem să ne preocupăm mai mult de graficele de Burn-down decât de release-uri. Ceea ce ar trebui să ne interesezs cu adevărat este să înțelegem modul în care munca noastră aduce valoare. Există un grafic care să arate cât de mult scopul va fi livrat într-un release, ca un Burn-Up? Ne concentrăm asupra ce contează pentru un Burn-Up de release?
Release Burn Up. Sursa: https://help.rallydev.com/progress-reports
Există o mulțime de moduri în care putem colecta "metrici bune".
Cum arată acestea? Sunt metricile ușor de înșelat pentru a obține rezultatul dorit. O posibilă "metrică bună" ar putea fi numărul de iterații, unde ne-am îndeplinit angajamentul.
Cum putem înșela? Ne asigurăm că nu promitem să livrăm prea mult.
Dacă există o metrică ușor de înșelat, știți ce se va întâmpla? Echipele dumneavoastră vor trișa pentru a arăta o valoare cât mai bună.
Ceea ce vrem cu adevărat să inducem, este crearea de metrici ce ne permit să luăm decizii, deoarece nu există niciun beneficiu în a înșela. Dacă trișăm, ne înșelăm pe noi în a lua o decizie. Deci, ceea ce intenționăm este ca echipele să aibă metrici pe care să le putem folosi în luarea deciziilor.
Sursa: http://waltdisney.org/exhibitions/snow-white-and-seven-dwarfs-creation-classic
Ceea ce ne dorim cu adevărat să facem este să inspirăm mari lideri și un leadership adevărat.
Avem lideri care încearcă să controleze inputurile? Dacă privim dintr-o perspectivă a fluxului de proces, avem inputuri și procese, dacă vom încerca să controlăm inputurile și procesele, care de altfel sunt foarte concentrate pe micro-management, vom avea un sistem în care putem prezice ușor care vor fi outputurile știind inputurile. Viziunea Leadershipului Agil este de a inversa acest mers.
Sursa: https://ro.pinterest.com/pin/369928556882939125/
Procesele de control anticipat sunt folosite pentru procese foarte simple. Sistemele de control a proceselor de buclă de feedback sunt foarte stabile în medii foarte complexe. În dezvoltarea de software avem un mediu foarte complex, care își crește stabilitatea prin aplicarea unui mecanism de feedback. Despre aceasta este vorba în agilitate.
Concentrați-vă pe învățare și feedbackul vă va aduce mai multă valoare.
