agemba og AgileLeanHouse

Transkript

1 Dette er historien om produktet agemba og Agile LeanHouse A/S, der så dagens lys i starten af 2015, og hvordan de strategiske valg både af produkt egenskaber og firmakonstruktion blev taget. Vi kommer langt omkring og langt tilbage, mange har påvirket os og har opmuntret os til at fortsætte. Læs med følg med på vores rejse. agemba og AgileLeanHouse Historien og baggrunden Version:

2 Copyright , AgileLeanHouse A/S. All rights reserved The content of this document is subject to change without notice and does not represent a commitment on the part of AgileLeanHouse A/S. AgileLeanHouse A/S makes no warranty of any kind with regard to this material. AgileLeanHouse A/S shall not be liable for any errors contained herein or damages, including any loss of profits, or other incidental or consequential damages, arising out of your use of this written material. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or information recording and retrieval systems, for any purpose, without the express written permission of AgileLeanHouse A/S. All registered and unregistered trademarks used in this document are the exclusive property of their re - spective owners. Document ID WP-??-001 Filename TheStoryBehindAgemba-DK odt Author Kurt B. Nielsen Revised of 13

3 Indholdsfortegnelse 1. Introduktion Baggrund generelt Hvorfor et værktøj som agemba? Hvorfor Agile Lean House? Hvor kommer navnene og logoerne fra? The AgileLeanHouse Pattern Hvad kan agemba værktøjet? System funktionalitet Standard Agile funktionalitet Udvidede Strategi funktioner Issue tracking funktionalitet Dashboard funktionalitet Integration Konklusion of 13

4 1. Introduktion Dette dokument blev til, fordi vi havde brug for at kunne fortælle folk, der var interesserede i alt det, vi har gang i i AgileLeanHouse, nogenlunde den samme historie; på tværs af tid og landegrænser. Vi ser AgileLeanHouse og vores nøgleprodukt agemba både som en forretning og noget der bør gøres, fordi det er rigtigt at gøre. Vi ser det både som vores opgave, men også som en "community" 1 opgave. Vi kan ikke løfte opgaven alene, vi må være et større team. Samtidig ville vi primært formulere historien til folk, vi deler interesse for sagen med. Det syntes lidt for meget af det gode bare at udstille alt på Internettet. Der er sikkert også nogle synspunkter og holdninger i dokumentet, som ville skabe unødig modstand i de tidlige faser af vores tilgang til markedet. Hvad er så "Sagen"? Hvad er det, vi brænder for? Det er forbavsende svært at udtrykke i en enkelt kort sætning. Det her er det bedste, vi har lige nu: Vi hjælper mennesker i organisationer med at vælge det rigtige at gøre, få mest mulig ud af deres indsats og fungere optimalt med det. Vi opnår dette ved at finde, arbejde med og udvikle de rette ledelsesprincipper, værktøjer og læringsmetoder. Vi bringer dem så til markedet til mennesker nationalt og internationalt. Det er naturligvis meget overordnet, men hold ud, detaljerne vil blive tydelig efterhånden. Igennem de sidste næsten 10 år har jeg arbejdet med Scrum, Agile, Lean og kompleksitetsteori mere generelt, og jeg har studeret baggrunden for ideerne og den praksis, der har udviklet sig. Det har radikalt ændret min forståelse af arbejde, organisation og ledelse. I vores Team har vi prøvet at afstemme og afprøve ideerne i praksis. Vi er kommet frem til, at vi bør gøre en indsats for at få denne viden og disse metoder ud til mennesker i organisationer bredt. Der er simpelthen for megen spildt indsats og for mange frustrationer derude, til at lade være. Mange har bidraget til hele denne videns- og erfaringsmængde, og vi står i dyb gæld til dem. Et lille udsnit er her: W. Edwards Deming, Peter Drucker, Robert Greenleaf, Peter Scholtes, Tom Gilb, James P. Womack, Jeff Sutherland, Ken Schwaber, Jeffrey Liker, Boris Gloger, Dave Snowden, Steve Denning, Gojko Adzic og David Allen. Alle har de bidraget med deres specielle vinkler uden hvilken, billedet ville være ufuldstændigt. Da jeg snublede over Scrum i Denver 2005, blev jeg grebet af enkelheden i principperne. Det var så enkelt at man praktisk taget kunne starte næste dag. Vi er så begyndt på at destillere alle disse gode menneskers input til et koncept og nogle værktøjer, der nok rækker udover det, fædrene 2 satte sig for at gøre med Scrum, men stadig er enkel og lavpraktisk nok til, at man kan komme i gang med det samme. Men at gøre tingene enkle er svært. Det er ingen sag at skabe et voldsomt Babelstårn af teorier, skemaer og bureaukrati, men det fungerer ikke i praksis, ingen kan huske på og leve med alle disse detaljer. Scrum kan formuleres på sider, PRINCE2 i sammenligning tager mindst 325 sider 3. Det er derfor, vi appellerer til vores "community" om hjælp. Ingen kan gøre dette alene eller bag lukkede døre. Opgaven er kompleks og forskellige perspektiver på den er nødvendige. Vi har haft en stor mængde mennesker igennem vore kurser og coaching aktiviteter de sidste år. Emnerne, vi beskæftiger os med i AgileLeanHouse, er blevet debatteret kraftigt under alle disse arrangementer. Utroligt mange er kommet med væsentlige og indsigtsfulde bidrag, hvilket vi er meget taknemmelige for. Det er disse menneskers behov, frustration og opmuntring, der har fået os til at realisere visionen. Januar 2015, Kurt B. Nielsen» It does not happen all at once. There is no instant pudding. W. Edwards Deming 1 I mangel af et godt dansk ord bruger vi "Community". Det skal ikke forstås som det klassiske Open Source community, hvor enhver snak om at tjene penge er no-go, heller ikke som en romantisk forsamling, der har alle ting fælles; Derimod blot som Webster's ordbog definerer det: "a body of persons of common and especially professional interests scattered through a larger society" 2 Ken Schwaber og Jeff Sutherland. 3 "Managing Successful Projects with PRINCE2", ISBN of 13

