Tag: agile

Notes from Evidence-Based Management Training

These are some of the notes I made for myself during my two day training with Scrum.org and others at Scrum.org HQ. Two mind-blowing days, I assure you!

Agility Path comes in to managers at a solution level, Evidence-Based Management addresses the thought level. (If you haven’t heard about it, it’s essentially the next move in trying to improve the profession of software development.)

What do you want to accomplish & how do you want to measure it?

Metrics for improvement, not performance.

Elevating empiricism to business value.

Measuring input, is not output – what do you actually get from this investment?

Success for an Engagement Manager? Help bring relevant metrics, bc of relevant reasons.

Försvinner utvecklingssamtalet i en agil organisation?

Läser med ett öga (barnpassning med det andra ögat) Peter Antmans “Riv pyramiderna igen”:

de agila värderingarna (teamet är ansvarigt, betoning av inre motivation, återkopplingar hela tiden, systemtänkande, vid behov) skar sig mot de värderingar som ligger bakom individuella utvecklingssamtal (bedömning, extern motivation, individinriktat, sällan förekommande, förutbestämt).

Spontant håller jag inte med. Möjligen (eller troligen) har vi olika bild av hur utvecklingssamtal genomförs och varför. Min erfarenhet säger mig att utbildningssamtal ger möjlighet till inspect & adapt.

Negativt?

“Bedömning”, ja mot egna uppsatta och antagna mål borde ju vara ett minimum. Vilken transparens har vi annars att jobba utifrån? Att få en extern vy på sina förehavanden och mål är sällan skadligt utan positivt – på samma sätt som att lära någon befäster sina egna kunskaper, att kunna visa och motivera sin bedömning för någon annan kan hjälpa till med att vässa sina argument och ställa djupare krav på eftertanke.

“Extern motivation”, detta ämne förstår jag inte.

“Individinriktat”, går visserligen bokstavligt stick i stäv med “teamet är ansvarigt” men inte bildligt. Det går inte att skapa grupper utan att ha individer. Att stötta individer till att växa och utvecklas borde göra teamet starkare.

“sällan förekommande”, detta håller jag med om. Min erfarenhet är att det sker sällan (varje kvartal). I för långa och för korta cykler är det svårt att se orsak och verkan.

“förutbestämt”, förstår inte riktigt vad Peter menar med detta. Förutbestämda datum behöver inte vara något negativt – i Scrum-ramverket ger det möjlighet till just att se orsak och verkan genom regelbunden inspektion. Ett metodiskt angrepp att försöka öka kontroll/riktning i en komplex miljö/omgivning/verklighet (och på så sätt reducera risken att komma ut i fel ände). Förutbestämd agenda kan vara jättebra för att komma igång, de flesta retrospectives jag deltagit i tror jag haft nytta av detta. Givetvis behöver man variera sig, men att ha något att börja titta på kan hjälpa till. Det kan också baseline:a och begränsa resultatet genom att det avgränsar tankerymden.

Positiva agila värden

“Teamet är ansvarigt” – vilket innebär personligt ansvar för den egna insatsen (inför teamet och sig själv).

“betoning av inre motivation” – kan man kanske se hänga ihop med Software Craftsmanship (för de som känner att det är vad de gör). En bra mentor/coach/chef bör kunna hjälpa till att hitta och formulera, och kanske även “maximera”, de aktiveter och den omgivning som stöttar en individs motivation. Att varje team skall bestå av personer vars innersta inre motivation kommer till fullt utlopp genom arbetsplatsens åtaganden känns eutopiskt.

“återkopplingar hela tiden” – instämmer att det traditionella utvecklingssamtalet är långt från tillräckligt här (samtidigt som viss ledtid måste finnas i “långa” processer)

“systemtänkande” – här tänker jag att utvecklingssamtalet inte bidrar till “systemtänkandet”, men inte heller skadar. Troligen optimerar man inte endast “flaskhalsen” genom att se till varje individ i teamet, vilket då skulle medföra “waste” i att se alla som inte är flaskhalsen. Jag skulle bli förvånad om det ändå är kostsamt att genomföra bra utvecklingssamtal, regelbundet.

“vid behov” – nja: visst som värde; nej som aktivitet för styrning. Om vi har komplex miljö vill vi göra kontinuerlig inspect & adapt, inte “vid behov”. I en enkel och repetitiv aktivitet vill vi minska waste, men att kalla individers utveckling inom arbetet för potentiell waste tror jag inte är lyckat. Det är antagligen inte heller vad Peter menar, så jag missförstår säkert hur utvecklingssamtalet “vid behov”.

Coach, mentor eller chef?

Givetvis får man kanske fundera över grundinställningen till utvecklingssamtalet. Om det är ett halvårsvis avstämningsmöte, eller förtäckt lönesamtal så är det väl tveksamma incitament för transparens etc.

Kanske Peter förtydligar sina tankar senare i boken.

Agila Sverige 2013

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.

Fantastisk utvecklarvår i Göteborg 2012!

