Alla dessa projekt

Ett rådande paradigm tas för en självklar gemensam grund för ett kunskapsområde, så självklar att den är svår att få syn på. Det är som en låda vi är instängda i utan att ens se det. Men ibland sker det ett radikalt omtänkande och ett paradigm ersätts steg för steg av ett nytt. Det är en process som tar sin tid, när en hel bransch lär om. Under tiden har vi olika världsbild; olika spelplan för agerande och reflexion, och har svårt att mötas.
Skiftet till Lean/Agile är som en våg som går över hela verksamhets- och it-utvecklingsområdet men har inte nått lika långt överallt. Längst har man kommit inom de mer progressiva delarna av systemutvecklingssamhället. Där fanns Agile och Lean redan för 10 år sedan och har vuxit sig starkt och även utvecklats vidare sedan dess. Svenska systemutvecklare har hela tiden gått i spetsen, med en livaktig community, riktigt bra konferenser och några kända namn.

Lean och Agile lirar ihop

Till it- och verksamhetsutvecklingsområdet har Lean kommit först under de senaste åren men det föregicks av ett liknande synsätt som har samlats under etiketten Agile.
Agile började synas för ungefär 15 år sedan. Agile liknar alltså i långa stycken Lean men har en helt annan bakgrund. På senare tid har det uppstått en rik korsbefruktning och därmed syntes som odogmatiskt hämtar inspiration både från Agile och Lean liksom från andra håll.

Agile och Lean fokuserar på olika saker men spelar förvånansvärt väl ihop.
Lean strävar att eliminera allt spill i flödet, det vill säga allt som inte direkt tillför värde, inte minst väntetider och överlämningar. Man vill på så sätt åstadkomma mer med mindre, därav namnet "Lean".

Agile betonar lättrörligheten, flexibiliteten och anpassningsförmågan, att man snabbt kan reagera på förändringar i omvärlden och prioritera om. I en dynamisk värld klarar den sig bäst som snabbt kan uppfatta och reagera korrekt på möjligheter och hot.

Det Lean och Agile har gemensamt är att båda filosofierna sätter människorna som gör jobbet i centrum. Teamet får förtroendet att själva kontinuerligt styra, anpassa och utveckla sitt arbetssätt efter de erfarenheter de gör.

Vad är Lean?

Lean brukar förklaras som att man fokuserar på att optimera det värdeadderande flödet i sina processer framför att fokusera på att optimera resursanvändning av olika slag.
Om man optimerar flödet följer vanligen ett bättre resursutnyttjande av sig självt. Andra vägen är inte framkomlig. Att fokusera på resurserna tenderar inte att möjliggöra bättre flöde och heller inte alltid ens bättre resursutnyttjande. Allt detta beskrivs i den rika litteraturen om Lean.
Men det är också viktigt att förstå vad det egentligen är som är det värdeadderande flödet i processen, vad det är vi ska optimera. Där finns det en avgörande skillnad mellan å ena sidan tillverknings- och leveransprocesser och å andra sidan design- och utvecklingsprocesser. Denna viktiga skillnad är inte tillräckligt uppmärksammad.

Lean vid utvecklingsarbete

Vid tillverkning och leverans av varor och tjänster finns det materiella eller andra mer konkreta flöden att optimera. Men vid utveckling handlar det om något mera svårgripbart. Där är det själva kunskapsuppbyggandet, det gemensamma lärandet som är det viktiga flödet.

Det vi behöver fokusera på är inte - som vi traditionellt har sett det - att en idé ska realiseras så fort som möjligt. Det är ett missförståndsom hämmar och missleder metodtänkandet inom verksamhets- och it-utveckling.

Det som måste vara fokus är i stället lärandet, hur vi arbetar med den gemensamma kunskapen. Det vill säga hur vi snabbast och effektivast utvecklar en gemensam förståelse av behoven och lösningsmöjligheterna. Det här är en insikt som kan vara svår att ta till sig för den som inte har reflekterat över vad utvecklingsarbete egentligen är.