5 2. Baggrund generelt Igennem de sidste mange år har vi og specielt jeg undervist, coachet og fået input fra op imod mennesker på vore kurser og andre aktiviteter. Disse mennesker kommer fra alle mulige brancher selvom der naturligt nok er en overvægt af folk med IT-relaterede funktioner. Vi har også haft mange dialoger med mine kollegaer i Scrum verdenen og også med dem, der mener at Scrum ikke er sagen. Vi har i vores software firma og i non-profit arbejde selv arbejdet med principperne og brugt mange værktøjer. Vi har også brugt meget tid på at granske principper for ledelse og beslutningstagning, ja endda helt generelt, hvordan erkender og kommunikerer vi den virkelighed, vi står i, reelt og realistisk. Det er som om verden også i organisationer er blevet mere og mere polariseret med hensyn til ledelse. På den ene side har vi den klassiske Command and Control struktur, som kommer fra militærets ledelsesform for infanteriet pre På den anden side har vi det som Steve Denning har kaldt Radical Management, der bygger på at udvikle tilliden, styrkerne og ansvarstagningen i den enkelte og i teams, det er det vi finder i Scrum, Agile og Lean Thinking, men sjovt nok trækker dette princip også på erfaringer fra militæret men i stedet for på specialstyrkernes erfaringer, som f.eks. de danske jægertropper. Lige siden jeg for år tilbage havde et pænt stort sammenstød med en person, der skulle forestille at hjælpe vores organisation og tordnede: Tillid er godt, kontrol er bedre!, har jeg vidst, at jeg altid vil være på den anden side af hegnet. Den side, hvor lederne er parate til det slæbsomme arbejde med dag for dag at involvere sig med virkeligheden og menneskene, kunder og medarbejdere for at tjene dem og opnå størst mulig værdiskabelse 4. Specielt er jeg meget imponeret af Dave Snowden 5 fra Cognitive Edge og hans arbejde omkring kompleksitetsteori. Jeg har været på flere kurser hos ham og haft mange diskussioner med ham om disse emner. En anden, vi har lært meget af, er Tom Gilb 6 og hans fokus på værdiskabelse i projekter Impact Estimation. Det er en stor mangel i mange projekter, at der er stor fokus på eksekvering og omkostninger, men efter den indledende business case sjældent reel fokus på om de ønskede værdier nu opnås. Jeg besøgte ham privat i sommer og blev meget imponeret af hans indsigt, synd og skam at han ikke er mere kendt. Vi er begejstrede for Scrum, Kanban og hele Lean tankegangen. Men et par af de hyppigste kritikpunkter er: Hvor er det store overblik? og Hvordan opstår Product Backloggen 7?. Ofte er automatsvaret: Det finder Product Owneren ud af. Vi stødte også på begrebet Story Mapping - en variant af Mind Mapping, der bruges til at designe og visualisere løsninger. Efterhånden som vi brugte det i projekter, blev vi mere og mere overbevist om at en generalisering af Story Mapping sammen med det, vi havde lært af Snowden, Kano 8 og Gilb var måden at generalisere og syntetisere tankesættet på både strategisk og taktisk Hvorfor et værktøj som agemba? For et par år siden kom vores udviklingschef Karsten Mathiasen og jeg så til den konklusion, at der sim - pelthen var en hvid plet på landkortet, et hul i markedet, et værdigt problem at løse. Der er ingen, der hjælper den stakkels Product Owner 9 med værktøjer til hans strategiske arbejde med at holde overblikket og prioritere optimalt. De værktøjer, der er, er enten for tunge eller for 4 En af de tydeligste eksempler på polariseringen ser man i Bjarne Corydons udmeldinger omkring kontrol i den offentlige sektor januar 2015, f.eks. 5 Dave Snowden, se her 6 Tom Gilb, se her 7 I Scrum betegner "Product Backloggen" en ordnet liste af specifikationer af alle de ting vi gerne vil have leveret. Sprint efter Sprint tager vi så fra toppen af, netop den mængde af ting, Teamet mener at kunne klare at levere i Sprintet. Hvis I ikke er bekendte med Scrum princippet så læs for eksempel vores "Scrum i Fugleperspektiv" 8 Professor Noriaki Kano introducerede sin model i 80'erne, se her: 9 I Scrum er "Product Owneren" den, der tager ansvaret for at specifikationer er på plads og prioriterede, så der opnås maksimal "Business Value" ud fra indstatsen. 5 of 13

