Några grundprinciper för XP är att förbättra kommunikationen, sträva efter enkelhet, ge feedback och att alltid fortsätta framåt med mod.
Målet ska alltid vara att sträva efter att skapa något mindre extremt än man hade tidigare.

Upprätta en inception sprint (sprint 0 även kallad), där man fångar kraven på en högre nivå. Låt utvecklarna ta fram grova estimat och använd som underlag för planeringen. Sätt upp förutsättningar för att kunna övervaka projektet utifrån data från det verkliga arbetet och följ upp gjorda estimat med utfallet.

Var inte rädd för att ändra åtagandet i kommande sprint om det visat sig vara övermäktigt att leverera enligt tidigare åttaganden. Estimera om dina user storys om estimatet inte verkar stämma.

Använd klara, tydliga och avgränsade user stories, ha mindsetet att det endast finns klara (100%) eller ej klara (0%) user stories.

Flytta runt på personer om så är behövligt. Låt folk mingla och lära av varandra.

Skapa ”spikes”, dvs. små utredningar huruvida det går att lösa ett problem eller framtida krav på det sätt som man väntar sig.

Håll alltid reda på projektets ”truck number”, dvs. hur många oumbärliga projektmedlemmar som måste ”gå åt” för att projektet inte skulle kunna fortsätta.

Skapa inga svulstiga ramverk (frame works). Det bästa ”designverktyget” är en white board tillsammans med en digitalkamera, så att man kan ta en bild av det man ritat och kommmit fram till.

Parprogrammera! Det kostar 15% mer, men koden innehåller å andra sidan 15% färre buggar.

Testa att ping-pong-programmera, dvs. man skriver koden växelvis och får på så sätt större förståelse och kunskap av det som utvecklats.

Får ni någon gång möjlighet att lyssna till Neal Ford, gör det! En mycket kompetent och fantastiskt rolig föreläsare.

Precis som smeder för i världen gjorde verktyg, så gör även vi som utvecklar mjukvara det. Skillnaden är bara att våra verktyg inte görs av metall utan av 1:or och 0:or. Smederna satte stor ära i sin yrkesskicklighet och ägnade ofta ett helt liv till att förfina sin yrkesskicklighet. Det borde även vi göra oavsett om vi jobbar som programmerare, arkitekter eller med kravhantering. Vi borde ta varje tillfälle som ges att träna och lära oss av varandra.

Detta är just vad som är innebörden i ”Manifesto for Software Craftsmaship”.
http://manifesto.softwarecraftsmanship.org/

En man som tagit fasta på detta är Cory Haines. Genom att resa runt i USA och parprogrammera med många olika personer på olika företag vill han utvecklas både som yrkesman och människa. Läs hans intressanta historia här:
http://www.coreyhaines.com/

Här är några tips på hur du kan utveckla din yrkesskicklighet:

• Övning och åter övning med code katas & dojos.
• Studera kod från mästare (t.ex Fitnesse eller JRuby).
• Glöm aldrig att vara noggran (mitt eget tips).
• Parprogrammering och partestning.
• Var alltid nyfiken och öppen för nya ideer.

Alla som kan musik verkar vara överens om att Stradivarius var en mästare på sitt yrke (att göra fioler). Men han misslyckades med något väldigt viktigt. Han misslyckade nämligen med att överföra sin kunskap till någon som kunde ta över och fortsätta förfina hantverket. Gör inte om hans misstag, se till att dagligen dela med dig av din kunskap!

/Patrik

Men så till ämnet, varför fallerar införandet av agila arbetssätt och hur gör man istället?

De främsta orsakerna är:

• Dålig start,
• Bristfällig planering,
• Otillräcklig finansiering,
• Bristande kommunikation och
• Rädsla för förändring

För att komma till rätt med detta bör man:

• Vinna organisationens förtroende.
• Framhäv vad den enskilde har att vinna på det.
• Utbilda alla som finns i och kretsat kring projektet.
• Känna till vad förändring innebär, se SatirChange Model.
• Använd agila coacher (75% av projekten som saknar coacher misslyckas).
• Inför automatiska byggeni projektet (Continuous Integration).
• Inför automatiserade tester.
• Teamet testar det de anser relevant, inte det som står i ev. testfall.
• Bli bra på att skapa user stories.
• Bryt ner större funktionsområden i user stories.
• Användsmå user stories.
• Använd 1 vecka korta sprintar.
• Identifiera vad som går att göra bättre.
• Förbättra processen fortlöpande.
• Var transparent mot omvärlden.
• Gör ”quick wins”.
• Starta smått.
• Involvera ledning och asärskild personer som innehar ”stödfunktioner”, som ex. Configuration Management.
• Anpassa Human Resources-funktionerna efter agila arbetsätt.
• Uppdatera styrtalen så att se avspeglar detverkliga resultatet snarare än insatsen.
• Arkitekterna ska ingå i teamen.
• Inför incitament att dela med sig av kunskap.
• Teamen ska vara multifunktionella, där arkitekten ingår.

Ett föredrag bli inte effektivare och roligare än så här. En lysande dragning!

De olika teamen i de olika projekten ska alltid arbeta i samma cykler, så att projekten och dess team inte jobbar i otakt. I de fall ett projekt skulle kunna starta på nästa cykel, men samtidigt ev. kan vara beroende av resultatet av ett annat team eller projekt bör projektets team fokusera på att refaktorera eller utbilda sig istället. Använda tiden till att reducera den tekniska skulden och göra sig redo för framtiden i form av utbildning och dyl. med andra ord.

När man nått framgång med de agila arbetsätten i ett team bör man skala upp steg för steg, anser Mike. Man sprider framgångsfaktorerna från ett team till flera andra, från ett projekt till ett annat osv. Vartefter organisationen blir allt mer agil behöver man från ledningsnivå börja arbeta på samma sätt. Man tar på översta nivån fram vilka krav/affärsmöjligheter organisationen ska arbeta med framöver och prioriterar dessa. Inom respektive ”affärsområde” bryter man ner ledningens krav/möjligheter i ett antal projekt. I de respektive projekten fördelar man de nu detaljerade kraven över flera team, som sedan bryter ner kraven på en detaljnivå och implementerar dessa.

För att koordinera och kommunicera kraven/möjligheterna mellan de olika nivåerna skapas team med arkitekter och produktägare, som arbetar med riktlinjer och prioriteringar som kommuniceras till den ”underliggande” nivån. Viktigt att dessa endast jobbar med frågor som rör den nivå man arbetar på och inte detaljstyr underliggande nivåer.

Slutligen är det av yttersta vikt att teamen på de underliggande nivåerna ger återkoppling och förbättringsförslag ”uppåt” i organisationen för att överliggande nivåer ska kunna förbättra inputen till de underliggande teamen i framtiden. 

Läs mer av Cottmeyer i hans utmärkta blogg på:
http://www.leadingagile.com/

En viss grad av upptagenhet är nödvändigt i livet, för att försörja oss, lära oss saker och uppleva livet. Ofta bryter det dock ner oss vi blir ständigt upptagna och vi lägger mängder av energi utan att uppnå något alls.
Att göra mindre handlar om att stanna upp och reflektera när upptagenheten är påtaglig. De faktorer som hindrar oss från att just göra mindre hävdar Marc är rädsla, antaganden, distraktioner, motstånd och upptagenhet.
Grundfilosofin i mycket att det Marc berättar om återfinner man sannolikt i zen-grenen av Mahayanabuddhismen från 500-talet.

Marc har även skrivit en bok ämnet, som vi förövrigt fick och som man kan läsa mer om här:
http://www.accomplishingmorebydoingless.com/

Vill man se en variant av föredraget hittar man det här:
http://www.youtube.com/watch?v=4OJqMPRYqOU

Avslutar med ett tänkvärt citat från sessionen lånat av Shunryu Suzuki-Roshi: ”You are perfect as you are, and you could use a little improvement” .

http://www.oredev.se