Det blir tydligt om vi jämför med en kocks arbete. Oftast lagar en kock rätter efter recept eller som han eller hon lagat tidigare och kan utantill. Det är tillverkning. Målet vid en sådan process är repeterbarhet och förutsägbarhet, att resultatet blir lika (bra) varenda gång. Det är det som kännetecknar tillverkning.

Men ibland vill en kock ta fram en ny rätt eller en variant på en befintlig. Då handlar det om en serie försök, där målet med varje försök primärt inte är att resultatet ska bli perfekt, utan i stället återkoppling, att hon eller han ska lära sig något viktigt. Det är då kanske ett framsteg att få reda på att kummin till torsken inte fungerar och därmed kan uteslutas från listan på kandidatkryddor. Det är utvecklingsarbete.

Utvecklingsarbete är, om man betraktar det närmare, till sin natur alltid en serie försök som vart och ett är riggat för att lärandet ska bli maximalt. Man sätter upp en hypotes som behöver provas och riggar därmed ett försök för att verifiera/falsifiera hypotesen. Utifrån resultatet modifierar man hypotesen och riggar nästa försök. Målet är inte, som vid tillverkning och leverans, repeterbarhet och förutsägbarhet utan tvärtom varians, att det ska bli tydligt olika men användbart resultat mellan varje försök. Användbart för det fortsatta utforskandet vill säga.

Det betyder inte att en utvecklingsprocess behöver vara mindre disciplinerad än en tillverknings- eller leveransprocess. Däremot har det värdeadderande flödet ett helt annat innehåll, vilket ger stor skillnad i processen.

Lean har funnits som begrepp sedan 80-talet, men då har det oftast gällt det som kallas Lean Manufacturing, det vill säga Lean tillämpat på tillverkningsarbete. Lean Product Development, det vill säga Lean-tänkandet tillämpat på utveckling, har legat i skugga.

Agiles historia

Det har länge funnits systemutvecklingsmetoder som betonat det iterativa arbetet, utan att man har satt etiketten Agile på dessa. Men i slutet på 90-talet kom en serie händelser som radikaliserade den progressiva delen av systemutvecklar-communityn.
Den första var när Kent Beck presenterade sin nya och minst sagt radikala systemutvecklingsmetod Extremprogrammering (Extreme Programming XP) på konferensen OOPSLA (Object-Oriented Programming, Systems, Languages and Applications), i Vancover 1998.
Extremprogrammering var varken den första eller den enda systemutvecklingsmetoden i det nya paradigmet men det var den metoden som på allvar styrde utvecklingen inom metodtänkandet in på det spåret.

År 2001 bildades Agile Alliance som en allians mellan olika metodförespråkare. Man tog fram ett gemensamt manifest. Sedan dess har Agile varit samlingsnamnet för den nya generationen systemutvecklingsmetoder.

Syntesen mellan Lean och Agile

Hela denna utveckling skedde intressant nog utan närmare kontakt med motsvarande tänkande inom tillverkningsindustrin under namnet Lean Manufacturing och Lean Product Development. Men år 2003 tog utvecklingen på området en oväntad vändning. Mary Poppendieck, ingenjör på tejptillverkaren 3M som var väl förtrogen med Lean Manufacturing och hade kommit i kontakt med Agile Software Development såg likheterna mellan filosofierna och skrev boken Lean Software Development - an agile toolkit.

Budskapet var följande (lätt förenklat):

1. Det är bra det ni systemutvecklare har kommit på med Agile,
2. men ni ska veta att det ni har upptäckt har varit känt i tillverkningsindustrin i 20 år, och man har där också kommit en bit längre i det tänkandet.
3. Låt oss utveckla området tillsammans.

Sedan dess handlar metodutvecklingen inom systemutveckling i nästan alla sammanhang om en förening av Agile (som i sig är en blandning) och Lean. Idag plockar man och blandar odogmatiskt arbetstekniker och verktyg från båda hållen och också från andra håll.