6 simplistiske og bogholderiagtige. På samme måde er der meget få værktøjer der skaber en øjeblikkelig synlighed af projekter og initiativer hele vejen op i organisationen. Den gode ledelse i en organisation har brug for et sandt øjebliksbillede for at kunne handle med "rettidig omhu", ikke en bureaukratisk konstrueret rapporteringsstruktur med stor tidsforsinkelse.» A perfection of means, and confusion Der findes mange fine værktøjer til Scrum, Kanban og andre patterns med fokus på eksekvering, på hvordan. Men der er sjældent hjælp at hente til at holde styr på: Hvorfor, hvem, hvad og hvornår. Det blev starten på det produkt, vi i dag har døbt agemba mere om navnet senere. Vi havde allerede leveret en del løsninger og havde et rigtig godt teknisk fundament at starte på. Det, vi satte os som primære mål, kan koges ned til to sætninger: agemba giver Product Owneren en interaktiv mulighed for at designe og skabe en generaliseret extended Story Map, der afbilder: Hvorfor, Hvem, Hvad og Hvornår, de elementer og sammenhænge, der er nødvendige at få en forståelse af, hvis man skal prioritere strategisk. agemba giver Product Owneren og andre højere oppe i organisationen et komplet øjebliksbillede på det rigtige detaljeringsniveau og de rigtige advarsler, hvis noget udvikler sig truende i projekter eller mere generelt initiativer. Selvom vi absolut er tilhængere af simple løsninger, hvor det slår til ingenting slår en tavle med post-it notes i fleksibilitet og overblik - så er der situationer, hvor de manuelle metoder ikke er tilstrækkelige. Vi kan for eksempel ikke skabe overblik over sammenhængene imellem "Hvorfor, hvem, hvad og hvornår" på en fysisk væg og være i stand til at raffinere den øjeblikkeligt og hele tiden. Vi kan ikke hele tiden manuelt krydsanalysere om vi skaber problemer med en afhængighed, hvis vi flytter en implementering fra et Sprint til et andet. Vi kan på samme måde ikke sørge for at der er total øjeblikkelig synlighed fra top til bund, hvis artifacts sidder fysisk på en væg. Alle mennesker i en organisation over 10 personer kan ikke sidde i samme rum og se alt samtidigt. Geografisk adskillelse af folk, der arbejder sammen er et faktum, vi er nødt til at forholde os til. Her er der virkelig noget reelt som computeren, netværket og Internettet kan gøre for os, som ikke kan lade sig gøre manuelt. En af de ting, vi har lært af Dave Snowden, er, at hvis man vil have mennesker til at ændre adfærd til det bedre, så skal man vise dem vejen, give dem værktøjerne til at gå den og være villig til at gå vejen med dem første gang. Vi ser agemba som et værktøj til organisationer, så de faktisk har mulighed for at ændre adfærd til det bedre og skabe mere værdi ifølge deres værdigrundlag, profit eller non-profit Hvorfor Agile Lean House? På et tidspunkt erkendte vi et par ekstra ting: of aims, seems to be our main problem. Albert Einstein Vi har ikke en chance som den lille organisation, vi er, for at komme bredt nok ud med vores løsning hurtigt nok, til at vi kan blive økonomisk bæredygtige og få tilstrækkelig "impact" altså, at det, vi gør, faktisk har en tilstrækkelig positiv virkning. Vi må være større hurtigst muligt. Vi erkender, at vi ikke har alle svarene, vi har ikke bredden af erfaringer til at kunne vælge den optimale timing og løsning til markedet. Det er ikke nok at producere verdens bedste løsning, der skal være nogen til at fortælle om den, overbevise folk, lære dem at bruge det og generelt hjælpe dem på deres vej til forandring. Vi kan sandsynligvis ikke skaffe funding i Danmark ad de sædvanlige venturekapital-veje og offentlige tilskudsordninger. Det er der mange grunde til men post-finanskrise Danmark er endnu mindre gearet 6 of 13

