2 dagars agil coachning av 150+ proffs för 2000 spänn

Tycker du det är dyrt med agil coachning? Missa inte konferensen Agila Sverige nästa år, som just gick av stapeln i Stockholm. Där får du 2 dagars professionell coachning av 150-200 erfarna ledare, utvecklare, designers, testledare, projektledare, verksamhetschefer, IT-ansvariga, filosofer,  pedagoger, samhällsvetare mfl

Insikten kom till mig på vägen hem. Denna återkommande konferens, ordnad i enkelhetens namn, innebär oavsett om du är proffs eller rookie i området att du får 2 dagars personlig coaching av väldigt många agila proffs och möjligheter till att ta del av erfarenheter, nya och gamla kontakter, roliga historier, personliga samtal, rådgivning, underhållning, praktiska tips och filosofiska resonemang om kommunikation, design, system, teknik, politik, religion, verksamhetsutveckling, organisation, teamutveckling och allt annat nödvändigt för att vi ska kunna leverera det våra organisationer är till för – att skapa en kund – må den vara medborgare, medlem eller konsument.

Det är nu 5:e (?) året jag deltar och utbytet ökar. Fiskdammen har mognat till ett event av direkt, praktisk och filosofisk coachning.

Några ämnen som var uppe som jag lyckades fånga

- Form och funktion – är samma sak. Varför skilja på design och utveckling?
- Inkludera människor i ditt team istället för envist försöka assimilera. Bjud in!
- Tänk nästa steg när du funderar på att byta riktning – vad kommer efter ditt val nu?
- Metodöverflöd. Det finns en enorm mängd fantastiskt användbara metoder idag för att leverera nytta – Innovationgames, Lean Startup, Real Options, UX (User Experience Design)-områdets stora skara av metoder, Stop-the-Line, Kanban, A3-förbättringar, Toyota Kator, Enkla checklistor, Programming Anarchy… listan kan göras oändlig. Välj en – prova på i 30 dagar, utvärdera, förbättra och/eller välj en annan nästa 30 dagar.
- Det finns goda exempel på hur verkligt självorganiserande organisationer kan fungera, se t.ex Valves handbok för nyanställda även Länsstyrelsen Karlskrona omnämndes i det sammanhanget. Hade velat höra mer om
- Kommunikationsskuld. Den skuld du bygger upp genom att avstå från nödvändig kommunikation. Ungefär som teknisk skuld. Det du inte gör något åt idag börjar du betala ränta på, skulden växer tills dess du tar i tag och börjar betala av skulden. Hur har du det med kommunikationen med dina leverantörer eller beställare egentligen..?

Agila Sverige är ett smörgåsbord av tillfällen till coachning och lärande.

Nya boktips från pedagogiska mästaren Tobias Fors – The Power of Learning och Thinking fast and slow

Om man upprepar något tillräckligt många gånger blir det sant. Några saker behöver upprepas och påminnas om många gånger, bl.a perceptuell blindness, testa själv på

Awareness Test: Basketball players

Har du verkligen koll på allt?

Och det ständiga upprepandet av mantrat:

”Be inte om tillåtelse, be om ursäkt efteråt”

kommer snart ge resultat i våra organisationer – förväntar mig större turbulens och större förbättringar på arbetsplatserna för kunskapsarbetare närmsta åren..

Och sist men inte minst, den ständigt och självklara upprepandet på denna återkommande konferens – frågan

VARFÖR?

Det resonemanget tror och hoppas jag blir nästa års fördjupning.

Tack till arrangörernas idealistiska och aldrig svikande engagemang för att se till att vi har ett forum som utan att kosta skjortan kan ta oss ytterligare ett litet steg framåt i evolutionen av våra system.

Snygga bilder på några av dessa 150+ coacher finns här…  fotat av.. vem var det? Joakim S?

Foton Agila Sverige Dag 2
Foton Agila Sverige Dag 1

Agila Sverige 2011 – 10 år av agile