Aldrig förr har utvecklarcommunityn i Göteborg varit så sprudlande som den är nu, iaf om du frågar mig! Till att börja med har vi minst tre rejäla konferenser, tyvärr inte fyra då Nordic Ruby går av stapeln i Stockholm i år. Hur som helst – ovanpå det har vi ju javaforum, nforum och alla user groups på Meetup, liksom SweNug, Alt.net, OWASP och en mängd andra aktiviteter som t ex Göteborgs Agilister och allt som anordnas av DataFöreningen Sverige (DFS).

Att vi har detta utbud i Göteborg tycker jag är kanon! Det ger varje utvecklare en möjlighet att välja själv, att inte bara vara tvingad till att stirra blint på en leverantörs erbjudanden, bara en teknik, bara en grupp – dvs inte bara smalna av och ramla in i “samma gamla hjulspår”, utan verkligen har en möjlighet att bredda sin insikt, kompetens och sitt nätverk.

Det som är än mer glädjande är att i all denna “konkurrens” så har verkligen de flesta user grupper jag varit i kontakt med satt just utvecklarna i första rummet. Det finns ett litet undantag som sätter sina egna ekonomiska intressen före utvecklarna i user groupen och försöker kontrollera informationen som når utvecklarna, istället för att låta medlemmarna själva bestämma vad de tycker. Jag gissar att detta blir uppenbart så småningom och att en ny grupp bildas spontant – som är till primärt för utvecklare, inte ett bolags ekonomiska intressen.
(Min uppfattning är att utvecklare är intelligenta, självständiga individer som är helt kompetenta nog att ta egna informerade beslut, inte få “så här skall du tycka och göra” nedtryckt i halsen. Nåväl, det lär som sagt självregleras inom tid.)

Så, without further ado: här är min lista på vårens toppar i Göteborg 2012!

Konferenser

WebCoast, 16-18 mars, Lindholmen Science Park (en unconference)
Software Passion Summit, 19-20 mars, Clarion Hotel Post (Centralstationen)
Scandinavian Developer Conference, 16-17 april, Svenska mässan (Korsvägen)
dev:mobile, 12 juni, Folkets hus (Järntorget)

User Groups etc

(Dessa har ju återkommande möten och byter emellanåt plats – därav blir datum/adress inte så intressant.)

Korsfunktionell syn

Sprang över denna bild som visar på en mogen organisation, eller som jag hörde någon säga vid lunchbordet:

– Ja, jag hörde att ni skulle bli agila på riktigt – flytta ihop korsfunktionella team i samma rum osv. När skulle ni “flytta”?
–  Det gjorde vi redan i måndags – men var bara lugn: vi har fortfarande kvar flyttbara väggar mellan de olika delarna. PO, systemtest och PM har vi tryckt in i en egen liten modul.

 

Korsfunktionell matrisorganisation

Tecken på agil utveckling

Sitter och rensar ut gammal e-post och hittade följande som skickades till en kund när ett POC-projekt övergick i “vi gör lite mer än POC” (från 2008).

Som förespråkare för agil utveckling vill jag ju poängtera att

  •  agila utvecklare aldrig undviker att “träffa” ett lager utan tvärtom har som mål att i varje utvecklingssteg se till att man tar ett “helt snitt av kakan” – man tar inte bara glasyren som vi gjort nu, utan strävar att alltid jobba sig hela vägen ner till botten (databasen) utan fusk eller genvägar.

Om vi har 30 minuter kan vi diskutera vilka agila principer vi skall hålla högt i detta projekt :)

Det förra projektet hade följande högt:

  • gemensamt kodägande
  • daglig regelbunden standup (med de tre frågorna: vad har jag gjort sedan senast, vad gör jag till nästa gång, har jag några hinder i vägen)
  • standupen får vara högst 15 minuter
  • planering i iterationer med synlig sprint backlog och …
  • … burndown chart
  • utvecklarna estimerar och planerar sprinten ihop med beställaren
  • sprintens backlog respekterades av alla
  • utvecklarna bestämmer egna dagordningen – alla jobbar med allt, inga revir
  • show and tell i slutet av iterationen
  • kontinuerligt bygge & test av koden
  • alltid körbar kod
  • sprintens backlog underhölls av och var till för utvecklarna och gav PM info om progress
  • endast återstående tid rapporteras

och halvhögt hölls

  • one shot build – ett kommmando är allt som behövs för att bygga och testa allt
  • retrospective – utan regelbunden utvärdering utvecklas man inte
  • gemensam arbetsyta (open work-area)
  • velocity – utvecklingstakt beräknades efter varje iteration utan indelning i mötestid, utvecklingstid, reviewtid, …
  • enhetstestning
  • coding standards – code review

och halvlågt hölls tyvärr

  • testdriven utveckling
  • automatiserad acceptanstestning
  • parprogrammering

och obefintligt var:

  • on-site customer
  • continuous deployment
  • relativa estimat i produktbacklogen (estimaten där hade rubriken timmar vilket var missvisande)