7 end før til at gå ind i noget der lægger op til større ændringer i adfærd. Vi var ret inspirerede af begrebet crowdfunding, men må konstatere at vi i Danmark har valgt at straffe os selv ved at forbyde de mest brugbare konstruktioner, selvom opstartsvirksomheder i både Tyskland og Sverige i stort omfang finansieres på netop denne måde herefter finanskrisen, hvor de finansielle institutioner er underlagt så megen kontrol og dokumentation, at man ikke skal forvente megen interesse for opstartsvirksomheder. Vi kom frem til, at vi måtte have en dedikeret organisation til at fremme hele ideen, og at vi selv måtte forsøge at skabe opbakningen både kompetence- og finansieringsmæssigt. AgileLeanHouse er derfor oprettet som et helt almindeligt dansk aktieselskab, i Danmark har vi en af verdens bedste lovgivninger omkring firmaer, så det er en god start. AgileLeanHouse skal udover at udvikle og markedsføre agemba, udvikle hele det idémæssige grundlag og andre værktøjer samt støtte vore kunder i at benytte værktøjerne og principperne. Vi ønsker bevidst at have en bred og gerne en skandinavisk måske international ejerkreds bag firmaet. Vi ønsker at have et bredt "community" til at komme med input til retningen af firma og produkter, til at bi - drage med dele til hele løsningen, software, videopræsentationer, illustrationer. Vi er ret fokuserede på det skandinaviske område da vi i denne kulturkreds har nogle af de bedste forudsætninger for alt Agile og Lean, vi har også vore egne udfordringer med Jantelov og den slags, men det er en anden snak. Sidst men bestemt ikke mindst ønsker vi at opbygge et korps af ambassadører, der ønsker at promovere principperne og løsningerne for at få så bred kontakt med markedet som muligt. Derfor operer vi med tre former for partnerskaber, som vi gerne vil invitere bredt til: 1. Ambassadører (Ambassadors) 1. Som ambassadør for AgileLeanHouse promoverer man hele konceptet og er med til at udstikke agemba s retning og udvalget af støtteværktøjer. 2. Ambassadører kan indføre agemba hos sine kunder og hjælpe dem til at få mest mulig udbytte af deres indsats. Formodentlig kan man tjene penge på denne måde. Alternativt kan man optjene agemba-point ved at udvirke salg af licenser. Det er bare vigtigt, at man gør sig klart, hvad man er overfor sine kunder rådgiver eller sælger. 3. Ambassadører deltager gratis i vores seminarer og uddannelse, ligesom de får al den support, de har brug for, for at blive succesfulde. 2. Bidragydere (Contributors) 1. Som Bidragyder vil man gerne løse konkrete opgaver. Et stykke software? En business site, hvor abonnementer kan tegnes? En rapport? En plug-in til et tredjepartsprodukt? En gennemgribende test af ny funktionalitet? Eller måske en introduktionsvideo? Mulighederne er uanede. 2. Bidragydere får naturligvis del i indtægterne i form af agemba-point. 3. Andelshavere (Shareholders) 1. Som Andelshaver (egentlig helt almindelig aktionær i et aktieselskab) er der mulighed for at hjælpe med at finansiere projektet og - hvis alt lykkes - få en pæn gevinst for en lille investering. 2. Andelshavere er med til at beslutte retningen for virksomheden og produktet. 3. Der er et internt marked for aktier, så man kan komme ud igen, hvis ens kurs i tilværelsen ændrer sig. Lige så vigtigt det er, at det er enkelt at komme ind, lige så vigtigt er det at kunne komme ud. Tanken er naturligvis at alle der bidrager også skal belønnes for det. Derfor er AgileLeanHouse's hele struktur, vedtægter, aktionæroverenskomst, udbytteprincip, bestyrelsesstruktur og -arbejdsform tilrettelagt for at tilgodese dette. Vi arbejder med agemba-point, som optjenes for indsats; disse point kan veksles til enten kontanter eller ejerandele (aktier) efter faste regler. 7 of 13

