Produktägarskap handlar om relationer

23 09 2015

När man tänker på produktägare och produktägarskap, så hör jag ofta att man tänker på marknads- och trendanalys, arbete med användarbehov och affärsnytta, arbete i utvecklingsteam och kanske acceptanstest. Att strukturera och grooma backlogen, sätta visioner och mål, följa upp och kommunicera dessa med teamen. Skriva user stories och klarkriterier kanske.

I teorin var det nog så Scrum-skaparna tänkte.

Efter att i många år ha arbetat både med och som produktägare så har jag insett att de delarna är bara en mindre del av rollen och uppgiften.

En produktägares viktigaste uppgift är att skapa och underhålla relationer. Relationer med kunder, intressenter, slutanvändare, leverantörer och utvecklingsteam. Om du som produktägare undrar vad du ska prioritera idag, så ställ frågan – vem är viktigast att jag träffar idag? (alternativt ringer upp eller kontaktar på annat sätt). För att höra hur de mår, hur det går, ge information om läget eller bara småprat.

Den andra viktigaste uppgiften är att kunna berätta en historia. Som produktägare hinner du sällan med att genomföra allt, leverera allt enligt plan eller förväntan. Men om du kan berätta din historia så är det mindre viktigt vad som faktiskt levererats. Mer viktigt är berättelsen om planen framåt, även när den är ytterst oklar, och om läget i teamet, även när det är kaos. En berättelse kan ha många hål, men det är produktägarens vardag. Du kommer inte ha koll på allt, alla siffror, alla detaljer jämnt. Men kan du berätta din historia på ett trovärdigt sätt så sköter du jobbet utmärkt.

Det kan räcka med en snygg powerpoint-presentation som lyfter fram små men ändå viktiga delleveranser så att det ser proffsigt ut. Eller att du använder ett språk som omgivningen gillar. Eller att du bara valt en bild som illustrerar något som är viktigt för mottagaren.

Framgång som produktägare handlar om att gå och ta den där after worken trots att du inte alls har tid eller har en enorm förkylning. Att du går och tränar ihop med någon chef som du kanske inte alls skulle umgås med annars. Att du åker till andra sidan stan för att luncha med den där leverantören då och då.

Detta leder till framgång för produktägare.

Backlog, user stories, produktvision, demos och allt annat metodiskt kan du delegera eller avsätta en dag i veckan för. Trots att det kanske var det du trodde att jobbet skulle handla om.

Stämmer det med dina erfarenheter?





Agilt, Iterativ & Inkrementell!

22 03 2013

Jag fick den här frågan från en kompis & student:

”Agile, Iterativ & Inkremell! Vi har pratat lite om det jag & några från klassen, och alla typ blandar ihop allt!
Vissa säger att tex Scrum är agilt, andra säger att det är ngt annat bla bla, jätte förvirrande :b det ända jag har
koll på är att RUP iaf är iterativt haha.”

Ska jag göra ett försök att förklara begreppen lite kort?  Jag gör ett försök..

Agile
Agile är ett sätt att tänka. Det är inte ett verktyg. Det är inte en metod. Det finns metoder som Scrum, Kanban, Lean Software Development som kan hjälpa dig att komma framåt. Du kan vara agil utan att använda någon metod alls. Du kan också vara agil med en gammaldags metod som RUP, eller vilken som helst annars. Det handlar om ditt sätt att se på projekt som en icke-förutsägbar händelse, och ditt sätt att se på verkligt samarbete (arbeta tillsammans), ständigt omfamna förändringar i omgivningen och hos dina kunder, kontinuerligt förbättra hur du och ditt team arbetar och samarbetar.

Det går att jobba enligt Scrum och inte alls vara agil, även om Scrum med sina regler om att inom en kort tid leverera fungerande programvara ofta hjälper till på vägen att bli agil.

Den här blog posten beskriver vad agile inte är  – med referenser till principerna i det Agila manifestet, som handlar om principer – inte verktyg & metoder.   http://www.tommycode.se/2012/12/what-is-agile.html?m=1

En gång delade jag några tankar om vad agilt är, på stapplande engelska..

http://blog.smartbear.com/software-quality/bid/224669/Ulrika-Park-Becoming-Agile

Iterativ

Iteration är ett annat ord för upprepning. Inom matematiken och i programmering handlar detta om att en funktion eller process åstadkommer något genom att upprepa tills ett önskat resultat uppnåtts.  (wikipedia nerkortat)