Varje gång jag ser programkod på storbildskärm kan jag inte låta bli att bli sugen igen, att göra det riktiga hantverket/konstverket. Nya språk, roliga saker som händer, monader & Scala, funktioner och kvalitetstänk gör att jag undrar ibland hur det skulle vara att prova igen.
Programming, motherfucker liksom.

Vi andra gör ju bara (?) Managment, asshole

Min stora miss!  Att inte delta i open x-sessionen där man skulle para kund/programmerare och utveckla något snabbt som attan till en marknad.  Var istället en stor behållning att se några vänners blixttal bland annat Jocke Holm i 4D-glasögon som siar en framtid där vi organiserar vår verksamhet utifrån-och-in på riktigt och verksamheten både drar (pull) i utvecklingen och deltar i den (vilket borde vara fallet redan idag, dock en optimistisk framtidsvision fortfarande).

Roland Bäcklin visar hur man mha improvment communities på Ericsson tror jag, arbetar med förbättringar i större skala – där en medarbetare committar sig till ett tillfälligt community som har ett visst mål, när målet är uppnåt upplöses communityt och medarbetaren kan delta i ett nytt om han vill. Förutsättning – 5-10% avsatt arbetstid för att arbeta med och implementera förbättringar i verksamheten. Boktips: Succeeding with Agile – Mike Cohn.

Medarbetare, motarbetare och vårt inrotade språk om att tala om oss själva och andra som ”resurser” var på tapeten. Tack Maria Thelin, Jaybis för den insikten under FishBowl-debatten som var en mycket lyckad start där många fick chansen att med väl valda ord uttrycka sin syn på 10 år av Agile.

Individens egna ansvar, teamets ansvar att bli självorganiserade – tänkte fler än jag själv över. Bland annat Petter Wigle som tycker att alla kodapor bör se sig själva som kodlejon i stället, att i stället för att passivt vänta på att få information – se till att skaffa den själva.

Deltog i intressant Open X om Economy of Gifts, att vi kan om vi vill börja organisera oss enligt devisen ”jag hjälper dig med något så finns det säkert något som du kan hjälpa till med i framtiden”. Komma loss ur budget- redovisnings- och tidrapport-träsket – kan vi själva kanske göra något åt det t.om, genom att bjuda på oss själva och inte be om lov – utan be om ursäkt efteråt? Det fungerar på många ställen. Kopplade dessutom väl till det Björn Elmberg talade om på #Webbdagarna – att gamla sanningar är på väg ut i business, nya på väg in – Sharing economy om jag minns rätt pratade han om.

Den största aha-upplevelsen – #OutdoorFriday med Martin Persson. De arbetar utomhus en dag i veckan, för att stimulera hjärnan, hjärtat och kreativiteten – komma ur våra bunkrar, stänga av laptopen, packa en termos och ett liggunderlag och sitta ute, t.om i Februari. Med mer än märkbart resultat. Inspirerar mig att göra det jag bara tänkt länge – att ta med viktiga intressenter på kreativa möten utomhus. Uppbackat av forskning. Det var inte så svårt upptäckte vi under ett OpenX där vi helt plötsligt befann oss utomhus.

Almut Herzog berättade om att starta upp projektet med ”Inception Deck” – ett sätt att få projektteamet med på tåget, väntar in hennes presentation att länka här.

Hans Brattberg, inspirerar om att ge feedback i smått och stort med hjälp av tekniken Perfection Game där tre frågor ställs: Vad ger du mig för betyg på det här? Vad gillade du med det? Vad skulle jag göra för att uppnå det perfekta betyget?  Fråga att använda i team-retrospektiv: ”Hur skulle en perfekt sprint se ut?”

Fantastiskt många bra & underhållande tal i år, givande fikapauser, riktigt drag på middagen.

Tre saker som lyste igenom:
- Eget ansvar för att uppnå det vi vill
- Det behöver inte vara så svårt
- Testning ur alla perspektiv, exploratory, visualisering, automatisering, bdd’s vara eller inte vara, specflow..