De underliggande värderingarna och principerna inom Agile och Lean är lika i allt väsentligt, men skiljer sig dock båda radikalt från de äldre synsätten inom systemutveckling vad det gäller grundläggande synsätt. Det hindrar inte att man ibland också har återuppväckt vissa tekniker från äldre metoder och använt dessa i de nya sammanhangen.

Vad händer nu?

Vad som händer nu är att Agile/Lean-tänkandet har spritt sig från själva programmeringsarbetet till hela systemutvecklingsarbetet som test, krav, verksamhetsanalys, projektledning, interaktionsdesign, user experience med mera.
I yngre och mer lättrörliga organisationer håller det tänkandet på att börja sprida sig uppåt i organisationen till övrigt it-arbete, till verksamhetsutveckling i stort och till affärsutveckling. Där gifter vågen sig på ett bra sätt med modernt tänkande inom management som på ett liknande sätt betonar självorganisation och ständigt lärande.Agile och Lean är en kraft i våra organisationer som vi behöver bejaka.
På många systemutvecklingskonferenser brukar det finnas konferensspår om Lean/Agile. Där förs det ofta en bra dialog. Det finns också många konferenser specifikt om Lean och/eller Agile. Det finns nätverk, inte minst Agile Sweden. Synen är inte ett dugg dogmatisk och det finns en stor vilja och driv att utveckla tänkandet.
Det känns som att det är nu det händer, den stora omvälvningen i synen på vad utvecklingsarbete egentligen är. Mycket handlar om hur vi ska få till ett bra arbete med verksamhetsutveckling i fokus.

Ogenerat kopierat från Peter Tallungs & Peter Edvinsson

Tjoho,vad kul att få jobba om våra rapporter och de nyckeltal vi följer verksamheten med. Jo, jag menar allvar. För mig är det något som är riktigt intressant och kul. Att vi följer rätt saker för att kunna fatta rätt beslut kan varaheltavgörande men samtidigt måste alla rapporter ta minimalt med tid och arbete att framställa. Det är just här som det hela blir en utmaning.

Vi kommer ganska snart ha en första prototyp klar att visa och de nyckeltal vi kommer ha med är följande:

• Beläggningsgrad
• Externbeläggningsgrad
• Arbetsgrad
• Debiteringsgrad
• Earned value
• Planned value
• Actual cost

De sista tre, som har engelska namn, är en teknik att följa på projekt på som kallasEarned value management vilket är en beprövad teknik för att på ett objektivt sätt mäta framsteg i projekt. Detta passar agil utveckling bra och eftersom vi prata Story points så fungerar det utmärkt.

Hoppas kunna visa ett första utkast till rapporten inom kort.

Vi har nu hållit på med Scrum på allvar i ungefär 4-5 månader. Stora framsteg har gjorts inom flera områden såsom story writing, backlog grooming, daily scrum och självorganiserande team. Det finns dock ett område där vi fortfarande inte lyckas superbra, det som heter i Scrum sprint review meeting.

Vi kallar ofta detta för demo och det är det som markerar slutet på en sprint. Detta möte har flera syften och för att insatsen i tid ska ge värde måste vi höja nivån på dessa så vi når målet med dessa möten. Anledningen till dessa möten är att ha en mer formell överlämning av sprintens resultat till PO. Det är på detta mötet teamet visar och berättar om de stories som teamet lovat lösa och där PO formellt säger JA eller NEJ. Det är PO som godkänner att en story går att stänga och att teamet då får tillgodoräkna sig den storypoints som hör till storyn.

Det finns även fler viktiga värde för en PO i detta möte. Han/hon ska direkt efter detta möte fatta beslut hur vi ska gå vidare. Vilka stories ska prioriteras om och i vilken ordning ska kommande arbete planeras. Hur påverkar det som gjorts i den nuvarande sprinten kommande sprintar. Kort sagt ska även detta möte ge beslutsunderlag för att fatta de mest välinformerade och korrekta besluten om fortsättningen.