8 2.3. Hvor kommer navnene og logoerne fra? Der er i dag ikke et entydigt begreb, der dækker over det vi gerne vil med AgileLeanHouse, nogle taler om Radical Management, nogle taler om Servant Leadership andre igen om værdiskabende ledelse. Helt sikkert er det, at der er meget fra "Agile" bevægelsen, vi kan skrive under på, og også fra hele "Lean Thinking" verdenen, der spænder videre end "Agile". Tanken om et hus med mange rum og plads til mange var tiltalende, ja og så var domænenavnene "AgileLeanHouse.com" og ".dk" ledige AgileLeanHouse var født. Oveni kunne vi vældig godt lide det japanske Kanji symbol for hus " 舎 ", meget illustrativt og nemt at huske hvordan man tegner det i en håndevending. Undervejs i processen talte vi ofte om at vores produkt var et "virtuelt Gemba". "Gemba" er et begreb der bruges meget i Lean. Det er også japansk ( 現 場 ) og betyder det rigtige sted, der hvor det virkelig forgår. Egentlig var det måske mere korrekt at oversætte det som "genba", men versionen med "m" er mest kendt. I fysisk produktion betegner Gemba ofte produktionsstedet, hvor maskinerne kører og folk arbejder. Det er en del af the Toyota Production System (TPS) og Lean generelt, at hvis man virkelig vil forstå tingene skal man gå til "Gemba" og ikke stole på rapporteringer på afstand. Japanerne har et udtryk for dette også: "Genchi Genbutsu" ( 現 地 現 物 ), som kan oversættes ved "gå selv hen og se". Det blev så til agemba som en sammentrækning af "Agile" og "Gemba". Som man kan se ovenfor optræder et af Kanji symbolerne flere gange: " 現 ", det udtales normalt "gen" og betyder realitet og virkelighed i modsætning til det man bare tror er sådan. Det var et meget passende logo for produktet, vi vil virkelig gerne skabe maksimal synlighed og konfrontere alle med virkeligheden som den er, så de kan reagere maksimalt fornuftigt.» It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so. Mark Twain 3. The AgileLeanHouse Pattern Lige som Scrum ofte betegnes som et "Organizational Pattern" altså et mønster at følge, vil vi gerne formulere vores "AgileLeanHouse pattern, som basis for vore løsninger. For nemheds skyld vil vi det følgende betegne dette mønster "ALH". ALH er ligesom Scrum ikke "rocket-science" og vi påstår heller ikke at vi har opfundet de forskellige elementer, det gjorde fædrene bag ved Scrum heller ikke. Det vi har gjort er at tage input fra en masse begavede mennesker, finpudse kanterne så alle deres ideer og principper kan bruges sammen og så pakke det pænt ind. Når man ser bort fra det, der er meget IT specifikt, så handler Scrum, Kanban og andre agile metoder om, hvordan vi får ting gjort, og hvordan vi undervejs tilpasser os til den virkelighed som gradvist åbenbarer sig for os. Erkendelsen er at den stor forkromede up-front plan er en illusion, da vi sjældent har al relevant viden fa starten af. Alt det er helt perfekt, det udfordrer vi ikke. Det vigtigste i Agile er principperne bag, men det man kan se udefra, kan illustreres med en terning, som man kan dreje og se virkeligheden igennem de klassiske artifacts: Product Backlog, Sprint Backlog/Kanban-board, Impediment/Im- 8 of 13

9 provement Backlog og Burndowns og -ups. Eller foldet ud: Det, vi så har lært fra alle dem, der har arbejdet med det mere strategiske er, at vi skal have følgende elementer med ind i tillæg: Why Hvorfor. Hvad er det vi vil opnå? Hvilke værdier eller kvaliteter vil vi høste, hvilke risici vil vi imødegå? Hvor er Impact'en? Hvordan kan vi måle og verificere en effekt? Hvilke "Issues" eller problemer har vi? Hvilke ideer til forbedring har vi? Dette er en Value Map, nogen kalder den en Impact Map 10. Who Hvem. Hvem er det vi betjener, hvem har gavn af det vi gør, hvem bruger det, vi frembringer? Dette er en Stakeholder eller User Persona Map. What Hvad. Hvad er det vi frembringer? Hvad er vores strategi for at opnå de ønskede værdier eller kvaliteter? Hvordan kan vi sammen med vores Stakeholders forstå og være enige om, hvad vi mener. Hvordan kan vi fastholde overblikket, når man gradvist bryder mere og mere ned, så tingene faktisk kan udføres? Dette er den klassiske Story Map. When Hvornår. Hvilke deadlines har vi, der kommer udefra? Hvilke Releases eller faser tænker vi at arbejde i? Hvornår skal vi levere noget ud? Hvornår får vi noget leveret ind? Hvilke egne milestones har vi sat? Dette er en Timeline Map. Disse fire områder vil man konstant skifte frem og tilbage imellem, når man arbejder strategisk med at komme op med et forslag til handling for at opnå noget. Informationerne i hver område bliver typisk formuleret som fortællinger, vi bruger ordet narrative som den generelle beegnelse. Vi kalder alt dette et "Inititativ", nogen gange er det projekt, nogen gange mere generelt. Visuelt tænker vi på disse som værende hver deres hierarkiske struktur, som en Mind Map, med relationer imellem de enkelte elementer. Vi kalder det en extended Story Map. Vi har afbildet dem i fire trekanter, som her. Når man folder disse bliver det til en pyramide, der er en overbygning over den traditionelle Agile terning ovenfor. Dette er meget illustrativt for, hvad vores ALH mønster går ud på: Det er en overbygning på traditionel Scrum, Agile og Lean, det giver et simpelt mønster at følge for den strategiske del af arbejdet: "Hvad er det vi skal satse på at gennemføre". Som et kuriosum, når de to figurer sætte sammen, ja så får man et sammenhængende hus et AgileLeanHouse. Når man står overfor at skulle gøre noget, tage et initiativ, have hænderne op af lommen, enten drevet udefra eller fordi man vil forbedre noget innovation, så kan man følge ALH mønstret, der er en form for omvendt byggeprojekt startende med tagkonstruktionen: 1. "Roles". Der må være én, der tager ansvaret for Initiativet, som til alle praktiske formål er samme rolle som en "Product Owner" i Scrum, dvs. den der tager ansvaret for at skabe den bedst mulige værdi ud af Initiativet med de givne begrænsninger. Der må også være Stakeholders, som kan og vil deltage i samspillet om at skabe det bedst tænkelige Initiativ. Nogen gange er dette brugere, nogen gange en ledelse, nogen gange er det kunder og andre gange en blanding af det hele. ALH er et mønster ikke en checkliste. 2. "Must Haves". Start med at sætte det, der er givet, på landkortet: De værdier der skal opnås, de trusler eller risici, der skal imødegås, de Stakeholders vi skal forbedre noget for, de deadlines der er givet 10 Se Gojko Adzic: Impact Mapping, ISBN of 13