Ett annat ord är loop. Tänk dig ett flygplan som gör en loop. Sedan gör flygplanet samma loop igen. Det är den 2:a iterationen. Bilden nedan är ett gäng iterationer av samma flygplan.

Smoke-Loops-Flight-demonstration-Circle-Sky-300x187

Inom systemutveckling är det att utveckla samma funktion flera gånger tills den är tillräckligt bra.
Det kan också vara att genomföra samma projekt flera gånger tills det är tillräckligt bra att släppa till kund.

Säg att du skriver en uppsats om ett ämne. Du skriver en version rakt på tills den är klar. Sedan börjar du om och skriver samma uppsats en gång till. Du tar med dig saker från första versionen, kanske många meningar, men lägger till saker, tar bort saker, ändrar ord. Den andra versionen är andra iterationen. Skriver du den en tredje gång, har du gjort 3 iterationer.

Detta är något som glömts bort i många genomföranden av s.k agile.

Jag har varit med i ett par projekt där vi verkligen jobbade iterativt. Det vill säga – vi valde en funktion att bygga. Definierade vilka krav & testfall som skulle passera för att funktionen skulle kunna fungera någotsånär. Vi visade upp funktionen för beställaren/kravställaren. Sedan byggde vi samma funktion en gång till – byggde ut, snyggade till, förbättrade både bakom ytan (programkoden) och framför ytan (användargränsnittet). Ibland en tredje och fjärde gång.

Att jobba iterativt är att ALLTID bygga samma funktion minst 2 iterationer – 2 gånger.

Faktiskt så påstod även någon att även den förhatliga Vattenfallsmetoden var iterativ från början. Meningen var att man skulle driva sitt projekt enligt Krav – design – implementation – test – integration – leverans och sedan köra samma projekt en gång till och då göra det rätt och snyggt. Kanske borde kolla upp källorna på detta, men har för mig att jag sett bilder på en loop – där man går tillbaka till början direkt efter slutet.

Idén med RUP var också att vara iterativ. Dvs definiera krav (use cases), design, progammera, testa under en fas, sedan gör samma sak en gång till. Tyvärr dränktes den idén i för mycket annan information, regler & dokumentation så att jag har sett få RUP-projekt som faktiskt jobbat iterativt, även om jag har hört talas om dem som faktiskt gjort det.

Scrum är enklare och studerar man metoden noga kan man se att tanken är att iterera, loopa, över funktioner. Det har tyvärr också ofta dränkts i idén att man bara ska leverera snabbt snabbt. Att leverera snabbt är inte huvudfokus i principerna i det agila manifestet. Ingenstans sägs att man ska leverera snabbt. Men man ska prioritera fungerande programvara framför pappersprodukter (oändliga dokument som inte går att använda).

En ”sprint” i Scrum är INTE en iteration. En sprint är rätt och slätt en time-box på t.ex 2 veckor (aldrig mer än 4). Efter 2 veckor ska teamet visa upp resultatet för sina intressenter. Och bara fungerande programvara. Dokumentation, tankar, idéer och planer är oväsentligt. Huruvida man faktiskt tar samma funktion och itererar över den i nästa sprint, sägs inget om i Scrum, även om metoden kan tvinga fram det beteendet. Man hinner inte på 2 veckor göra så mycket ”lull lull”. Man måste ofta gå tillbaka till samma funktion nästa eller senare sprintar för att göra den värdig att sälja/använda.

Man kan säga att en sprint i Scrum kan vara en projekt-iteration. Dvs man genomför samma projekt i många iterationer, tills det är tillräckligt bra. Första iterationen så har man gjort projektet (krav, test, utveckling, integration, leveransfärdigt) fast det kanske inte är tillräckligt bra – än, så man gör en iteration till över samma projekt så blir resultatet bättre.

Jag har inte sett många Scrum-projekt som sett på sprintar på det sättet. Även om tanken var att en sprint – skulle vara en iteration av ett projekt.

Sprint och iteration är alltså (oftast) två helt olika saker.

Du kan bygga en funktion under en sprint, och sen strunta i att bygga/förbättra den igen. Då har du inte itererat över den funktionen. Du har bara jobbat i en time-box, en sprint.

Inkrementell

”An increment is an increase of some amount, either fixed or variable. For example one’s salary may have a fixed annual increment of x%” (redigerat från wikipedia).   Om din lön ökar med en fast % varje år, så ökar den i inkrement.