Ytterligare ett viktigt syfte med dessa möten är kunskapspridning. Att vi börjar delta på varandras review meetings är viktigt. Det är här det finns en chans att mellan teamen få insyn i vad som byggs just nu till kunden X respektive kunden Y. För att få detta att hända måste vi mer tydligt annonsera när det är dags för review meeting samt vad som kommer att visas. Då kommer vi kunna bygga intresse för övriga team att sitta med och lyssna. Detta är att se som ytterligare en feedback-loop som ger otroligt värde för hela bolaget när den fungerar bra.

Dessutom under detta möte får övriga intressenter såsom jag, sälj, övriga PO och så vidare en möjlighet att verkligen så se vart vi befinner oss i projektet. Ofta är det svårt att få en bra överblick i Daily Scrum då dessa är fokuserade på just dagens aktiviteter men detta möte sammanfattar hela projektet och hela senaste sprinten. Detta är viktigt ur perspektivet fördelning av uppdrag mellan teamen och att alla får en chans att se hur fantastiska saker vi kan bygga.

Detta med fantastiska saker är också en viktig sak. Det är här som teamet ska få visa upp sin förmåga att skapa innovativa lösningar som ger maximalt kundvärde. Det ska vara ett tillfälle för lite fest och glam, det är roligt att lyckas och att komma i mål helt enkelt och det är inte alls fel med lite tårta och skumpa.

Dessa möten brukar följa en ganska enkel agenda.

• SM ger en kort genomgång av vad teamet lovat lösa vad som faktiskt gjorts samtkommenterar den ev differensen
• Teamet visar på en övergripande nivå vad som lagts till denna sprint, merarkitektonisktänfunktionellt
• Teamet visar funktionaliteten
• PO meddelar sitt beslut ang vilka stories som är godkända

Inför detta möte bör man räkna med ca 1 h förberedelse och se till att hålla produkten i fokus. Undvika powerpoints i möjligaste mån utan det är vad teamet lyckats bygga som är det viktiga. Mötet bör vara 1-2 timmar långt beroende på frågor och innehåll. Ofta brukar dessa möten spelas in för att de som inte kan delta ska kunna ha chansen att se i efterhand.

Vi behöver höja oss i dessa möten. För att få ut nyttan med den nerlagda tiden behöver vi förbereda oss bättre och redan från start av en sprint tänka kring vad vi ska visa i sprint review meeting. SM och PO kommer stötta teamen kommande period i detta att lyfta nivån och vi kommer bli bättre på att annonsera kommande möten och dess innehåll.

Fick ett infall och köpte en PS4 till kontoret. Den kommer sättas upp i Roxen nu till börja med men tanken är att vi bygger upp två spelstationen i de öppna utrymmena.

Min förhoppning är att skapa en ny möjlighet till lite avkoppling i samband med raster och luncher men då vi inte riktigt får in ett biljardbord idag så fick det bli en spelkonsol. Då konsolmarknaden är tydligt uppdelad så tänkte jag att vi vill ha både en PS4 och en Xbox One.

Kom gärna med förslag på speltitlar vi borde behöva ha ibiblioteket.

Sitter nu på tåget för att åka och besöka vår stora kund GT. Jag ser verkligen fram mot detta, mitt första besök ute hos denna viktiga kund. Har givetvis med mig lite backup i form av SUS och MW så jag ska nog klara mig.

Syftet med mitt deltagande är att förklara hur fantastiskt bra agila utvecklingsmetoder är och hur vi tillämpar dessa. Det påverkar givetvis kunden en del och ju mer de förstår om vårt arbetsätt, desto bättre blir det. Det som är de största fördelarna för kunden kan beskrivas såhär.

• Låg risk då man inte lägger tid på fel saker
• Får ändra sig under hela projektet både avseende features och prioriteringar
• Snabb återkoppling
• Snabbt kundvärde genom kontinuerliga leveranser
• Hög kontroll på framsteg genom burn-down charts och velocity

Tänkte även visa ett exempel på en brun-down då det brukar uppskattas av tveksamma kunder.