Härligt nördig och samtidigt både mänsklig och väldigt medveten konferens som tidigare. Kvaliteten helt klart högre i år både på tal och open space, även om det var lite tunt med postningar på open x-schemat med tanke på det debattglada klientelet.

Vi saknar nästa generations deltagande – vad går 90-talisterna och funderar över därute på sina campus? Något för nästa år gissar jag. Också tvärfunktionella konferenssamarbeten är nästa naturliga steg, det är många som vill i olika forum.

Kram på er! We are the system, society & change.

Systemkraven är de nya verksamhetskraven

Sitter tillsammans med några andra ”kravare” ”produktägar-proxys” eller vad man nu vill kalla det.

Vi har uppdrag av ”verksamheten” att identifiera, prioritera, utreda, kommunicera och följa upp kraven i ett större systemutvecklings/systemförändringsprojekt.

Vi försöker varje dag hålla oss till ”business”-språk och kommunicera omkring kund och verksamhetsanvändning och låta bli att tänka på vilka system saker finns i eller vilka systemlösningar som passar bäst, och helt lämna det till utvecklare.

Problemet är att systemen numera ÄR en del av verksamhetsprocesserna.

Exempel: Vi ska göra en enkel blankett-beställning på webbsidan. Om det nu finns något som längre är ”enkelt” på en normalstor site.

Var sjutton ska blankettbeställningen ta vägen nånstans? Det finns en massa system därbakom i verksamheten för hantering av blanketter som webbutvecklarna (konsulter allihopa såklart) inte alls känner till. Lämnar vi frågan enbart till utvecklarna i just det här lilla teamet att besvara är det stor risk att lösningen blir ytterligare en av alla blankett-lösningar som finns.

Tillbaka till krav. ”Fokusera på vad användarna vill”. Ja, slutkunden vill ha blanketten på snabbaste sätt hem. Kundtjänst vill slippa ännu mer manuellt arbete och att beställningen ska gå helautomatiskt och lagras/loggas.

Vilket av de 5 tänkbara systemen som idag finns ska vi använda? Återstår intervjuer med kundtjänstmedarbetare, de kvarvarande anställda systemmänniskorna som finns och se till att de kommer i kontakt med webbteamet för att hitta bra lösningar. Frågan ligger i knät på krav ett tag till.

Hur länge då?

Jag tror att

1. vi måste acceptera att system- och verksamhetskrav i IT-intensiva verksamheter som nog alla större organisationer är idag, är väldigt väldigt lika och att vi behöver personer med bakgrund från  båda världar för att göra ”rätt sak” och leverera nytta som alla vill. Lär dem och ge dem verktygen att respektera varandra – t.ex teambuilding – låt dem leka ihop, och placera dem bredvid varandra – på bekostnad av andra som vill sitta tillsammans mm.

2. inse värdet av verksamhetskunniga systemutvecklare. Snälla, gör er inte av med dem! Ge dem dubbla lönen, finaste stolen och alla förmåner och kompetensutveckling ni kan – och ge dem sällskap, låt dem utvecklas i par! Det är bara dessa personer som verkligen kan se helheten och hjälpa oss andra (konsulter) att se den.

Finns det någon svensk organisation som gör detta än?

Vad väntar ni på?

Jag ökade min produktivitet med 100% idag

Bara genom att osanktionerat flytta in till programmerarna, kravare som jag är.

Det kändes som jag på 4 timmar fick gjort 8 timmars arbete.

Allt för en liten flytt på ca 5 meter och ett par väggar emellan.

Betyder det att jag bara behöver jobba halvdagar nu?

Dessa java-bönor och IT-tjejer

citat från lunchen. måste bara bjuda på den.

Kravutredning med spikes