10 og de ting vi ved skal gennemføres. Altså et landkort for hver af de givne rammer i de fire "W" områder: Why, Who, When and What. Det er et "Must Have Constraints" map. 3. "The Authentic Epics". Prøv skabe den første master fortælling (narrative) af hvad ("What"), man kunne gøre. Skab den som en serie af fortællinger (Stories), der tilsammen ville tilfredsstille "Must Haves", så vidt vi kan se. Dette er sikkert temmelig store fortællinger, vi kalder dem "The Authentic Epics". 1. Nogle gange kommer disse første Epics udefra, Stakeholders har måske allerede en form for kravspecifikation. 4. "Authentic Epic Refinement". I dialog med Stakeholders, raffineres "The Authentic Epics", Stakeholders skal kunne forstå disse Stories, det bliver den fremtidige kommunikationsplatform med dem. Det vil normalt være et iterativt forløb, hvor man gradvist kommer tættere og tættere på noget, der plausibelt vil løse "Must Haves". 1. Hovedfokus her er Values, prøv at fokusere på Must Have og vigtige Values, de som betyder mest for Stakeholders, identificer strategier for at opnå disse Values. Skab Epics og Stories der bidrager (Contribute) til værdierne eller kvaliteterne (Values). 2. Ofte dukker der i denne dialog flere potentielle "Must Haves" op, disse skal udfordres om de virkelig er "Must Haves". Hvis alt er bundet er der ingen frihed til at finde optimale løsninger. 3. Der kan også dukke detail-afklaringer til nogle af beskrivelserne under "What" op, vi kalder dem gerne "Acceptance Criteria". 4. Man opdager også ofte andre Values, som er relativt nemme at høste, når nu disse "Must Haves" skal opfyldes, eller andre Stakeholders, der kan tilfredsstilles, med begrænset indsats. 5. Man opdager også ofte flere Milestones, der kan være afgørende, såsom afhængigheder til leverandører eller andre afdelinger. 6. Når denne fase er overstået, skal man stå med hele tagkontruktionen i skeletform populært sagt, den første fælles version af alle fire flader af pyramiden. Hver af siderne skal være plausible og Stakeholders skal kunne forstå, hvad der tales om (det skal de udtrykke), og den, der har ansvaret for initiativet skal tro på det, ellers er det en "ommer". 5. "Strategic Hardening". Dernæst går man i gang med at trykprøve Initiativet. Det kan indebære en eller flere af de følgende discipliner» There is nothing so useless as doing 1. Relevante Values brydes i mindre "Value Stories" indtil man kommer til et punkt, der er simpelt nok til at måle og verificere om, man har opnået det man ønskede, vi kalder disse for Impacts. 2. Skab en matriks over de vigtigste Values og de forskellige Epics der bidrager til at skabe disse værdier. Tom Gilb anbefaler at man maksimalt beskæftiger med en matriks på 10 gange 10, for at vurdere, hvad der bidrager til hvad og få et overblik. Dette er Impact Estimation Relevante Epics vurderes ved hjælp af Kanos principper sammen med Stakeholders for at afklare om denne Epic er "Dis-satisfiers", "Satisfiers", "Exiters", "Reverse" eller "Indifferent", måske skal scopet justeres for hvilke Stakeholders vi kan tilfredsstille. 4. Ud fra disse to skulle man gerne have en overbevisning om hvordan værdierne i Initiativet genereres, og hvor usikkerheder gemmer sig.» It is always wise to look ahead, but 5. Relevante Epics vurderes for kompleksitet (Snowden), hvis der er komplekse Epics må vi planlægge med eksperimenter og det er spildt indsats at forsøge at planlægge detaljeret på den anden side af disse eksperimenter upfront. efficiently that which should not be done at all. Peter Drucker difficult to look further than you can see. Winston Churchill 11 læs mere om det hos Tom Gilb på eller her 10 of 13