Flera medarbetare har tagit upp detta men hur vi bokar resurser, rum, för möten och är inte nöjda med hur det fungerar. Vi har ett system för detta i Outlook där våra mötesrum finns upplagda som resurser. Vi ska använda denna funktionalitet för att boka dessa rum och det går inte att bara ta ett rum utan bokning.

Jag säger bara skärpning! Det är inte speciellt svårt att boka upp rummen och att ta bort bokningar som blir ändrade. Sedan måste man respektera tiderna som finns i bokningen. Har man bokat till 13:00 så går det inte att säga, det tar bara 10 min till, till nästa som ska starta sitt möte. Ofta är det hela team som ska sitta för att jobba med sina projekt och tidspillan som uppstår är onödigt och kostsam. Så om du är osäker på om ni hinner, boka längre tid för säkerhets skull. Tänk även på ev förberedelsetid som kan komma och krävas.

Jag kommer lägga in i Evernote hur detta ska fungera inom kort men det ska inte vara några större frågetecken kring detta så jag vill be alla om att börja sköta detta bättre. Ge teamen möjlighet att fungera effektivt snarast möjligt.

Har idag tillsammans med MW och PR träffat vår kund i team 2 som nyligen fått leverans av sin facelift. Kundens IT-chef, HJ, är imponerad av det teamet som jobbat med denna uppgift och är mycket nöjd med slutresultatet. Det finns en delfrågeteckenkvar kring sökmotorn men HJ förstår att detta inte ligger på oss utan mer på sökmotorns funktionalitet och att de måste själva lära sig skapa material som motorn gillar.

Det fanns givetvis även en del saker de önskar att vi förbättrar, främst kring analys av återkommande fel, så detta ska vi se hur vi kan angripa på ett bra sätt. Passade på att även prata en del om att vi vill få kunden in i supportportalen istället för direkt in i Jira, det gick inte direkt hem då de tycker just att den nuvarande lösningen är mycket bra och en av våra stora fördelar. Vi får nog tänka om här och låta just denna kund komma in direkt i verktyget.

En utmaning framåt kommer vara att få PO:ns tid att räcka för att utveckla denna kund på ett bra sätt. Blir till att prata ihop oss hur vi bäst utnyttjar tiden.

Pratade just med vår PO för kunden som berättade att BO hört av sig och 76yu8vill ha mer hjälp. De har beslutat sig för att satsa på detta med e-handel och vill fåhjälpatt bygga upp sin verksamhet för detta. Helt enkelt konsultstöd på en mer strategisk nivå. Roligt att vi får en sådan förfrågan och en chans att visa vad vi kan inom området.

Vi håller nu på att planera för fullt för en första kompetenslunch. Tanken är nu på torsdag, innan påsken, med givetvis påsklunch. Teamat för dagen kommer att vara våra nya verktyg Evernote och Lync.

Vad är då en kompetenslunch? Jo, konceptet har jag stulit från ett annat konsultbolag och det handlar om att sprida kunskap och insikt i företaget. Ämnet varierar och deltagandet är frivilligt men deltar du bjuder vi på lunchen mot att få din uppmärksamhet. Det kan handla om verktyg som denna gång men det kan vara design, frontend, backend, strategi, nya partners osv. Målet är på sikt att kunna köra detta någon gång varje vecka och att alla som vill ska få möjligheten att berätta om det man brinner för.

Formen är att runt 11:50 står lunchen uppdukad och man får börja ta för sig. 12:00 startar vi föredraget som håller på i ca 40-45 min. Den som håller föredraget brukar ha förberett en presentation eller demo som denna går igenom och vanligtvis tas frågor på slutet.

Inbjudan bör komma under dagen.

Ps. Misslyckades att få hit en påsklunch men vi får smörgåstårtaistället. Ds.

Ibland tar det fart snabbt, kul. Efter att ha visat Evernote för några medarbetare har nu 16 personer på kort tid anslutit sig. Det var just detta som var min förhoppning och tanke. Att vi som bolag inte "tvingar" på ett verktyg utan det sprider sig som en best-practis snarare. Syftet med att införa Evernote är att spara tid och sprida kunskap vilket systemet är mycket bra på.

