Agila Sverige 2013

No Gravatar

Sitter på tåget på väg hem från Agila Sverige 2013. Det har varit två underbara och uttröttande dagar, med mängder med trevligt, kompetent folk, bra blixttal och öppna, givande diskussioner och dialoger.

Egna insatsen

Fredrik Wendt: Coding Dojos för företag
Jag var först ut, hade inte presentatörsanteckningarna framför mig vilket var tvärtemot vad jag fick mail om dagen innan, men bortsett att det blev lite mindre fokuserat och tydlig röd tråd så tror jag att det viktigaste sades.

Open space-session på temat “Hur lär man ut TDD?”

(Kallas också rundabords-diskussioner, ofta utan bord.) Jag deltog i ett par open space (kallades open X)-sessioner men förde bara anteckningar från en där frågeställningen var Hur lär man ut TDD? Det var inte jag som som föreslog ämnet men deltog och försökte erbjuda så konkreta tips på idéer till den/de som sökte svar och inspiration eller bara nya (eller gamla) tankar.

  • + training, education
  • ? how do I get colleagues to see the benefit of it?
  • ! forced for a short period where you see the end of the period, one sprint/2 weeks
  • ! re-allocate some of the devs to a team where TDD is heavily used
  • ! move away from too simplistic katas, people have a too hard time transfering what they’ve seen/learned to production (Emily: this was NOT me saying this, brought up by someone else based on experiences from other teams and devs! :-)
  • ? hard to start when what you’re starting your journey from/off of/on/what you have is untestable legacy code
  • ! book: M Feather’s Working With Legacy Code
  • ? more on what’s the benefit of TDD in your view?
    I answered that almost everyone agree that pre-production tests, such as a unit test suite, is of great value.
    If you use TDD as means to get more readable, usable, understandable, maintainable code – then that’s your benefit. But it’s not the only way to get there, TDD is not the silver bullet solution to everything.
  • ? what are the arguments against TDD?
    Can’t use it blindly, might be hard transition/initially. Should/may not be used for spikes.
  • ! book: Kent Beck’s Test-Driven Development by Example

Övriga personliga diverse anteckningar och doodles

Ann-Louise Ulfsparre och Fredrik Josliden: Kommunikation mellan team, javisst! Men, hur då?
Story points samma mellan team? Grooming utan O? Slå ip team fungerade bra. Skall prövas!

Johan Dewe: Så fick vi alla att räcka upp handen
Om att rulla ut agil utvecklingsprocess utan att kalla den agil. “Roll your own vs try what’s been known to work”?
Rubrik “att få alla att räcka upp handen”, efter en egen introduktionskurs (liknande CSM dag 1, PSF, …) med folk från blandade verksamhetsfunktioner så fick alla frågan “Vilka håller på med systemutveckling?”. (Alla förstod sin del och att det var en del av det hela.)

Jonas Hermansson: Acceptanstest är töntigt
Acceptanstestare är ofta för välbekanta med testobjektet – fundera över vem som gör acceptanstestet och konsekvenser av det. Mycket humor, kul presenterat! En klar topp 3 för mig.

Kajsa Goffrich: RTFM – varför är vi så snåla med kunskap?
Vi håller inne med kunskap som Joakim von Anka håller sina pengar i sin pengabinge, varför? Agil metodik leder till att vi jobbar öppet och talar ut om “jag har kört fast, tar tid, har problem”, men hur bemöts det? Vilken inställningar har vi till detta? “Jag har blockering – skall givetvis ses som att det teamet som har en blockering, inte en individ”. “Jag är inte korkad, jag har bara inte lärt mig det än”.

Inga-Lill Holmqvist: Servant Leadership – passar bra ihop med Agile och Lean?
Att tänka “du är viktigare än jag”, som chef. Mät: “Växer personen som jag servar?”
Aktivt lyssnande; Empati; Läkande; Awareness (self, organizational); Bygga konsesus vs auktoritativ beslutsfattande; Foresight; Stewardship (översattes till förvaltarskap :-P ); Bygga gemenskap (community).
(Ja, allt detta passar mycket bra ihop med Lean och Agile.)

Matti Klasson: DevOps – ett sätt att samverka inte en jobbtitel!
Mixade team, praktisera i annan roll. Automatisering och verktyg är inte lösningen – lösningen är samverkande människor.

