Fail with agile [short version]
•Als PPTX, PDF herunterladen•
2 gefällt mir•512 views
How to fail with agile (or not)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Fail with agile [short version]
- 1. MISSLYCKAS MED AGILA METODER
- 2. Patrik Falk
- 4. >10år med agil utveckling
- 5. Adaptive Software Development (ASD) Agile Unified Process (AUP) Crystal Methods (Crystal Clear) Dynamic Systems Development Method (DSDM) Extreme Programming (XP) Feature Driven Development (FDD) Kanban Lean software development Scrum Scrum-ban Extreme Programming (XP) Kanban Lean software development Scrum
- 7. Individer och interaktioner framför processer och verktyg Fungerande programvara framför omfattande dokumentation Kundsamarbete framför kontraktsförhandling Anpassning till förändring framför att följa en plan
- 11. LEVERERA OFTA 3
- 18. ENKELHET 10
- 21. FOKUS PÅ TEAM WORK
- 22. FÖLJ INTE DOM AGILA PROCESSERNA
- 23. SKAPA SILOS
- 24. DELA INTE PÅ ROLLER
- 26. BERÄTTA INTE DIN VISION
- 32. "IT IS NOT NECESSARY TO CHANGE, SURVIVAL IS NOT MANDATORY." Dr. W. Edwards Deming
Hinweis der Redaktion
- Jag heter Patrik Falk, jag är java utvecklare men fuskar ibland i andra språk också.
- Jag har 20 år i branschen
- Jobbat 10 år med agil utveckling, som både utvecklare och coach. Under denna tid har det kommit väldigt många agila metoder.
- Jag gick in i väggen för 13 år sedan och har sedan dess varit väldigt intresserad av ledarskap och team utveckling och lägger därför en hel del tid av min fritid som instruktör och ordförande i både Malmö Sportdykarklubb och SSDF.
- Men dom jag har fokuserat på är Kanban, LEAN, XP och Scrum
- När jag blev introducerad till mitt första AGILA projekt så måste jag erkänna att jag inte förstod hur det skulle kunna fungera, kändes väldigt flummigt och jag var van vid det här laget att jobba efter command & controll metoden.
- När jag först läste det agila manifestet så läste jag det som att det till vänster var värdefullt och det till höger skulle vi undvika till varje pris, men det vi säger är ju att vi värdesätter det till vänster mer än det till höger. Alltså vi ska inte sätta upp verktyg för att undvika interaktioner mellan individer. Men redan efter några sprintar in i projektet så upptäckte jag att min attityd hade ändrats och jag började älska det, det var fartfyllt, engagerande och samtidigt lite skrämmande och….
- jag började förstå varför dom 12 grundprinciperna fanns. Jag började bli nyfiken på varför dom fungerade, vilket ledde till att jag började läsa en massa böcker om motivation och hur man bygger team. Efter ett tag insåg jag att storheten ligger inte i själva ramverket, utan värderingarna som styr ramverket.
- Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans
- Vi välkomnar förändringar i krav, även sent i utvecklingen. Att vi kan ändra prioritet är till fördel för kundens konkurrenskraftighet.
- Leverera fungerande programvara ofta, från ett par veckor till ett par månader, med en förkärlek till den kortare tidsperioden.
- Affärsfolk och utvecklare måste arbeta tillsammans dagligen under hela projektet.
- Bygg upp projektet runt motiverade individer. Ge dem den miljö och det stöd de behöver, och lita på dem för att få jobbet gjort.
- Den mest effektiva metoden för att förmedla information är genom konversation på plats mellan individerna.
- En fungerande programvara är det huvudsakliga måttet på framsteg.
- Vi ska kunna hålla en jämn utvecklingstakt på obestämd tid.
- Kontinuerlig uppmärksamhet på teknisk kvalitet och god design vilket ökar flexibiliteten.
- Konsten att maximera mängden arbete som inte görs är viktigt.
- Att det egna ansvaret och motivationen växer när man känner sig delaktig och har möjlighet att organisera sitt eget arbete.
- Teamet ser över med jämna mellanrum hur man ska blir mer effektiva, sedan finjusteras och anpassar sitt beteende därefter.
- Jag älskar att jobba i Agila metoder, dom fokuserar mycket på teamet och samarbete mellan människor genom hela organisationen. Tyvärr så springer vi i en hel del fallgropar för att vi ibland inte tar oss den tid som krävs eller orkar göra förändringar för att få dom effekter som man kan förvänta sig från ett agilt team.
- Ställa dom rätta frågorna Våga ställa upp dom tuffa frågorna Duktiga på att starta projekt – vet inte riktigt vart vi är på väg När vi ändå är inne på vision och mål så finns det bra forskning som visar att dom flesta projekt är dödsdömda redan innan dom startar! Man har inte ställt dom rätta frågorna och eller vågat ställa dom tuffa frågorna. Detta är gemensamt för alla projektmetoder, och är inte ett Agilt problem, men av någon anledning så har det blivit lättare att starta utveckling innan man har arbetat fram en tydlig målbild och vision med projektet… Vi kommer igång snabbare, men vet inte riktigt var vi är på väg.
- Vad som dödar dessa projekt är att människor har olika bilder om hur framgång ser ut, man har inte samma förväntningar och man kommunicerar ut dåligt till organisationen och projektmedlemmarna vad det är man vill uppnå. Man startar projektet innan alla är ombord och man tror det finns konsensus där inget existerar, det leder till att många försöker definiera sina egna mål och visioner. Man vill gärna veta vad det är man köper, fast man inte själv kan beskriva det man vill ha, för man vet inte vad det är ännu. Man försöker sedan sätta upp kvantifierbara mål, söka förutsägbarhet och inte tillåta misstag i projekt. ----- Mötesanteckningar (2013-11-20 20.22) ----- Ej nämna kund Akamai förklara använd de
- Team Work är ett val, ett strategiskt beslut, tyvärr ser vi ofta det som en standard, - är vi ett team? ja vi är ett team, vi sitter ju i samma rum ju! Det har blivit politiskt korrekt att säga att man är ett team idag och det gör att vi många slutar tänka på vad det innebär, vad är kostnaden. Sanningen är den att om vi ska kunna operera som ett team, så måste vi aktivt välja att jobba som ett team och jobba för det; vi behöver planera för tiden, kostnaderna och göra dom uppoffringar som det kostar att jobba med människor. När en grupp av människor inte väljer att investera i varandra och göra dom uppoffringar som krävs för att uppnå fördelarna, då är det oftast bättre att säga att vi inte ska vara ett team. Detsamma gäller för Agil utveckling, vill vi göra ett medvetet och aktivt val, eller hoppas vi på slumpen.
- Ofta ser jag att man startar direkt med att ändra ramverket och dom processer som är uppsatta innan man har skaffat sig erfarenhet och kunskap om varför det fungerar. Har varit med om där man har tagit bort tex retrospective för att spara tid. Eller inte ta med PO i planeringen för att dom har viktigare saker o göra. Viktigt att förstå ramverket innan du börjar ändra på den, och gör det först när du är medveten om riskerna och när du kan förutspå ett förväntat resultat.
- Det är lätt att vilja skydda teamet eller någon viktig projektresurs, men det viktiga är ju att informationen får flöda fritt, det betyder ju inte att man kan ändra krav mitt i en sprint eller sitta och störa teamet med saker som inte har med sprinten att göra. Men även inom teamet kan man bygga silos: Om alla sitter och är experter på en egen del av systemet, så slutar kommunikationen att flöda och det är svårt estimera eller dela med sig av information när det varje gång krävs minst två experter som slåss för sitt område. Viktigt att komma ihåg att faller en faller alla, inkl stake holders och produktägare som har satsat pengar och anseende. Hjälp varandra! Om PO har problem med krav, hjälp henne att skriva dom! Om test inte hinner med, hjälp till att testa. Om utvecklarna misslyckas sprint efter sprint, ta ett steg tillbaka.
- Att inneha flera roller i ett projekt är ingen bra ide. Det går bra tills den dag det uppstår en konflikt mellan rollerna eller det börjar bli stressigt i ett projekt.
- Underminera teamet genom att inte ha delat ansvar; Individuella incitament (bonusar), Tävlingar Tyvärr har jag stött på där man har haft olika bonusar på individuella prestationer. Man bör vara försiktig med tävlingar, det kan skapa osämja och dålig stämning. Speciellt när jag är i teamet, jag är en usel vinnare.
- Om du är produktägare så kan du låta bli att dela med dig av din plan, låt den vara i ett dokument på din dator eller i ditt huvud Satt i ett projekt där vi skulle bygga en prototyp på 6 veckor, hade inte ens budget för server - körde på min NAS, Service Manager ville ha Geografisk partionering via Akamai nätverk. Se till att alla vet vad målet är; Sätt upp den på väggen, Intranätet, tryck upp tröjor eller möss underlägg. Kommunicera även till stake holders
- Ett annat sätt att öka på chansen att misslyckas är att låta teamet prioriteta åt dig, utvecklare har inte hela bilden och kanske inte har samma mål som företaget. Om du är produktägare och vill lyckas så är det viktigt att prioritera jobbet. För några år sedan så berättade en linjechef för mig att allt var lika viktigt så man införde vad han kallade för rak prioritering, 12 projekt på 4 utvecklare…. samtidigt Du kanske har ett väldigt duktig team som delar din vision och förstår din affär, men om du inte har det - hjälp teamet med prioriteringarna!
- Om du vill att utvecklarna ska tappa motivation så kan du som produkt ägare välja att inte gå på Sprint planeringen eller Sprint demo:t. Om du inte visar intresse så tror inte teamet att du värderar deras jobb och bryr dig om projektet, så varför ska dom bry sig. Viktigt att kommunicera och ge ledning, även om gruppen verkar klara sig själv. Kommunikation är viktigt, speciellt feedback
- Som team finns det också recept för att misslyckas; Att aldrig leverera rätt funktionalitet, under estimerar sprinten, och inte lär av sina misstag (t ex deploy problem) Produktägaren får svårt att planera och göra externa åtagande mot tex marknadsavdelningen eller kunder Produktägaren i värsta fall tappar förtroendet för teamet och den Agila metoden.
- Förbättra er kontinuerligt Stanna inte er egen utveckling Utmana er själva och andra team Bli inte komfortabel i gamla rutiner
- Tyvärr händer det ofta att team lämnas vind för våg Man sätter likhetstecken mellan självorganisering och självledande. Själv organisering = det dagliga arbetet Ett team behöver Guidning, Vision, Motivation, Feedback
- Innan jag lämnar scenen så vill jag slå ett slag för två böcker som jag har haft med mig på vägen! Five dysfunctions of a team med Patrick Lencioni Drive av Daniel Pink Det är inga böcker om agila metoder men handlar om den ”mjuka” vetenskap och tekniker bakom att bygga team och få människor att samarbeta.
- Jag tackar så mycket för att ni har kommit ut o lyssnat på oss, jag vill avsluta med ett av mina favorit citat ”It’s not necessary to change, Survival is not mandatory” Tack så mycket!