Detta ställer dock lite krav på att vi får till en vettig struktur i EV ganska snabbt. Saknas det en struktur kommer alla börja bygga sig egen och det kan skapa kaos. Har därför gjort ett första försök på att få till något smart. Har pratat med så många jag hunnit för att få synpunkter och andra idéer vilket nu kokat ner till detta.

Evernote ser på strukturen i två perspektiv, anteckningsböcker och taggar. Anteckningsböcker bör man vara sparsam med men det är på den nivån man kan styra behörigheter. Taggar, eller etiketter, kan vi vara mer frikostiga med. En sökning på en etikett går över alla anteckningsböcker så det är ett enkelt sätt att snabbt hitta allt om en viss kund, utan att behöver veta exakt i vilkenanteckningsbok det ligger. Därför tänkte jag sätta upp en viss struktur för anteckningsböcker men även vissa riktlinjer för användningen av etiketter/taggar. Utöver det vi skapar i gemensam struktur går det utmärkt att skapa egna anteckningsböcker för det du själv vill spara i Evernote men vi tar inom kort och bokar upp några genomgångar av verktyget så alla slipper själva uppfinna hjulet.

Vi sätter upp följande gemensamma (tillgängliga för alla)anteckningsböcker.

Våra ramar, regler och policys

Detta är avsikten att bli ersättare till personalhandboken. Detta är styrdokument, med det menas "hårda" saker vi måste rätta oss efter såsom hur vi reser, tidrapporterar och är organiserade.

Våra processer, rutiner och verktyg

Här finns de rutinbeskrivningar, how-to, instruktioner för larm, veckofakturering och liknande. Detta är mer "mjuka" saker än ovanstående som ska ge oss vägledning i att vara en medarbetare hos oss.

Skattkistan

Vår interna anslagstavla. Här lägger vi presentationen från informationsmöten, månadsmöten, bilder från senaste demon, när det blir kompetenslunch nästa gång och när vi får tårta.

Teknisk kunskap

Här lägger vi vårt gemensamma kunnande om tekniken vi använder. Här lägger vi in beskrivningar av lösningar, dokumentation av komponenter och SQL-frågor.Kända buggar, betallösningar vi använder och länkar till test. Allt det som vi kan vilja återanvända och spara för framtiden gällande teknisk kunskap. Var inte snåla med att lägga in material, utrymmet är obegränsat. Allt tänkbart som vi kan ha nytta av, in med det.

Projekt

Här lägger vi allt som är projektspecifikt.Det kan vara en skiss över flödet i checkouten, excelfilen över produktträdstrukturen eller noteringar från senaste mötet med kunden. Det är saker som inte passar in i ovanstående "Tekniskkunskap" läggs här.

Kunder

Här samlar vi dokument och information som skapas ur kundperspektivet. Det är främst sälj och PO som kommer skapa material här. Det kan vara det gällande avtalet, senast skickade offerten, det visade lösningsförslaget eller ett mail med information från kunden. Observera skillnaden mellanprojektoch kund i detta fall.Projektär mer, för och av, leverans medan kund är mer, för och av, sälj.

Utöver ovanstående som alla har tillgång till kommer det även finnas dessa för de medarbetare som behöver tillgång.

• Sälj & Marknad
• Ledningsgrupp
• IT
• Support

Etiketter eller taggar

För att förenkla sökningar och framförallt undvika att det skapas alltför många väldigt lika etiketter vill vi sätta ett prefix för vissa sökord.

_Kundnamn,kunders och leverantörers namn ska föregås av ett underscore. T.ex. _KUND1, _Kund2, _Kund3

_Leverantörsnamn, såsom _Magento, _Zend osv. Då det ofta är svårt att skilja på en leverantör och en kund har jag valt samma prefix för dessa.

.Projekt, projektets namn. Detta gör att ofta kan en notering taggas med två etiketter, t.ex. _kund1 och .kund1_PIM

Detta är som vanlig bara första iterationen och att vi kommer förbättra denna struktur så snart vi vet mer är självklart.