Inkrement är alltså en utökning.

Jag tänker på en bakelse. Säg att du har en liten rund bit sockerkaka och fyller den med bär. Sedan tittar du på den och tycker den förtjänar lite grädde runtom. Du lägger till grädde. Det är ett inkrement. Bakelsen var redan klar att äta och njuta av med sockerkakan och bär, men med inkrementet grädde så har du utökat bakelsen till en lite större upplevelse. Sedan tittar du på bakelsen igen och bestämmer dig för att lägga på riven choklad runtom. Ytterligare en utökning, ett inkrement. Den var redan färdig som den var, men chokladen gav det lilla extra.  Som ett sista inkrement lägger du på hyvlad mandel.

Du hade en färdig bakelse från början med sockerkaka & bär. Bara sockerkakan hade  inte varit tillräckligt, det hade bara varit en sockerkaka. Efter den första inkrementet, utökade du den stegvis, inkrementellt, till en större finare bakelse.

Samma gäller funktioner i systemutveckling. Du bygger en funktion som är färdig som den är. Den går att använda. Sedan utökar du den med (små) inkrement, ett extra värde, ett extra inmatningsfält, extra information.

Exempel
Ett exempel på inkrementell funktionsutveckling var när vi skulle presentera kursinformation i ett utbildningssystem för studenter.

Det första inkrementet bestod bara i att visa upp kurskoden och namnet på kursen. Fullt fungerande.
Det andra inkrementet bestod i att visa upp ytterligare information, såsom kort beskrivning, hur många poäng kursen var, vilken institution som gav kursen.
Tredje inkrementet var att visa upp kurstiteln på engelska och vilka prov som ingick.
Etc.

Vid första inkrementet kunde vi inte släppa funktionen till studenter, den var för fattig på information. Däremot kunde vi visa upp den för vår beställare/kravställare/produktägare, så att han kunde se att det fungerar.
Efter 3:e inkrementet var funktionen redo att släppas till studenter – slutanvändaren.

Skillnaden mellan iteration och inkrement??

Inte helt lätt att avgöra. När man stegvis utökar (increment) – en färdig funktion, så gör man det genom att iterera – alltså återkomma till samma funktion (bakelse) flera gånger.

Inkrement = utökning
Iteration = upprepning

Solklart?

Skulle vara jätteintressant  om den som rättar era tentor vill kommentera den här artikeln, kanske har hen ett ännu bättre svar på skillnaden mellan iteration & inkrement?

Kram

Ulrika





Att vara projektledare

27 08 2012

Jag fick idag en fråga ”kan du berätta lite vad du gjort som projektledare?” av en person som fått ett erbjudande att prova-på att byta roll.

Jag fick tänka till lite, vad är det egentligen jag gjort i projektledar- och projektledarliknande roller (som t.ex produktägare, scrummaster) under de ca 10 år som jag verkat i rollen.

Jag måste vara ärlig och svarade så här:

I korthet har det mesta jobbet som projektledare handlat om det sociala – att bli kompis med alla – och då menar jag alla, inklusive den där jobbiga otrevliga typen som jag kanske inte alls alltid haft lust att bli kompis med.

Och dessutom få dessa alla att bli kompis med varandra. Som en jäkla kamratstödjare för vuxna helt enkelt. 😉

Andra halvan har handlat om att om att övertyga ledningsgrupper och chefer om att tro på vårt projekt och ge oss de medel (miljoner ibland, lokaler, utrustning etc) till just vårt projekt som vi behöver. Som en jäkla politiker och försäljare helt enkelt. 😉

Och det värsta är att det är sant.

Planering och organisation är typ 1% av jobbet som projektledare.

Vilket när man läser kursprogram och annat kan låta som att det är de 1%-en som det handlar om att vara projektledare.

Vi pratade om detta och jag kom på att ingen talade om detta för mig när jag gav mig in på banan.

Jag kunde också lägga till att, jo som projektledare är man den som får ta smällarna och all skit när saker går dåligt, och när det går bra är det teamet som får beröm. Det är du som står där när det stormar, det är du som får vara försvararsadvokaten när det är svårt och det är dig de hotar att halshugga när det krisar.

”Låter inte så lockande” säger hon.

Om någon sagt detta för 10 år sedan, hade jag ändå tackat ja till det erbjudande jag då fick?