Första gången jag stötte på tekniken ”spike” var när vi i ett projekt stod inför ett teknikval med många osäkerhetsfaktorer. Vi gjorde helt enkelt ett antal time-boxade spikes på de olika alternativen för att skaffa oss kunskap och kunde ganska snabbt utesluta två av fyra alternativ. En ”spike” är att snabbt göra ett experiment på ett alternativ, och experimentet ska slängas bort. Det behöver inte vara funktionsdugligt eller leveransdugligt utan bara ett experiment. Målet är att efter ”spiken” fatta beslut om vi ska gå vidare med något och göra det ordentligt.

Nyligen använde vi samma metod ”spike” i ett fall av ett svårt krav som varken kravställarna/produktägaren eller utvecklarna hade en riktigt klar bild av. Vi bestämde att vi gör en utvecklingsspike för att prova ett förslag på design och för att skaffa oss kunskap. Timeboxade till 2 dagars programmering.

Under dessa 2 dagar utvecklades mycket snabbt några funktioner som provade systemdesignmodellen. I samband med det ställdes helt plötsligt, inte särskilt förvånande, rätt sorts frågor till kravaren, kunden, verksamhetsarkitekten, om begrepp, om interaktion, om regler mm och på bara 2 dagar hade hela teamet med kravare o testare fått en bra bild av vad vi egentligen vill ha. Valet kommer innebära ett ordentligt programmeringsjobb och en del refaktorisering som vi tar med oss i nästa sprint (iteration). Vi kastar experiment-koden och bygger ordentligt med en mycket högre känsla av att göra rätt.

Ungefär som att hastigt slänga upp en kuliss på en yta där man vill ha sitt hus, för att se hur det gör sig på platsen, hur rummen kan placeras, provar några snabba färger, för att sen riva ner och bygga som det ska.

Det kräver en enorm disciplin att faktiskt i princip kasta koden, och att INTE dema eller använda kulissen som någon slags fungerande mjukvara, men har man disciplinen så har vi fått en enorm kunskapsvinst på mycket kort tid som ger oss möjlighet att få bra feedback snabbt och designa rätt lösning med trygghet.

Det här är inte sista gången jag använder spikes som teknik för att förstå krav och behov.

Spikes skiljer sig stort från traditionell krav-prototyping som ofta sker i mock-up-verktyg för att t.ex pröva en interaktionsdesign. Inget illa om mock-ups och prototyp-skisser, men det är verkligen först vid programmering som vi verkligen ställer de rätta designfrågorna – och kostnadsfrågorna.

”och hur eliminerar man risken med integration?”

forts på tidigare inlägg..

Om du vill eliminera risken för missförstånd mellan uzbeken och svensken helt vad gör du då? Eliminerar samarbetet helt, eller hur? De behöver inte prata med varandra alls eller ha något alls med varandra att göra.

Det enda sättet att eliminera risk med integration av olika system är alltså att eliminera integrationen.

Men om det inte går att eliminera, de måste kommunicera, hur minskar du risken för missförstånd mellan uzbeken och svensken?

1. En tolk är naturligtvis bra. Motsvarigheten i den tekniska världen är en medlare – en utvecklare som aktivt arbetar i båda systemen. Han kan båda språken, kulturen, designen och miljön.

2. Kvittenskommunikation. ”Sa du det här?” Bekräfta den kommunikation du har så tidigt som möjligt. Om uzbeken ritar upp en sol med händerna, rita ner det du uppfattar, dvs solen, på papper.  Uzbeken skakar på huvudet och visar med en spark att det är en boll han menar.

Detta händer dagligen i integration mellan system. Genom att snarast kvittera det meddelande det andra systemet skickar ökar förutsättningen för kommunikation.

I praktiken: Bygg integrationen först! Integrera först. vänta aldrig med att visa upp och bekräfta en fungerande kommunikation mellan systemen. Prioritera alltid uppvisning av integration.

Hur gör du själv för att eliminera eller minska risker du själv ser i ditt arbete? Vad brukar fungera?

”Varför är integration mellan system alltid riskfyllt?”

Mina kunder frågar mig, varför är det riskfyllt med integration mellan system?