Annica Söder och Anna Forss: Hur vi undvek att bygga Dödsstjärnan
Jämförde Star wars- och Star Trek-stil, dvs magi, hjältar och ikoner med vetenskapliga teorier, samverkan och team.
10000 stormtroopers vs teamet “on the bridge”; Yoda vs Spock (mer vetenskapligt); dödsstjärnan vs enterprise (doable scope); mötet där Darth nästan stryper en amiral vs star trek-öl i restaurangen på skeppet (refletion meetings)
Seldon plan.

Thomas Nilsson: 13 steg mot Kanban Kaizen
Kändes lite för basic, men passade säkert många andra. Bra take away: se till att välja ord – det är lättare att “genomföra ett litet experiment under 2 veckor” vs “nu skall vi förändra våra arbetsmetoder”.

Annika Widmark: Om att lösa komplexa problem med enkla bilder
Storytelling, visualisera förändringsarbetet. Gather facts, group facts, imagine goal, show/visualize/draw. En av flera presentationer som tycker att tre kugghjul visar på något som snurrar (tre kugghjul som rör varandra kan aldrig snurra).
Glömde fråga om de foldrar som tagits fram hos Arbetsförmedlingen om erfarenheter om bra metoder/framgångar från projekt har lämnats ut publikt (tillbaka till skattebetalarna).
Bok: Back of the napkin, Dan Roam

Daniel Fröding: Continuous Delivery – On the road to a true agile company
itrevolution.com. Bra budskap. Använde karaktären Mr Business som gav beståeende men/intryck ;-)

Labbet – Continuous Delivery Pipeline

Andra halvan av dag ett var open X och jag valde att spendera tid i “labbet” med bl a Mattias Karlsson, Mikael Sennerholm och Johan Elmström från Avega Group (Enzo). De hade med ett par saker in, dvs förberett ett par saker såsom CI-, test- och prod-VM:ar, (Jenkins, Tomcat, Puppet, GitHub) men framför allt härlig öppenhet och vilja att lyckas utan att ta för mycket fula genvägar.

I korthet så fick vi något som fungerade, men ingen av oss helt “färdiga” (uppstädning) och ej heller helt nöjda med teknikstacken. Jag skall kanske inte tala för de andra men Jenkins och sina plugins (jag läste källkod också för att fixa en bugg) lyste inte direkt upp tillvaron, erhöll glada tillrop eller större uppskattning. Inte direkt någon överraskning för någon av oss, men nu är det iaf gjort en gång så det kommer från erfarenhet! :-)

Dag 2

Andra dagen förde jag inte anteckningar då jag hoppade fram och tillbaka mellan blixttal och labbet där vi fick den enkla Continuous Delivery-pipeline att snurra (Spring Petclinic, Puppet, Fabric, Razor, VMware, Python/bash, Jenkins). Bamboo, Go och Team City plus en mindre hög andra saker att kika på eller göra bättre fanns på ena kylskåpsdörren (bra yta för statisk plast = mobil whiteboard).

Gabriel Falkenberg: Jakrakning på rätt sätt
Mycket underhållande och träffsäkert. Om du skall raka jak, raka rätt jak, raka den rätt, … Klart topp 3 även denna.

Adam Killander: Fundamentalistisk förvaltning
Bra teatralisk berättandestil om förvirringen kring nyproduktion vs förvaltning. (Nyproduktion kanske finns första sprinten på ett nytt projekt, men inte efter det.)

Någon gång under dagarna gjordes en jämförelse mellan Legacy inom och utanför mjukvaruvärlden – i det ena en tillgång med värde, i det andra ses det mer som en belastning och kostnad.

Scrum i kravarbetet

No Gravatar

I mitt nuvarande uppdrag jobbar jag med att ta fram krav för utvecklingsteamen. Eftersom jag är van att jobba med scrum som utvecklare saknade jag det nu när jag började jobba med krav. Det jag framför allt saknade var möjligheten att kunna jobba efter en synlig prioritering och strävan efter att få saker klara succesivt istället för att allt blev klart ganska nära inpå den nya sprinten började. Jag har därför börjat jobba scrum-ish även nu när jag jobbar med krav.

Effekten hittills har framför allt varit att vi har fått ökad arbetsro, eftersom det blir tydligt vilken planering vi har för en begränsad tid framöver, och jag känner även själv att jag strävar mer efter att bli klar med enskilda arbetsuppgifter så fort som möjligt för att undvika för mycket parallellt arbete.