Jag vet inte.

Det tog mig 5 år att börja tycka det var roligt på riktigt att vara projektledare – eller då blev jag ScrumMaster – kanske hade något samband? Eller var det bara så att det var då jag började få tillräcklig erfarenhet för att börja bli bekväm med rollen?

Det tog mig ytterligare 5 år att ha tagit mig igenom strider, stått i blåsten, blivit hotad, kramad, peppad och stressad innan jag började förstå vad teamledarrollen egentligen handlar om. Jag påstår inte att jag bemästrar den, mycket är kvar att lära. Numera är det väldigt roligt och spännande att gå till jobbet och faca de där herrarna i höga hattar som har miljonerna, eller se sitt team växa och nå framgångar.

Det har tagit tid, och jag vet inte om någon annan projektledare skulle säga annorlunda?

Jag har sett så många pressade, stressade, överarbetade, ledsna och oförstådda projektledare runt om.

Samtidigt verkar vi vara ett ordentligt gäng som bara inte kan hålla oss ifrån den här organisation/metod/team/coachande rollen, som bara måste se om det går att komma i mål den här gången och hur roligt man faktiskt kan ha på vägen. Att få möta team efter team av fantastiska människor som älskar att utveckla system, produkter och tjänster i någon form.

Jag skulle inte vilja vara utan det.

Skulle du?





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

24 04 2012

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





Kvalitet och kommunicera lättrörliga krav – Sundsvall 42

20 10 2011

Under konferensen Sundsvall42, som pågick den 18-20 oktober 2011 höll jag ett seminarium på tema ”Att kommunicera lättrörliga krav” i spåret ”Kvalitet” med undertexten ”Ok, nu jobbar vi agilt – är det bättre eller inte”. Flera frågor att svara på alltså, hur gör man det på 40 minuter?

Dessutom var det skrivet att detta är ett seminarium, inte en föreläsning, och min tolkning av seminarium är att det innehåller interaktivitet. Hur gör man en workshop i en biosalong med 60 deltagare?  Det finns säkert bra svar på det, det sätt som dök upp i huvudet på mig inför konferensen var att låta deltagarna refklektera omkring begreppet ”Kvalitet” och hur det kan tillämpas på kravarbete i en alltmer snabbrörlig värld – och dessutom dokumentera on the fly i Prezi. Att servera färdiga svar när det sitter 60 erfarna testledare, kravare, förvaltningsledare i publiken känns på något sätt.. omodernt – det måste finnas bättre sätt. Färdiga svar är bara att googla på – som min nyfunne digitala kamrat @erkstam sa under sitt föredrag om digitalisering.  ”Googla på mig så kan vi skippa hela den där presentationsbiten.”

Googla på ”Agile requirements” så hittar du en del, eller varför inte skaffa ett Twitter-konto tillslut och fråga där! Twitter är en fantastisk yrkeskunskapsbank för tips om artiklar, bloggar, rapporter mm. Om du hittar mig där (@ulrikapark] kan jag hjälpa till lotsa till intressanta grupper där du kan ställa frågan, eller så retweetar jag din fråga. Några tips från mig på tekniker och annat finns lite längre ner.

Prezi-dokumentationen från seminariet  (via traditionell dator behövs inget login). Jag försöker också få ner resultatet här i en något mer fyrkantig form som kanske är lättare att skriva ut. Tack till Ulf Eriksson, Reijo Soréus, Azim Rezaei, adjunkten från Mittuniversitetet och alla andra mycket kloka personer i lokalen som bidrog till ett facit, ett av flera multipla sanningar, för HUR vi bör jobba med krav för att uppnå kvalitet i de system, produkter eller tjänster vi levererar.

Några associationer  deltagarna gjorde till begreppet ”Kvalitet”:
(alla 60 kommer redovisas i separat inlägg)

LEVERERAT ENLIGT BESTÄLLNING

Vad kan vi göra när vi arbetar med krav för att bli säkrare på att leverera enligt beställning (”det får kosta så här mycket, jag vill ha det här”)?

Deltagarnas svar:
Var TYDLIG! Hur blir vi tydliga? Genom DIALOG och MALLAR t.ex User Stories.

Detta brukar jag kalla ”Extreme Expliciteness”. Extrem tydlighet alltså. Att använda krav&test-tekniken ”Specification by example” (Gojko Adzic har skrivit bra böcker i området) i kombination med user stories (Mike Cohn) är mycket användbart för att uppnå extrem tydlighet.