Det finns andra “agila tecken”, jag tog bara ett par ur huvudet och från http://jsolutions.se/2009/10/29/undersokning-om-agil-utveckling/

/Fredrik :)

Böcker om Scrum mm

Jag brukar ta med mig ett par böcker när jag håller workshops eller predikar om ett ämne jag håller nära hjärtat. Eftersom det ofta är svårt att hinna svara alla frågor eller gå på djupet på alla ämnen så brukar det uppskattas att jag lämnar referenser till böcker (eller bloggar) där man kan gräva sig djupare. Efter fredagens “Agile Injection” fick jag frågan om att skicka över listan med böcker jag hade med mig då. Här är den. :)

Följande utmärkta böcker rekomenderas varmt

Agile Project Managemeng with Scrum, Ken Schwaber
9780735619937
Appendix A är Scrum i ett nötskal (~10 sidor). “A book of case studies about Scrum”. Som Knibergs bok, fast mer polerad och mindre detaljrik.

Scrum and XP from the Trenches, Henrik Kniberg
9781430322641
125 sidor med erfarenheter: how we do testing, how we do sprint backlog, how we arrange the team room, how we do daily scrums, … Man bör kunna grunderna (helst prövat på) för att fullt uppskatta boken.

Clean Code, Robert C. Martin
9780132350884
Utmärkt genomgång av hur man renskriver kod, och varför. Ögonöppnare för många.

Working Effectively with Legacy Code, Michael C. Feathers
9780131177055
Utmärkt bok om “refactoring” – hur skall man attackera legacy code (dvs kod som inte täcks av automattest).

Mycket bra är också

The Pragmatic Programmer, Andrew Hunt, David Thomas
9780201616224
Insiktsfullt om kärnan av systemutveckling – hur jobbar en “bra” utvecklare (eller hur blir man).

Följande böcker har inte samma nivå, men är fortfarande bra.

Extreme Programming Explained, Second Ed, Kent Beck, Cynthia Andres
0321278658
Kent Beck försöker förklara Extreme Programming. Lyckas sådär.

Test-Driven Development, Kent Beck
9780321146533
Kent Beck visar upp TDD i praktiken med riktig kod i tre kapitel. En bra praktisk genomgång.

Andra har uppskattat

User Stories Applied, Mike Cohn
Agile Estimating and Planning, Mike Cohn
Agile Software Development with Scrum, Schwaber, Beedle

och lite utanför ämnet

The Mythical Man-Month, Frederick P. Brooks, JR
9780201835953
Insikter kring mjukvaruutvecklingen från 1975, med uppdatering tjugo år senare. Intressant om man tycker utveckling av systemutveckling över tiden är intressant.

Projektdelen i Avancerade Webbteknologier 1

Detta är min egen utvärdering av sättet att arbeta i projekt efter halva tiden.

Aktiva val

  • Fyra projekt presenterades. Studenterna fick 10 minuter på sig att skriva upp sitt namn på det projekt som de ville jobba med.
  • Grupperna formas inte om.
  • Helt fri indelning i grupper.
  • Två projekt fick user stories från mig, samt “vision” för webbplatsen som skall byggas.
  • Det tredje projektet var student-idé.
  • Projekten skall använda gemensam databas och källkodsrepo.
  • Inga sprintplaneringar, inga burndowns (vi har chansen att jobba med detta i nästa kurs).
  • Det ska finnas en fil som skapar hela databasen, inkl grunddata för att demonstrera den differentierande featuren.
  • Fokus på att producera user story med störst affärsvärde först – “ni möter VC om ett fåtal dagar: vad måste ni visa för att ro hem kosingen?”

Positivt

  • Bra storlek på grupper och lämplig fördelning med (för-)kunskaper.
  • Bra närvaro.
  • Bra stå-uppmöten (inga lösningsdiskussioner, inget trams, en talar i taget, avstämningsinriktat) och projektdiskussioner i helhet.
  • Varierande arbetssätt, bra variation i ena gruppen, mer statisk indelning/uppdelning i de andra.
  • Högt intresse för projekten.

Negativt

  • Studenterna har spenderat mycket tid på att diskutera projektets innehåll, såsom funktion.
  • Studenterna har spenderat mycket tid på att diskutera och få till databasdesign.
  • Överlag har ett fåtal producerat lösningarna, medan flertalet haft svårt att få ihop det själva.

Sammanfattning

Till nästa period kommer jag nog gå in och tillhandahålla en färdiddesignad databas. Detta kommer få dem att inte lägga tid på sådant som ligger utanför kursen. Jag kommer försöka tillhandahålla user stories, viktade efter affärsvärde. Eftersom det varit ett par personer som dominerat kanske dessa skall sättas i eget projekt för att få utmaning?

Notiser

  • Teckenkodning har varit en issue i Eclipse men framför allt i MySQL.
  • Två grupper har valt att använda user stories/tickets på papper, uppsatta på väggen. Tredje gruppen jobbar ad-hoc.