Verktyget som vi valde att använda är Trello. Det är ett gratis och mycket användarvänligt webbaserat verktyg där man konfigurerar det mesta själv efter behov direkt i de vyer man använder funktionen. I Trello kan man ha flera bräden, boards, där vi använder ett bräde per sprint och ett bräde till vår backlogg. Varje bräde kan ha så många kolumner man önskar och i kolumnerna lägger man lappar, cards. Vi har i dagsläget valt att ha kolumnerna:

  • Att göra
  • Håller på med
  • Nästa steg är inbokat
  • Väntar på något
  • Klart

Vi börjar varje sprint med en planering. Då ser vi över hur många arbetsdagar vi har att tillgå i teamet och pratar med produktägaren för produkten vi kravställer om vad vi ska göra och i vilken ordning. För varje sak som ska göras skapar vi en lapp på det i Att-göra-kolumnen. Det går enkelt att ändra prioriteringen genom att dra och släppa lappar inom kolumnen.

Ett exempel på en scrumtavla för ett kravteam. All information är påhittad.

Ett exempel på en scrumbräde för ett kravteam. All information är påhittad.

För att kunna följa upp hur väl vi lyckas hålla oss till det planerade arbetet markerar vi upp vilka lappar som planerades från början med en etikett, label, som syns som en färgmarkering i överkanten av lappen. Om det kommer in nya arbetsuppgifter under sprintens gång bedömer vi om de är prioriterade och lägger i så fall in dem som lappar i att-göra-listan.

Varje morgon har teamet en avstämning där vi tittar igenom brädet. Om någon lapp har hinder för att fortsätta jobba på den markerar vi den med en etikett, vi har valt rött.

Etiketterna konfigureras enkelt direkt i gränssnittet och har både färg och text. Det finns till och med möjlighet att slå på ett filter så att etiketternas färger blir anpassade för färgblinda!

Lappar kan tilldelas en eller flera medlemmar på brädet. Man kan även lägga till checklistor, vilket vi brukar använda för att markera vilka arbetsuppgifter som ingår i en lapp. På brädet ser man tydligt hur många punkter som är klara och inte.

En lapp med en checklista och två etiketter

En lapp med en checklista och två etiketter

Checklistorna kan kopieras, vilket underlättar för oss som har ett gäng punkter som ska uppfyllas innan ett krav anses klart. Det är vår Definition of Done, som fungerar bra att använda även när det gäller krav. Checklistan i bilden ovan är bara ett exempel.

Vi har även börjat uppskatta storleken på våra lappar och gör ett burndown-diagram där vi räknar ner hur mycket som inte är klart. Det ger också en strävan efter att bli klar med lappar successivt och en indikation på om vi jobbar oss framåt eller inte.

Trello har bland annat en iPhone-app men det är enklast att använda Trello direkt i webbläsaren.

iPhone-app

iPhone-app

Det kommer kontinuerligt nya features, en av de senaste är att man kan filtrera brädet, t ex för att se vilka lappar som har en viss etikett (vilka som har hinder) eller för att se vilka lappar man själv är medlem i.

Ta gärna en titt på Trello och se om du kan använda det i din vardag. Och om du jobbar med kravställning i en agil utvecklingsorganisation kan det fungera bra att även jobba agilt med kravarbetet!

Information Radiators – Team Performance

No Gravatar

Jag såg en skön bild som fick mig att tänka på agila värden.

Sign“This team has delivered as planned, on time, for the past 24 weeks without slipping dates, and with zero overtime.”

“This team has a current roll of 1023 consecutive fully successful software builds and automated test runs.”

Transparens, överblickbarhet – att skylta med det som är viktigaste aktiviteten för ett team (lyckade mjukvaruleveranser t ex), borde göra att man känner ansvar om skylten visar ett dåligt “resultat”.

Denna form av utåtriktad “information radiator” ger bara rätt effekt under förutsättning att teamet som skylten gäller för, har full kontroll över hela kedjan som ingår i det skylten visar upp, t ex “lyckade byggen”. Om det står någon annan organisation i vägen så kommer teamet inte ta ansvar eftersom det inte KAN ta ansvar. Istället kommer de känna sig utpekade som “dåliga” och känna sig oförtjänt nedtryckta pga omständigheter de inte kan påverka eller göra något åt.

