Agile has long shunned up-front design. When Agilists force themselves to do up-front work, it usually is limited to a symbolic use of User Stories for requirements and metaphor for architecture, with much of the rest left to refactoring.

Experience and formal studies have shown that incremental approaches to architecture can possibly lead to poor structure in the long term. This course shows how to use domain analysis in a Lean way to build an architecture of form that avoids the mass of structure that usually accompanies big up-front design, using only judicious documentation.

The course will guide you specifically how to fit architectural planning into your Scrum framework. While these principles apply broadly to any Agile development shop, we will go into Scrum specifics according to the interest of the attendees. Build on what has been proven to work instead of figuring it out yourself! (For a teaser, see: http://www.leansoftwarearchitecture.com/home/engaging-the-stakeholders)

It will also show how architecture can accommodate incremental addition of features using Trygve Reenskaug’s new DCI (Data, Context and Interaction) approach, and how it maps elegantly onto C++ implementations.

The course is based on the Wiley book of the same title (http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470684208.html).

Teachers: James O. Coplien and Gertrud Bjørnvig

Language: English

Location: Trifork A/S, Spotorno Alle 4, 2630

Duration: 2 days, both days from 9 a.m. – 5 p.m.

Price: 11500 ex. Vat, including course materials and meals.

Læs vores kursusbetingelser her

Tilmelding via mail eller tlf. 8732 8782

Hvorfor skal vi interessere os for Lean Product Development (LPD)
Lean er igennem de sidste 30 år gået fra en være forbeholdt enkelte virksomheder i Japan til at have influeret, hvordan stort set alle producerende virksomheder i verden driver deres forretning. Hvorfor? Fordi de, der ikke har gjort det, ganske enkelt ikke har kunnet holde sig konkurrencedygtige og derfor enten har adopteret hele eller dele af Lean-filosofien eller simpelthen har måttet lukke forretningen.

Selvom produktudvikling langt fra er karakteriseret ved det samme standardiserede forløb som en produktionsproces, har det vist sig at brugen af Lean kan revolutionere tilgangen på tilsvarende måde. Det skyldes, at der også i produktudvikling gemmer sig spild, ventetid, flaskehalse, kvalitetsproblemer og lagre af information, der overgår de flestes fantasi. Tænk blot på hvor meget tid og ressourcer der ofte er investeret i kode, analyser og diagrammer, der endnu ikke har skabt forretningsværdi og i værste fald aldrig kommer til at gøre det. Det kan der dog gøres noget ved, og gevinsten er så stor, at vi også i produktudvikling på længere sigt vil opleve den samme forskel på dem, der forstår at udnytte potentialet i Lean, og dem, der holder fast i deres traditionelle tilgang.

Agile metoder som Scrum, Kanban, Feature Driven Development og Extreme Programming baserer sig i mere eller mindre bevist grad på kerneelementer i Lean som: Små ”batches”, eliminering af spild, løbende forbedringer, fokus på kvalitet, visualisering og ikke mindst hurtige feedback mekanismer. Den gode nyhed er altså, at mange virksomheder, der arbejder med software, allerede er i gang med at udnytte den konkurrencefordel, Lean kan give. Men hvor agile metoder længe har fortalt os ”hvordan”, kan Lean hjælpe os med at forstå ”hvorfor”. Det giver konkrete værktøjer og viden til at forbedre processen udover de til tider overfladiske og svagt funderede agile tiltag.

Hvordan kommer vi i gang med LPD?
Har du lyst til at vide mere om Lean i produktudvikling, tilbyder Trifork kurser og on-site sparring. Et centralt princip i Lean er, at forbedringsinitiativer drives af alle i virksomheden og skal potentialet veksles til positive tal på bundlinjen, er det vigtigt at få alle med. Kurser og sparring i Lean produktudvikling inkluderer bl.a. følgende elementer:

• Value Stream Mapping
• Identificering af spild
• Forståelse af Pull vs. Push systemer
• Optimering af flow
• Opbygning af en forbedringskultur (Kaizen)
• Visualisering af workflow
• Etablering af de rigtige målinger (Cumulative Flow Diagrams, Cycle Time, Lead Time, Defect Rate…)

Softwarebranchen har længe været på forkant med brugen af LPD og er ifølge bl.a. forfatteren til en lang række bøger om emnet, Don Reinertsen, langt foran også Toyota på dette punkt. Vi hjælper derfor også gerne din virksomhed, selvom jeres produkter ikke nødvendigvis består af 0- og 1-taller. Pointen er at lære at se produktudvikling i et nyt lys og lægge de traditionelle og ofte administrativt tunge metoder bag sig, så en større del af kræfterne kan fokuseres på at skabe forretningsværdi, reducere time-to-market og maksimere ROI.

Se planlagte kurser i vores kursuskalender

Kontakt: training@trifork.com eller tlf. 8732 8782

Beskrivelse
Kanban eller mere præcist “Kanban system for software development” repræsenterer en mere direkte implementering af Lean i softwareudvikling end traditionelle Agile metoder. Med sit store fokus på flow og projektets kontekst er Kanban efterhånden blevet et populært supplement til de mere dogmatiske planbaserede tilgange  til Agil udvikling som eksempelvis Scrum.

Ordet Kanban er japansk og betyder “visuelt kort”. Den store udbredelse skyldes at det gennem årtier også er blevet brugt til at beskrive det system, der bruges hos Toyota, til visuelt at styre og balancere hele produktionslinjen og er dermed blevet næsten synonymt med implementeringen af Lean. Så selvom Kanban er et relativt nyt koncept i softwareverdenen har det været brugt i mere end 50 år i Lean produktion.

Brugen af Kanban i softwareudvikling er pioneret af David Anderson, der i tæt samarbejde med blandt andet Don Reinertsen har gjort meget for at udbrede kendskabet til værdierne i Lean og synliggjort hvordan Kanbansystemer kan bruges i software til bedre at visualisere og optimere workflowet. 

Hvornår skal jeg overveje at implementere Kanban?

Hvis du kan nikke genkendende til en eller flere af nedenstående statements er der en god chance for at det vil være interessant for dig at vide mere om Kanban:

• Kæmper du med at implementere Agil udvikling i din organisation uden det store held?
• Har du lavet Agile udvikling i lang tid og har efterhånden svært ved at finde noget, der kan forbedres?
• Bruger du meget af din værdifulde tid på rigide “Agile” praktikker, der ikke længere synes at passe til den kontekst, du arbejder i?
• Har du brug for større fleksibilitet end det den frosne plandrevne iteration kan tilbyde?
• Skifter dine prioriteter dagligt?
• Bruger du processer designet til Agil produktudvikling i en kontekst, hvor det ikke passer særlig godt?

Langt de fleste Agile virksomheder vil have glæde af at have Kanban i deres værktøjskasse.

Hvad er Kanban?
Der findes forskellige tilgange, men de fleste er enige om, at Kanban fokuserer på følgende principper:

• Visualize Workflow
  • Synliggør alle de stadier dine “opgaver” gennemgår fra idé til release
• Limit Work-In-Progress
  • Sæt eksplicitte grænser for mængden af igangværende arbejde i hvert stadie
• Deliver Often
  • Lever så ofte til din kunde, som det giver mening for at sikre hurtigt feedback og så lidt kapital og tid bundet i igangværende arbejde som muligt
• Focus on Quality
  • Fokuser på kvalitet. Kun gennem “Quality Built In” kan du sikre et stabilt flow, fokus og et minimum af fejlrettelser der forstyrrer det igangværende arbejde
• Prioritize
  • Prioriter dine opgaver så du laver det vigtigste først og kun det brugerne efterspørger
• Measure and Manage Flow
  • Mål dit flow, så du synliggør konsekvensen af forbedringer og uhensigtsmæssige handlinger
• Identify Improvement Opportunities
  • Skab en kultur hvor løbende forbedring drives af alle i organisationen

Folk med kendskab til Lean vil genkende mange af disse som udgangspunktet for at implementere et lean “pull scheduling system”.

Herunder ses et simpelt eksempel på et Kanban system, hvor de specifikke grænser for igangværende arbejde er synliggjort (rød).

Hvordan starter vi med Kanban?
Det er selvfølgelig altid en fordel at have tilegnet sig noget grundlæggende viden, inden man kaster sig ud i brugen af et nyt værktøj, men faktisk er det utrolig nemt at komme i gang med Kanban.

Kanban har nemlig en evolutionær tilgang til procesforbedring, og første skridt er derfor at få visualiseret den nuværende proces I arbejder efter. Når det er gjort sættes WIP grænser for de individuelle stadier, og I er nu allerede på vej til at identificere og løsne op for de flaskehalse, der forhindrer jer i at følge en agil/lean udviklingsproces. Over tid vil I gradvist ændre hele eller dele af processen og gennem løbende forbedring bevæge jer mod det optimale fit i jeres kontekst.

Hvor kan Kanban bruges?
I Trifork har vi efterhånden hjulpet mange virksomheder med at implementere Kanban. Først virkede det som om det primært var i drift og vedligehold, at Kanban havde sin berettigelse, men de seneste år har overraskende mange agile udviklingsprojekter også haft stor glæde at benytte Kanbanprincipper som supplement og gradvis erstatning for eksempelvis Scrum. Derudover har Kanban vist sig helt ideelt i organisationer, der benytter vandfaldinspirerede udviklingsmetoder og har behov for en gradvis overgang til agil produktudvikling.

Typiske misforståelser

• Myte: Kanban egner sig kun til teams med små ensartede opgaver som eksempelvis drift og vedligehold
• Fakta: Kanban er kraftigt inspireret af Don Reinertsens arbejde med Lean produktudvikling og har vist sig mindst lige så anvendeligt i udviklingsprojekter

• Myte: Kanban er en modsætning til Scrum
• Fakta: Der er ingen af principperne i Kanban, der siger, at du ikke må benytte Scrum. Kanban driver forandring, og principperne i Scrum bør i den optik kun benyttes, hvis de er med til at optimere dit flow. Du kan derfor fint starte med Scrum og derefter benytte Kanban-principperne til at optimere din metode yderligere – det har rigtig mange faktisk haft stor glæde af

• Myte: Kanban benytter ikke iterationer
• Fakta: Iterationer er ikke obligatoriske, men bør benyttes hvis det kan optimere flow, feedback og kvalitet

• Myte: Med Kanban må du ikke estimere
• Fakta: Estimater er ikke obligatoriske, men benyttes hvis der er brug for det i projektets kontekst. Langt de fleste, der benytter Kanban i udviklingsprojekter, benytter en eller anden grad af estimering for at sikre den bedste prioritering og alignment.

• Myte: Kanban er bedre end Scrum/XP/Crystal osv.
• Fakta: Kanban er først og fremmest en tilgang til at drive forandring og har derfor brug for et grundlag. Selvom rigtig mange projekter har stor glæde af principperne i Kanban, er det ikke en erstatning for f.eks. Scrum. Faktisk er Scrum et rigtig godt udgangspunkt og uden det, havde Kanban sandsynligvis ikke haft nogen større udbredelse.

Se vores Kanban firmakurser her

Kontakt: training@trifork.com eller tlf. 8732 8782

Lean produktudvikling

Primær målgruppe er ledelsen. Deltagerne får viden om, hvorfor det er vigtigt at benytte Lean til softwareudvikling. Hvilke økonomiske konsekvenser ( Se Don Reinertsen)

Beskrivelse om indhold og økonomi mangler.

En halv dag/ 2-3 timer

Pris DKK 25.000, pr. hold