INGA FEL

Vad kan vi göra när vi arbetar med krav för att bli säkrare på att det blir rätt – inga fel?

Deltagarnas svar:
Test & granskning i iterationer!
Demos!
Flera iterationer över ett och samma krav!
Användarmedverkan!
Utvecklarmedverkan!

Inte bara kravaren är med i kravställningen alltså! och involverade på riktigt – mitt tillägg. Det räcker inte med att göra en workshop en gång där man ”samlar in krav” utan utvecklare och användare behöver vara med och påverka kraven löpande under hela genomförandet. Bästa sättet att lära sig mer om detta är att börja pröva idag!  Vad hindrar dig, ditt team, din organisation från att iterera över ett krav flera gånger, eller att involvera utvecklare i processen? Vad kan DU göra för att påverka det i små steg? Sitta 1 dag i veckan hos IT-leverantören? Sitta 1 dag i veckan hos din kravställare?

TRYGGT

Hur gör vi för att uppnå trygghet med kraven?

Deltagarnas svar:
Prototyper
Verifiera kraven, genom demos
Prioritering!
Kommunikation!
Rätt människor med

Ramverket Scrum innehåller många verktyg för just detta – tvärfunktionella team, prioriterade product backlogs och kommunikation och synlighet genom regelbundna demos och tvärfunktionella planeringsmöten (sprintplanering).
Scrum på 5 minuter.
Confessions of a serial Product Owner

ANVÄNDBARHET

Kvalitet är användbarhet. Hur uppnår vi användbarhet när vi arbetar med krav?

Deltagarnas svar:
Prototyper
Användningstester

Mitt tillägg: Engagera en duktig UX-designer (användbarhetsexpert ibland kallad) i teamet – som arbetar med teamet löpande genom hela genomförandet, inte bara i början eller i slutet. Personliga tips: Anette Lovas – Connecta, Fredrik Lindersson  – Söderhavet, Johanna Särnå – Valtech,  Sigrun Tallungs – Frontit, och säkert en hel bunt till därute t.ex på Antrop och Transformator Design.

Intressanta artiklar om User Experience Mapping

HÅLLBAR

Hur uppnår vi krav som håller över tid, är aktuella mer än 3 månader?

Deltagarnas svar:
Tydliga mål!
Gå ner på djupet! Gå ner på domänen och förstå varför.

Mål håller ofta längre än detaljerade krav. Vi ändrar inte målen varje dag, däremot gärna detaljerna beroende på förändrade omvärldskrav eller förväntningar.
Informationsobjekt/domänobjekt håller också längre än detaljer i funktionalitet är min erfarenhet. En informationsentitet – eller domänobjekt – (beroende på vilken ”skola” man pratar med) ändras inte varje dag när man väl lyckas förstå och kommunicera vad det är för objekt ”begrepp” vi pratar om. Därför är domänobjekt t.ex utmärkt lämpliga för att strukturera krav- och testdokumentation omkring, eftersom dessa strukturer håller över tid – åtminstone bra mycket längre tid än en user story.

Dessutom så vid de tillfällen jag varit med vid begreppsmodelleringsworkshops ”med rätt människor med” så har betydligt djupare insikter kommit fram om kraven. Insikter som kan vara både besvärliga och kännas omöjliga, men som verkligen bidrar till en djupare dimension av kravförståelse och detta kan förhindra allvarliga misstag och belysa nödvändiga samband och förändringar. En teknik som används alldeles för lite – eller för stelbent gömt i någons kammare, i ett hemligt filarkiv som bara vissa personer får åtkomst till. Sprid denna teknik!

Tips: Använd SMARTA mål. Googla på SMART goals. Eller fundera på vilka dina klarkriterier är. Beskriv, definiera vad ni menar när ett krav är ”klart” så har du ett mål definierat.
Tips: Arbeta med Domain Driven Design eller Begrepps-/informations-/domänmodellering. Förstå er verksamhet genom modellering. Ta hjälp av duktiga modellerare, kanske finns en ensam arkitekt någonstans hos er som inget hellre vill än att bli inbjuden till teamet och kravställningen? Eller en utvecklare som brinner särskilt för domänförståelse och modellering?

PORSCHE

Hur kan vi arbeta med krav om vi vill skapa en produkt/tjänst som är av motsvarande kvalitet som en Porsche?