11 6. Relevante Epics estimeres for størrelse af relevante personer ideelt det Team, der skal udføre opgaverne. Disse brydes ned indtil et estimat er plausibelt at gennemføre. 7. I denne fase får man også ofte afdækket om man mangler ressourcer, tids- eller vidensmæssigt. 8. Man samler så en passende mængde af Epics til den første fase (eller release), som er plausibelt at gennemføre i et bestemt tidsrum, og som bringer en fornuftig værdi til bordet, og overholder alle rigtige Must Haves, dvs. som minimum, at de ting, der er deadlines på, er overholdt. Der er sikkert også foretaget en vurdering af hvor de resterende Epics er placeret rent tidsmæssigt 9. Ved afslutningen af denne fase har man så det man kunne kalde en RoadMap, en Release- eller fase plan, en Product Backlog. Dette reviewes og verificeres med Stakeholders. Herefter kan man gå fra tagkonstruktionen ned til selve bygningen, man fokuserer nu på "How". Man har første version af en Product Backlog og kan gå i gang med at eksekvere. Man er nu i kendt territorium, hvor alt hvad vi allerede ved om Scrum, Kanban, Agile og Lean bringes i spil. Og det skal vi ikke her trætte med at gennemgå igen. Undervejs, Sprint efter Sprint (eller kadence efter kadence, hvis man er til Kanban terminologi), arbejdes der iterativt, Epics brydes ned og bliver til sidst til Stories, der kan udføres. Det betyder også, at nogen gange sker der ændringer, der påvirker den tagkonstruktion den strategiske plan, vi startede med. Efterhånden som forventninger i Initiativet veksles til fakta, afspejler det sig i tagkonstruktionen. Stakeholders kan følge udviklingen i de termer, de selv har været med til at definere, og som vi derfor må forvente de forstår. Det, der sker nede i bygningen, bliver øjeblikkeligt synligt i tagkonstruktionen i. Stakeholders kan følge estimater, værdiskabelse, færddiggørelsesgrader, hastigheder og meget andet. Det aggregeres op på de Authentic Epics som de selv har været med til at definere.» "Plans are only good intentions unless they immediately degenerate into hard work." Peter Drucker 4. Hvad kan agemba værktøjet? Vi skal ikke her forsøge en komplet beskrivelse, men blot gennemgå nogle hovedpunkter, der er væsentlige for at kunne se værdien i løsningen. agemba kan bruges in-the-cloud, det kører i øjeblikket på Amazon Web Services på en Linux platform, men da det er bygget på standard open-source værktøjer (specielt Enterprise Content Management systemet Alfresco), kan det også stilles til rådighed for organisationer, der vil installere det i egne netværk, vi kalder det Enterprise løsninger. Der er ikke benyttet værktøjer eller komponenter, som er befængt med licensafgifter. agemba klient-delen er ren Javascript og kan afvikles i alle standard browsere uden installerede plug-ins. Der er desuden en responsive del, som kan afvikles på tablets og mobil System funktionalitet 1. agemba understøtter flere Domæner per instans, altså et multi-tenant koncept. Hvert Domæne har egen konfigurering af relevante opsætningsparametre. 2. Hvert domæne har en eller flere Initiativer. Hvert Initiativ har egen konfigurering af relevante opsætningsparametre. 3. Hver Initiativ kan have taktisk eksekvering tilknyttet (et Team f.eks.), eller det kan være et udelukkende et strategisk initiativ, hvor Epics delegeres til andre Initiativer, der så må formodes at have taktisk eksekvering. 4. Brugere kan inviteres fra et Domæne ind i et andet, så f.eks. kan en konsulent på denne måde være kendt hos to forskellige kunder. 5. Grundlæggende er alle Values, Risks, Epics, Milestones osv. af natur Stories, dvs. de har en tekstmæssig beskrivelse med normal syntax og tegnsætning af, hvad de betyder. De har også egenskab af en folder eller en container. Dvs. man kan gemme ekstra oplysninger, dokumenter, billeder, screen-dumps og 11 of 13