Hur svarar man på det, på ett icke-tekniskt språk? Liknelser och exempel brukar ju rekommenderas för att förklara så här kommer ett försök.

Att integrera två tekniska system är som att få två människor att kommunicera som har två helt olika språk. T.ex en uzbek som bara kan uzbekiska med en svensk. Vi har vissa gemensamma nämnare, som gör det möjligt, t.ex kroppsspråk, tecken och tonfall och kanske några engelska ord.

Översatt till den tekniska världen:

Två system som skall prata med varandra har två olika språk. De är skapade vid helt olika tillfällen, ofta är ett av dem mycket äldre än det nya som vill få information från det gamla.  Det är två helt olika tekniska miljöer som skall ”integreras” dvs se ut som om de vore samma system. Du skall alltså integrera något som någon annan för längesen gjort, i en helt annan miljö, av helt andra designers och människor, med ett helt annat språk i din applikation.

Som att ta ett arabiskt nomadtält anpassat för öknen och integrera och använda som del av bostad i din hemmamiljö i vintriga Norden.

Enklare än så är det inte.

Går detta att förstå?

Om inte, besök morgonmöten för valfritt utvecklingsteam, varje morgon under en vecka, alternativt fråga om du kan sitta med  och parprogrammera (bidra med att lösa problem, det måste man inte vara teknisk för) så kommer du förstå.

Vilka risker har du själv i ditt arbete? Och hur förklarar du dem i två meningar för t.ex en advokat?

Och vad är det bästa sättet för advokaten att förstå de risker du ser i ditt arbete? Ge mig gärna tips.

Det är ju så lätt att programmera

Är det inte märkligt hur många det är, som aldrig, eller nästan aldrig, har programmerat själv, som har så starka åsikter om hur lätt det är att programmera?

Som anser sig kunna avgöra hur lätt eller svårt det är att

- programmera ett system
- integrera ett system med flera andra
- att bygga ett GUI
- att testa
- att produktionssätta
- att drifta
- att dokumentera
- mm

och som också anser att en programmerare bör kunna alla verktyg, alla versioner, i alla tekniska miljöer och alla tänkbara applikationer det aktuella  utvecklingsprojektet är beroende av.

Vad vet du om programmering egentligen?

Skulle du som icke-ekonom, t.ex gå till ekonomerna som påstår att det är mycket och svårt att göra bokslut i år ställa dem mot väggen – hur svårt kan det va? Du är ju ekonom, det här har du ju gjort varje år, gud vet hur länge?

Skulle ekonomen möjligen uppfatta det som respektlöst beteende?

”Jag ser en risk i att bokslutet inte stämmer, pga ett antal oklara faktorer”

”Hur kan du påstå att det är en risk, det är väl bara att räkna, fram med kulramen bara!”

Det finns flera lätta sätt att ta reda på hur lätt eller svårt det är att programmera något, även för en icke-programmerare.

1. Besök varje morgonmöte / Scrum-möte i ett aktuellt team under 2 veckor, eller kanske bara 2 dagar. Lyssna på samtalen och du kommer att förstå.

2. Fråga om du får sitta bredvid och parprogrammera, som en trainee, under 1 vecka i ett utvecklingsteam. Eller eventuellt sitta bredvid och bidra med någon annan del, t.ex testning eller interaktionsdesign. De kommer ta emot dig med öppna armar, och du kommer att förstå.

Vill du verkligen veta?

Veckans ord: Innovation

Hur och när inträffar innovation?

Hur ska vi lyfta blicken och sluta analysera och börja nyskapa?

Analys är bra till mycket, men kanske inte  just för innovation?

Vad ska få oss att tänka utanför våra rutiga boxar och pilar? Behöver vi alltid en Steve Jobs i teamet? Eller en konstnär? Eller räcker det med att vi drar ut på en tur på häst tillsammans? Eller sätter oss på ett café istället för i ett konferensrum?

Eller att ha anteckningsboken bredvid sängen?

Vad är ditt tips för innovation?