Deltagarnas svar:
Smakar det så kostar det!
Sätt rätt förväntningar! Det kanske är ok att det blir en Trabant, bara förväntningarna är satta och kommunicerade så.

Min kommentar: Om vi förväntas skapa de administrativa stödsystemens motsvarighet till en Porsche, eller the BMW of kundtjänstsystem – då behövs det resurser för krav. Vi behöver antagligen flera olika kompetenser – analytiker, arkitekter, ux-designers, exploratory testers.. i teamen. Det räcker inte med en verksamhetsrepresentant på 30%…  Vi behöver också acceptans för att det kostar tid av flera personer i verksamheten såsom affärs-/verksamhetsutvecklare, strateger, domänexperter, personal att delta i användningstest, workshops mm.

OM VI HAR MÅLET ATT GÖRA ALLT DETTA, disciplinerat och ett steg i taget, visst kommer kraven hålla högre kvalitet?

Tack för orden och berätta gärna nästa år på SU42 hur det går med kraven!

Om jag hade trotsat programmet och hållt ett föredrag i stället, hade det jag tagit upp varit just dessa saker. De exempel jag hade med mig handlade om – Tydliga mål, begreppsmodellering, prioritering (backlog), user stories, specification by example och experience mapping – enklare version. Hade inte haft en chans att få med allt – t.ex användningstester och iterationer, så tack till deltagarna för att vi fick med mycket mer än jag hunnit med ensam.

De exempel från verkligheten jag tänkt visa upp finns lite av dem i Prezin. Vid något tillfälle ska jag försöka producera en artikel här om ”exempel från verkligheten på lättrörliga krav”.

Happy development!





Wikispeed and Agile @ universities – ALE2011 – Berlin

24 09 2011

2 weeks after wonderful Agile Lean Europe unconference in Berlin, there are many things that stick.

One of the things that stick is WikiSpeed, this lovely project of developing a car going 100 MILES PER GALLON – with a self organizing distributed team with people in a lot of countries contributing to the project. People saying that agile cannot work in distributed teams could pay a visit to WikiSpeed on YouTube.  Thx to Thorsten O Kalning (@vinylbaustein) for giving us a ”everything is possible” mindset.  It’s possible to design and build a car that goes 100 miles per gallon! It’s possible to apply object orientation in car and make modules and parts that can be changed during driving. This is the car I’d love to drive.

Marc Lainez (@mlainez) and a couple of other people asked the question ”Why don’t you speek about agile and Lean at universities?”  I couldn’t find an answer in my head. ”Time?” If you have the time going to conferences or speaking at seminars or in community groups or whatever, you could trade some of that time and spend it sharing experiences and insights you’ve gained with the next generation? Insight gained from a lightning talk – if we don’t share – these students are gonna be our co-workers in a few years and probably we’ll need to first help them to unlearn some waterfall teachings they’ve studied hard to learn in school. (Not ALL university courses are like that of course, but far far too many). Why not start already in school. Share your agile mindset with next generations developers, designers and managers.

After this an idea of an ALE @ university day is forming at ALE Group at Linked In. The idea that is forming is to have a production game  or pair programming session with coaching, connecting students in many European countries online, with the help of students of course.

In the mean time – contact your uni and offer a guest seminar, speech, BDD-session whatever..

Story mapping session in the next post.. now it’s Saturday night right.

Former post on ALE2011 Berlin – Feature injection and Complexity theories





Complexity and Feature injection at Agile Lean Europe 2011 Berlin

17 09 2011

While reading in news magazine Computer Sweden about all the big companies getting even bigger, and their sometimes so outdated strategies for development and business, I’m ready to agree with Brian Marick (@marick), saying that the only way being agile all the way is to start your own business. Several more people, among them Rachel Davis, said agile just won’t scale.

When companies are that big, you can make agile bubbles inside the company, networking with other agile bubbles in the company and have some changes happen. You’ll soon hit the system – HR, CEO bonuses, incitements, history, education and either you stay happy in your little agile bubble networking with your peers or you quit – and start your own business.

I still believe though you can make things happen with the mindset of the people around you in big business. I like being part of creating these agile bubbles all around, to see creative minds waken up from traditions, to dare to question ”the ways things always been around here”. That’s agile for me. Maybe you can’t turn an oil tanker around by doing Scrum, but you and your closest peers will learn a lot and have a lot more fun on the way and hopefully adding a bit more business value than usual.