12 andet direkte på den relevante Story. Ligeledes kan man kommentere på Story'en og de ændringer der foretages. 6. Alle ændringer på enhver Story logges. Det vil sige, der er en sporbarhed af alle ændringer i specifikationer, acceptans kriterier, opbygning af Story Map, mm. 7. På en Epic eller Story i What delen (den klassiske Story Map) er der en række oplysninger, som kan bruges af Product Owneren: 1. Estimat af Size (arbejdet størrelse) med værdi for expected og worst case så risiko kan beregnes. 2. Estimat af Kano parameter: Dissatisfier, Satisfier, Exiter, Reverse, Indifferet, hvilket påvirker vurderingen af business value. 3. Estimat af Business Value med værdi for expected og worst case så risiko kan beregnes. Heri indgår også Impact Estimation (a la Tom Gilb), hvilke Values bidrager denne story til. 4. Estimat of Complexity (ifølge Dave Snowden), så det afgøres om, der er behov for eksperimenter eller foranalyse. 8. Workflow af Stories, Tasks, Sprints, Kanban osv. kan tilpasses. Det er primært i øjeblikket tænkt til Enterprise løsninger. 9. Der kan automatisk produceres Alerts, hvis Stories bliver blokeret, Milestones nærmer sig, Values ikke bliver høstet, fremdriften falder osv. Alerts kan være s, screen pop-up, dashbord oversigt, mm. 10. agemba er målrettet mod samarbejde (collaboration), derfor pushes alle ændringer ud til klienterne. Dvs. hvis en ændring gennemføres på Skærm #1, dukker den automatisk op på Skærm #2 (og flere naturligvis), hvis ændringer falder inden for Skærm #2's interest-area Standard Agile funktionalitet 1. Der kan arbejdes med en Backlog for hvert Initiativ. Der kan være nul, én eller flere Releases eller Faser. Hvis der ingen er, arbejdes der med kontinuert leverance (som i Kanban). 2. Den konkrete udførelse af opgaver (arbejde med Tasks), kan styres efter Scrum princippet (Sprints), Kanban eller en kombination, hvis man har både projekt orienteret og hændelsesstyret arbejde. 3. Der er standard Burndown charts Udvidede Strategi funktioner 1. Først og fremmest er der extended Story Map, der er implementeret i SVG, så der kan zoomes og navigeres som i et interaktiv kort. Alle de fire W'er (Why, Who, What and When) kan afbildes og relationer imellem dem skabes, ses og krydsanlyseres. Forskellige skins kan vælges. 2. Der kan derfor opbygges en klassik Story Map over det, der skal udføres ( What delen). Alle ændrin- 12 of 13

13 ger, der sker på Stories dybt nede, aggregeres automatisk op igennem hierarkiet. Og status kan kommunikeres til Stakeholders på Authentic Epics, også hvis en Epic er delegeret fra et andet Initiativ. 3. Der er en avanceret bruger interaktion, så alle strategiske sammenhænge kan kryds-tjekkes og fastholdes Issue tracking funktionalitet 1. Hvis man skal arbejde agilt, kan det ikke nytte, at spiuld ekostbar tid og båndbredde på atskal rundt i en mængde forskellige systemer for at få sit input. Agemba har derfor sin egen issue tracking funktionalitet, hvor emner af værdi kan registreres og spores. 2. Stakeholders kan registrere Issues og Ideas, medarbejdere kan registrere Impediments og improvements (som drejer sig om arbejdsmetoden). Alt dette kan ses og analyseres sammen med de mere komplekse Values, når Product Owneren skal planlægge, hvad kræfterne skal bruges på. Han kan for eksempel oprette en Story og fortælle systemet at dette implementerer Issue #117 og Issue # agemba kan naturligvis også integreres med et allerede eksisterende system såsom Jira Dashboard funktionalitet 1. agemba har naturligvis sit eget Dashboard, hvor brugerne kan sætte op, hvad de ønsker at have på deres favorit oversigtsbillede (en eller flere). 2. Dette kan også bruges til at skabe generelle informationsskærme, kiosk-agtige applikationer. Simpelthen: definer et agemba dashboard og lad det vise automatisk på en eller flere storskærme (eller tabletter). På grund af agemba's avancered push teknologi opdateres alt automatisk. 3. Derudover kan standard værktøjer bruges. Data kan hentes ud af agemba og nemt formateres i forskellige standard software løsninger. Vi bruger for eksempel i udstrakt grad Google's applikationer (f.eks. Sheet) til at hente data ud, formatere og præsentere nye og interessante artifacts, der giver mening for Stakeholders Integration 1. agemba har et rigt rest API, hvor system integratorer (eller ambassadører) kan hente data ud og skabe ekstra værdi for deres kunder. De kan imidlertid også lægge nye ting ind: Stories, Issues osv. 2. Det er planlagt at agemba skal integreres med i hvert fald Jira og MS TFS, sådan at de grundlæggende beskrivelser stadig ligger i disse systemer og agemba benyttes til de avancerede Strategiske tiltag. Det er noget af det vi håber vore Bidragydere kan byde ind med. 3. Man kan benytte import- og eksport faciliteter, til forskellige mere batch betonede integrationer. Stories er måske allerede beskrevet i et regneark, det kan importeres. Måske ønsker brugerne at bruge et velkendt værktøj, f.eks. Trello eller ScrumWise til at styre den taktiske afvikling, et planlagt sprint fra agemba kan eksporteres og status importeres tilbage igen.» We keep moving forward, opening new doors, and doing new things, because we're curious and curioisty keeps leading us down new paths. Walt Disney 5. Konklusion agemba og AgileLeanHouse A/S er noget helt nyt og en helt ny måde at gøre tingene på. Vi er vældig opsatte på at få hele konceptet til fungere. Vi er også overbeviste om, at vi kan bidrage med noget nødvendigt og positivt til den måde vi leder vore organisationer og skaber resultater på og tjene en ærlig mønt undervejs. Vi håber at tiltrække et bredt spektrum af personer med forskellige kompetencer, der kan dele vores vision tilstrækkeligt til at ønske at være med. 13 of 13