Givetvis är målet att teamet skall känna sig nöjda och viss stolthet över sitt arbete och sin skylt med ett bra “resultat” – en implicit klapp på axeln med orden: Japp, här inne vet de vad de gör och de gör det bra!

Oberoende, självorganiserande team ftw!

Spaning från konferensen SDC.

No Gravatar

Agila team är mer inne än någonsin och mer norm än undantag. Men det pratas inte så mycket SCRUM utan det är en mix av SCRUM, Lean och XP där det gäller att hitta sin egen implementation för framgång. När det gäller att få delarna i företagen utanför utvecklingsteamen med på det agila spåret så börjar det hända en hel del, men många har fortfarande samma problem som tidigare. Maktstrukturer rubbas och ansvarsområden förändras när team och projekt skall ta egna beslut. Men det är en livsnödvändig förändring för de företag som vill hänga med i den allt snabbare utvecklings- och förändringstakt som är på marknaden.
En talare sa att dagens stora komplexa system kräver att man jobbar i grupp för att kunna lösa uppgifter tillsammans, en hjärna räcker helt enkelt inte till för att tänka ut ett helt system, och det är de som kan utnyttja dynamiken och kreativiteten i teamen bäst som är vinnarna.

Nyckelbegrepp att fördjupa sig i:

  • Små agila team som är sjävvalda, självgående och väljer sina egna uppgifter ur backloggen.
  • Satsa på hög utvecklingstakt, så kommer teamen själva att vilja effektivisera arbetet.
  • Tänk alltid; Användaren i fokus! Jobba med UX.
    Ingen har råd att bygga något användarna inte vill ha!
  • Test ofta
  • Satsa på kontinuerliga releaser hela vägen till slutanvändarna, då följer automatisk en satsning på “Continuous Integration” och kvalité.

 

Software Passion

No Gravatar
Hotel Post

Hotel Post

I början av denna vecka hölls den av DFind Redpatch och oss på Squeed ordnade konferensen Software Passion Summit. Det var premiär för den nu i år och platsen var det fina nyrenoverade Hotel Post mitt i centrala Göteborg.

Jag valde tisdagen som konferensdag eftersom den hade flest lockande agaila föredrag.

Keynoten på tisdagen med Gojko Adzic var lättlyssnad med intressant innehåll som var lätt att relatera till. Han sa att han jobbade med software delivery vilket är ett mycket trevligt begrepp. Det är alldeles för lätt hänt att man bara gör software utan att komma till delivery!

Han berättade om företag som trodde att de var agila och körde scrum med iterationer på ett par veckor men som i själva verket inte släppte ut något i produktion mer än var två-och-ett-halfte-år. Det låter lite galet men är inte alltid så långt ifrån verkligheten. Ett bra citat som jag tog med mig var att scrum och kanban bara är speglar där man tydligare ser en del av verkligheten. Men man väljer själv vilket område man vill spegla, och där ligger en stor risk att man sätter spegeln på en del av sin process som ser fin och bra ut, till exempel utvecklingsiterationerna, när man egentligen skulle speglat hela cykeln fram till produktionssättning. Han menade också att enligt forskningen praktiserade de flesta organisationer “water-scrum-fall-metoden”.

Tom Gilb

Tom Gilb

Andra intressanta föredrag ur min synvinkel höll Tom Gilb, Jakob Mattsson och Nick Oostvogels. Tom Gilb trashade det agila manifestet med huvudpoängen att vi ska sträva efter ingenjörsmässigt mätbart värde för intressenter, inte bara leverera fungerande kod. Han kallar sitt koncept för Competitive Engineering som är en iterativ metod där även intressenter omvärderas med jämna mellanrum. Jag gillar detta eftersom han presenterar en metod att arbeta med att fylla på produktbackloggen på ett strukturerat sätt som man kan mata scrum-teamen med.

Soffhörna

Soffhörna

Jakob Mattson är en lokal programmeringsspråknörd — i positiv bemärkelse — som diskuterade på ett närmast filosofiskt sätt om olika programmeringsspråk, främst dynamiska.

Nick Oostvogels från Belgien pratade om Kanban med upplägget att ta död på fem vanliga argument mot detsamma. Han har en blogg som verkar läsvärd.

Flera av föredragen hölls i små lokaler som blev knökfulla så att folk fick stå, men sammantaget var det en bra konferens i härlig miljö och med många tankeväckande föredrag!