Agile is a learning machine!  (Chris Matts quote I think, not good at remembering who said what)

Dave Snowden (@snowded) warned us agile bubble-creators that we’re in a danger zone of change and impact right now. It’s easy to get eaten by the old system when we hit the system right. So, he’s advice is you have to stop selling agile and start talking about it in other words! Now!

And that’s what Bjarne Bogsnes (Statoil) have been doing for a long time with the Beyond Budgeting movement, inspired and maybe strengthened by the spreading of agile thinking. I bring some of his words in my backpack. ”Event driven planning” in stead of ”Calendar driven planning” might speak to business people around there. And the metaphor: Having yearly budgets is like I had only 4 weeks a year where I could ask my bank for money. If it turns out the money is not enough the years consume and investments, I have to wait until next years ”open time” til I can get more money out from the bank, no matter what happens. And I have to spend a wasteful amount of time trying to foresee what will happen the coming year.

Dave Snowden also gave us another warning and important insight – it’s easy to get idealistic, to in the systems thinking way believe you can edit the process and then expect a certain outcome. That sounds like Lean thinking in my head. Make changes in the process and you should expect a certain outcome. Lean Software Development (and Lean in general) could probably add some complexity theories and improve to stay a relevant for the complex networks we act in, where there’s no one cause and no one effect.

Complex systems need constraints. Self organizing teams need constraints otherwise there is chaos. Compare with a self organizing birthday party for 10 year old kids. As soon as you draw an imagined border and say ”cross this and you’ll die!” team works getting better. Yes, we need management, nothing said about managers, but management. Constraints and Amplify/Dampen actions for the team.

Dave also gave a what we say in Swedish ”känga” (sort of a light kick) to all these Management theory x.0 books and courses. The same of old stuff. Anyway I think the ”Managment theory x.o” fills an important purpose. That kind of language talks to an audience normally not very attracted to ”Agile” ”Lean” ”Complexity theories” or whatever for them abstract and obscure strange name. Some hard core management words are needed to meet a wider audience, as long as we use them wisely. So for all of you that falls asleep when you hear about another Agile titled book, I recommend to buy Jurgen Appelos book ”Management 3.0 – Leading agile developers – Develop agile leaders”  and attend his course ”Management 3.0 – Agilt ledarskap i praktiken” in Sweden 24-25/10 at Citerus. Jurgen was one of the organizers of #ALE2011 and also got us bloggers a bit change management in practice at his talk. We’ll see if I change or not. At least I got the desire injected.

Here are More notes from Snowden’s talk.

Feature injection was a fun session with Chris Matts (@PapaChrisMatts), lovely British IT Risk Manager. dare to call himself a BA. (Am I the only one actually liking BA’s btw? They’re a competence all to often get wasted by putting them away in lonely rooms – not Chris I’m sure but a lot of his profession colleagues.)

”What’s the worst thing that can happen in a presentation?” he had a conversation earlier. What happened..  His session got feature injected by a minute of birthday party thrown by the lovely kid’s programme. Oana, one or two (?) of the kids mother was the happy celebrant.

Anyway Feature Injection, sort of a real application of pull system in systems development. Happy to see there is a theory for something I learned in a project not long ago – maybe a little too late – that YOU have to start with the recipient of your systems output, no matter who this is. This recipient, end customer or reader or whatever end user – has to first pull features developed from the systems. Ooach! This means that I really need to put end user’s first!? Again!? Oh all these end users all the time, please. It’s really challenging to implement this thinking, since the recipient often is a partner, who you don’t have really close development practices or relations with, or end users where the threshold for involving them early early in the process is very high – ”we’re only in pre-study”  ”we’re in such a hurry” ”the money doesn’t cover user recruitment..”

Anyway. Feature injection seems to be best explained by comics. And I love to hear about some real cases in Sweden. Will my case be the first, do I dare? I would for sure need some information/domain modeling expert, since the injection go all the way to the details of implementation.

clip from infoq.com. Whole comic

More about Story Mapping and ALE2011 in next post.

Thank you Caios for helping me out in a tough time
Thank you Tibault for great photos
Thanks to Olaf for spreading humbleness around
Thanks to Birgit for making me think.

Thanks to all people for being so friendly and bringing such a heartly atmosphere around you

What happened more in ALE2011 – Berlin – 7-9 sept