Dersom du vil prøve deg på samme øvelse, inneholder denne artikkelen litt informasjon for å komme i gang. Start med koden under og følg feilmeldingene. Send en kommentar dersom du ikke kommer videre fra en feilmelding, så får vi en FAQ.

Oppgaven

Løs et så enkelt som mulig problem som involverer websider og database med så enkel teknologi om mulig.

Oppgaven jeg har laget går ut på å opprette personer med fullt navn og søke etter personer basert på navnet deres. For å gjøre oppgaven så lite som mulig har jeg valgt å la personer kun ha ett informasjonsfelt: Fullt navn. Denne oppgaven tar cirka 2-3 timer uten øvelse og du kan få den ned i 60-90 minutter med trening.

Du kan naturligvis velge en annen oppgave, men uansett hva du velger: Det er mer lærerikt å gjenta den samme oppgaven flere ganger enn å utføre en avansert oppgave.

Når jeg utfører oppgaven er det viktigste jeg lærer meg å forstå feilmeldingene som guider meg gjennom utviklingen. Dersom du trenger hjelp til å komme til de første feilmeldingene kan du se resten av artikkelen.

Steg for steg: Startpunktet

Selv om jeg valgte veldig enkel teknologi for implementasjonen, har jeg valgt et større sett med biblioteker for å skrive testene. Jeg bruker følgende når jeg skriver testene:

• JUnit 4.6
• Jetty 6.1.22
• HSqlDb 1.8.0.10
• WebDriver-HtmlUnit 0.6.1039
• Mockito 1.8.0
• FEST-assert 1.2 (ikke påkrevd, men gjør testene søtere)

Den eneste teknologien jeg har valgt for implementasjonen er Servlet-API 2.5 og Hibernate-Annotations 3.4.0.GA.

For at du skal slippe å plundre så mye med avhengigheter før du kommer i gang har jeg laget en pom.xml-fil som du kan ta utgangspunkt i.

Web-tester

For å starte utviklingen, er det lurt med en test som starter på utsiden av applikasjonen. Noe slikt:

1. Start opp miljøet
2. Legg inn en person
3. Søk etter personen

Slik kommer du i gang med en test som går mot en web applikasjon:

int SERVER_PICKS_PORT = 0;
org.mortbay.jetty.Server server = 
       new org.mortbay.jetty.Server(SERVER_PICKS_PORT);
server.addHandler(
       new org.mortbay.jetty.webapp.WebAppContext("src/main/webapp", "/"));
server.start();
 
int serverPort = server.getConnectors()[0].getLocalPort();
 
org.openqa.selenium.WebDriver browser =
       new org.openqa.selenium.htmlunit.HtmlUnitDriver();
browser.get("http://localhost:" + serverPort + "/");
browser.findElement(By.linkText("Create person"));

Dette oppsettet forventer å finne web.xml-fila på src/main/webapp/WEB-INF/web.xml.

Funksjonell test

En funksjonell test definerer kravene i applikasjonen. Det er lurt å gjøre funksjonelle tester så raske som overhode mulig, samtidig som de går gjennom alle kravene. En funksjonell test trenger ikke være en ende-til-ende test, slik som eksempelet over. Dette er viktig, fordi ende-til-ende tester er ofte veldig trege. Her er noen eksempler på funksjonelle tester:

• Vis en siden for å opprette nye personer
• Opprett en ny person
• Verifiser at personens navn er oppgitt og ikke inneholder ulovlige tegn
• Vis en side for å søke etter personer
• Vis alle personer dersom søkestreng ikke er angitt
• Søk etter angitt søkestreng

En funksjonell test kan se slik ut:

PersonServlet servlet = new PersonServlet();
 
HttpServletRequest req =
    org.mockito.Mockito.mock(HttpServletRequest.class);
HttpServletResponse resp =
    org.mockito.Mockito.mock(HttpServletResponse.class);
 
PersonDao personDao =
    org.mockito.Mockito.mock(PersonDao.class);
servlet.setPersonDao(personDao);
 
org.mockito.Mockito.when(req.getMethod())
    .thenReturn("POST");
org.mockito.Mockito.when(req.getPathInfo())
    .thenReturn("/create.html");
org.mockito.Mockito.when(req.getParameter("full_name"))
    .thenReturn("Johannes Brodwall");
 
StringWriter pageSource = new StringWriter();
org.mockito.Mockito.when(resp.getWriter())
    .thenReturn(new PrintWriter(pageSource));
 
servlet.service(req, resp);
 
org.mockito.Mockito.verify(personDao)
    .create(Person.byName("Johannes Brodwall"));
 
org.fest.assertions.Assertions.assertThat(pageSource.toString())
    .contains("Personen er opprettet");

Data-aksess-test

Hibernate forenkler databasebruken mye. Men Hibernate er selv komplekst og når man bruker det på mer avanserte måter fortjener det egne tester. En typisk test med Hibernate kan være:

1. Legg i tre personer i database
2. Søk etter en del av navnet på en av dem
3. Sjekk at du får tilbake akkurat den du forventet

Når jeg starter med Hibernate, lager jeg en test som dette, og følger feilmeldingene. Pass på å både følge feilmeldinger i loggen og stack tracer.

AnnotationConfiguration conf = new AnnotationConfiguration()
    .setProperty(Environment.URL, "jdbc:hsqldb:mem:persondaotest");
PersonDao dao = new HibernatePersonDao(conf.buildSessionFactory());
 
dao.create(Person.withName("foo"));
 
org.fest.assertions.Assertions.assertThat(dao.find(null))
    .containsExactly(Person.withName("foo"));

Følg feilmeldingene herfra.

Integrasjon

En veldig vanlig måte for web serveren å overlevere spesielt ting som DataSources til applikasjonen er via JNDI. I Jetty kan du gjøre dette i Web-testen på følgende måte:

org.hsqldb.jdbc.jdbcDataSource ds = new org.hsqldb.jdbc.jdbcDataSource();
ds.setDatabase("jdbc:hsqldb:mem:personwebtest");
ds.setUser("sa");
new org.mortbay.jetty.plus.naming.Resource("jdbc/primaryDs", ds);
 
// Oppstart av Jetty som vist over

Konklusjon

Å gjøre en liten øvelse som dette er en god måte å bli bevisst hvilke vaner du har og hvor lang tid det egentlig tar for deg å gjøre oppgavene dine. Du vil oppleve at det å skrive tester før koden føles som om det går saktere enn du tror du er vant til.

Men dersom du er som meg, vil du også oppleve noe annet: Når du tester ut applikasjonen første gang (du kan gjøre dette med Jetty, naturligvis) så er sjansene gode for at den vil være nokså feilfri og at debugging i stor grad er overflødig. Jeg vet ikke med deg, men debugging er en aktivitet jeg gjerne blir kvitt.

1. Ha en organisert struktur med at man gjennomfører navngitte migreringer (a la Ruby-on-Rails sine migrations eller dbdeploy). Typisk er det vanlig og velfungerende å navngi scripts med løpenummer (001, 002, …) eller timestamp (20091124071300, …) og ha en tabell i databasen som holder styr på hva som har blitt kjørt
2. Bruk views og materialiserte views for å støtte tilbakekompabilitet (NB: Oracle er veldig sterk på dette, andre databaser kan slite)
3. Om mulig, gjør hver migrering bakoverkompatibel på en versjon av programvaren. Dette er lettere å få til jo hyppigere du releaser programvaren
4. Skill endringer i skjema (for eksempel: legg på en kolonne) fra migrering av data (for eksempel: populere kolonnen). Feilene vil typisk ligge i #2 av disse, og den er lett å gjøre transaksjonell, mens skjemaendringer ikke er transaksjonelle i de fleste baser.

Har jeg dekket det viktigste da?

This Norwegian language article introduces a short two-page guide I’ve written to explain Scrum to people who’ve only just heard of it.

I samarbeid med våre dyktige redaksjonelle medarbeidere på Steria, har jeg forfattet en “3 minutters guide” til Scrum. Denne tar for seg spørsmålene som “hva er egentlig Scrum”.

Dette er Scrum

3-minutterguidene kan lastes ned fra Sterias hjemmesider.

Jeg planlegger å følge opp denne guiden med en guide som beskriver hva som skal til for å faktisk lykkes med Scrum. Har du noen ideer?

This Norwegian language post talks a little about a quick intro to Scrum that I wrote for my employer

Jeg har forfattet en “3-minutters guide” til Scrum. Dette er en to siders lettlest artikkel som publiserer via min arbeidsgiver Steria. Denne har som mål å være tilgjengelig både for tekniske og ikke-tekniske prosjektdeltagere som gjerne vil forstå litt mer om hva Scrum dreier seg om.

Du finner artikkelen på Sterias arkiv over 3-minuttersguider. Du kan ta kontakt dersom du ønsker et eller flere eksemplarer av guiden trykket på solid papir.

Jeg regner med å lage flere iterasjoner av denne guiden, så tips om forbedringer mottas med takk.

This is a Norwegian language copy of an article I published with Niklas Bjørnerstedt in the Norwegian computing magazine ComputerWorld

Studier som utgir seg for å være vitenskapelig utført viser seg stadig å ikke tåle nærmere granskning. Kommersielle tenkesmier tar mange snarveier i kampen om å få frem oppsiktsvekkende resultater. Forskeren Magne Jørgensen har gjennom årene bidratt til å “avsløre” flere tvilsomme studier og dermed bidratt til å heve den vitenskapelige standarden innenfor systemutvikling. Vi synes dette er en hederverdig innsats som vi har lært mye av. Vi synes dog at Magne har blitt overivrig i det siste. I både artikler og foredrag virker han å fremfekte et syn som stiller spørsmålstegn ved all erfaring som ikke er vitenskapelig bevist. Det siste eksemplet på dette synet sto å lese i CW den 24. mars. Når artikkelen bruker denne skepsisen til å koble smidig utvikling med ord som “mote” og “tro” så føler vi at forskeren er i ferd med å kaste ut barnet med badevannet.

Kan det noen gang bevises at smidig utvikling er effektivere enn “tradisjonell utvikling”? Problemstillingen er sannsynligvis for åpen. Det finnes mange måter man kan definere “effektiv” på, en uendelig antall måter å være smidig på og enda flere måter å utvikle på som ikke er smidige. Vitenskapelige studier må redusere en problemstilling til noe som lar seg måle. For eksempel: Gir parprogrammering færre defekter enn individuell programmering? Faren med å redusere problemstillinger på denne måten er at det som gjenstår kan bli et meningsløst spørsmål uten kontekst. Et studie har for eksempel nylig vist at en naken mann (eller kvinne) ikke mister mer varme gjennom hodet enn resten av kroppen. Men dette er ikke relevant til hvor vidt vi bør ta på oss lue om vinteren: I det virkelige livet er det få som velger å gå ut nakne på vinteren, men mange som går barhodet. I sitt foredrag på Software 2009 hevdet Magne tilsvarende at Fred Brooks berømte påstand “Adding manpower to a late software project makes it later” ikke er verdt mye da det er en overforenkling (Brooks skal selv ha innrømmet at det er en “outrageous oversimplification”). De fleste prosjektledere vil derimot si at dette er et godt eksempel på en erfaringsbasert regel. Selvfølgelig er den ikke sann i alle tilfeller, men man bør ha gode grunner for å bryte den.

Som et komplement til vitenskapelige studier er det jo vanlig å bruke erfaringsbaserte slutninger. Disse erfaringene kan være falske, vi mennesker er mestere på å lure oss selv, men det må likevel være bedre å basere seg på en erfaring enn å bare gjette. Hvis det så kommer vitenskapelige studier som tilsier at erfaringen er falsk så er det et grunnlag for å endre adferd. Det er viktig å samle erfaring på en måte som er tilnærmet vitenskapelig for å unngå noen av de fallgruvene Magne gir eksempler på i sine innlegg.

Systematisk bruk av erfaringer er også fundamentet for smidige metoder. Etter en kort iterasjon revurderer teamet resultatet og sin arbeidsform. Målet er nettopp å basere seg på erfaring og empiri framfor blind tro. Slik vil et smidig team bruke iterasjonene på å hente inn mer informasjon om teknikkene de bruker, måten de jobber på og hvor vidt arbeidet deres tilfredsstiller kundens behov.

Smidige metoder er heller ikke en moteting, slik Magne ser ut til å hevde. Smidig utvikling har en lang tradisjon. Det oppsto ikke med det smidige manifestet i 2001. Tankeretningen vokste ut fra det samme miljøet som ble kalt objektorientert på 90-tallet. Dette er et miljø med sterke bånd til akademia tilbake fra Smalltalk og Simula67 før dette. I tillegg har man lånt fra Toyota Production System sin erfaring innen prosessindustrien. En tradisjon som bygger på det W. Edwards Deming kalte Plan-Do-Check-Act – en tilpasning av den vitenskapelige metode til industrien.

Smidig utvikling er et rammeverk for å lære fra erfaring. På samme måte som man kan bruke vitenskapens verktøy bra eller dårlig, kan man bruke smidig utvikling bra eller dårlig. Det vil aldri finnes metoder som garanterer at vi lykkes. I stedet ønsker vi metoder som hjelper oss å oppdage når vi ikke gjør det.

Niklas Bjørnerstedt, Leanway
Johannes Brodwall, Steria

Publisert i Computerworld 22. mai 2009 (kun i papirutgaven)

This blogpost is a Norwegian language tribute to one of my home city’s great poets

Med takk til Joachim Nielsen

Ta en titt inn på skjermen din æ’kke testen grønn
Det var mye værre her om da’n da var alle tester røde
Skulle vært her i forrige uke, da hadde byggserver’n stopp
Alt jeg tenker på er test og kode og bygg og mat hver bidige dag

Alt kan refaktoreres, alt kan leveres
Alt kan refaktoreres, og ingen ting blir bedre

Jeg våkner i den samme gamle klassen og håper på det beste
Tomme tester og tommere metoder, her er gutten som kan refaktorere
Alle koderne som var her i går har forsvinni til no’ bedre
Hver dag er den samme som den neste, ut og refaktorere

Alt kan refaktoreres, ingen ting kan heles
Alt kan refaktoreres, og ingen ting blir bedre

Jeg sitter her og tester igjen, min oppfinnsomhet har grenser
Skulle hatt no’ design eller no’ krav, eller begge deler
Alle folka går å prater om meg her skal det konverseres
Dem begynner å bli skikkelig lei, her må det kritiseres

Ta en titt på skjermen din, æ’kke testen grønn (ikke vær så kjedelig)
Det var mye værre her om da’n da var alle tester røde (ikke reproduserbar)
Skulle vært her i forrige uke, da hadde byggserver’n stopp (kan det være mulig)
Alt jeg tenker på er test og kode og bygg og mat hver bidige dag

Alt kan refaktoreres, alt kan leveres
Alt kan refaktoreres, og ingen ting blir bedre

Jeg våkner i den samme gamle klassen og håper på det beste
Tomme tester og tommere metoder, her er gutten som kan refaktorere
Alle koderne som var her i går har forsvinni til no’ bedre
Hver dag er den samme som den neste, ut og refaktorere

Alt kan refaktoreres
Alt kan leveres
Alt kan refaktoreres
Og ingen ting blir bedre

Alt kan refaktoreres
Alt kan leveres
Alt kan kopieres
Og ingen ting blir bedre

Alt kan refaktoreres
Alt kan refaktoreres
Alt kan refaktoreres
Alt kan refaktoreres

Forslag til refaktorering av sangen mottas med takk

I diskusjonen etterpå kom vi inn på mange av aspektene og det var mange veldig gode forslag der jeg ikke fikk notert meg alt, så jeg har utelatt mange ting som kunne vært sagt.

Her er mitt førsteutkast til “vær-varsom plakaten”:

• Hold tilbake til innflytelse: Når du foreslår en løsning, kan løsningen bli valgt ukritisk. Når du tar ansvar for en løsning, umyndiggjør du de som skal utføre jobben og gjør dem i dårligere stand til å ta ansvar i fremtiden.
• Vær forsiktig med å foreslå løsninger: Løsningen du foreslår har høyere kostnader enn du forventer. Løsningen du foreslår løser problemet dårligere enn du forventer. Problemet du løser er mindre alvorlig enn du forventer.
• Byråkrati koster: Alle tid brukt i møter er tid som ikke brukes til fremdrift. All unødvendig informasjon (for eksempel standarder) som blir gitt fjerner oppmerksomheten fra en bit viktigere informasjon.

I stedet kan en arkitekt fokusere på å være en kulturkatalysator:

• Skap fora for andre: Du har en unik mulighet til å støtte læring og erfaringsutveksling mellom de som utfører jobben.
• Fremhev andre: Dersom du kjenner andres sterke sider og forbedringsønsker, har du mulighet til å bidra til andres personlige vekst.
• Vær et talerør: De som gjør oppgavene har ofte vanskelig for å få gehør for sine problemer og behov. Formidle disse problemene til ledelsen og hjelp sett fokus på daglige forbedringsmuligheter.

En god lyntale kan ha enda større påvirkning enn et godt foredrag, fordi lettere kan nå flere mennesker. Men det krever innsats. En god lyntale er:

• Fokusert: Du skal ha ett poeng, én påstand eller ett spørsmål som foredraget bygger rundt. En god lyntale er ikke kortversjonen av et timesforedrag, eller abstraksjon over erfaringer. Snakk om konkrete erfaringer. Finn det aller viktigste poenget og snakk om det.
• Forberedt: En lyntale krever forberedelser, akkurat som et annet foredrag. Men siden det er kort har du anledning til å trene på det flere ganger. Vis ditt publikum respekt. Hold talen for en vegg tre ganger før du holder den for et menneske. Det tar bare 30 minutter.
• Pirrende: Når tiden din er brukt opp skal du ikke ha sagt alt du kunne ha sagt, og ditt publikum skal ikke ha hørt alt de kunne ha hørt. Både du og publikum bør ha appetitt på mer informasjon.

Kan du skape mening på ti minutter? Klart du kan.

Kommentarer, eksempler på gode lyntaler og forslag til revidering av “manifestet” mottas med takk!

The Norwegian computing association has released guidelines for contracts regarding agile projects. Wednesday, November 26th I will be part of a panel debating this work and the combination of agile and contracts. This Norwegian language blog post contains my introductory remarks for the debate.

Kom på debatten på Oslo Lean Meetup på onsdag og delta på debatten!

Jeg er ikke en prosjektleder, en advokat eller en politikker, så jeg kan ikke si så mye om hva som må være med i en slik kontrakt. Jeg er bare en programmerer. Jeg er en programmerer som ønsker å jobbe på gode prosjekter. Jeg håper at det er mulig for meg å jobbe på gode prosjekter som også advokatene og politikerne vil være fornøyde med.

Hva er et godt prosjekt? Den enkle definisjonen er at et godt prosjekt er et prosjekt som både leverandøren og kunden, både utviklerne og brukerne er fornøyde med. For meg som programmerer er dette viktig. Og jeg tror det er viktig for mange andre programmerer. Hva er det som gjør at enkelte mennesker synes programmering er spennende? Jeg tror svaret er enkelt: Programmerer er mennesker som brenner for å skape ting som noen har bruk for.

Jeg ønsker å skape verdi, og for meg er smidige metoder en god rettesnor. Jeg tror ikke smidige metoder er et magisk ord man kan bruke for å få til vellykkede prosjekter, men jeg tror at verdiene smidige metoder beskriver forbedrer sjansene mine for å delta på gode prosjekter. Men bare dersom man forstår verdiene og ikke bare utfører tomme ritualer som man kaller “smidig”.

Jeg har jobbet noen år som programmerer. Og jeg har deltatt både på prosjekter jeg var fornøyd med og på prosjekter som jeg ikke var fornøyd med. Den triste sannheten er at de fleste prosjektene jeg har sett eller deltatt på var ikke gode prosjekter.

Derfor var det veldig spennende for meg når jeg først fikk høre om veillederen. Spørsmålet jeg håper veilederen kan svare på: Er det mulig å forbedre sjansen for at leveranseprosjekter blir gode leveranseprosjekter? Kan veilederen forbedre sjansen for at prosjektene våre blir gode prosjekter?

Jeg har lest gjennom det som har blitt skrevet med en blanding av håp og skrekk. Mitt svar er “jeg vet ikke”.

Men jeg er skeptisk. Det virker som om smidige metoder, som mye annet, er i ferd meg å bli et offer for sin egen suksess. Kan vi risikere å falle i fella at vi tror at fordi vi bruker ord som Product Owner og ScrumMaster og Sprint og Product Backlog så vil alt bli bedre av seg selv?

Det er lett å si “smidig”, men det er ikke alltid lett å gjøre smidig. Så for å forstå hva smidige metoder dreier seg om, gikk jeg tilbake til kilden.

Jeg bladde opp på http://agilemanifesto.org. De smidige verdiene er kjent for de fleste nå. De står på forsiden. Men det ser ut som om mange overser den første linken herfra. Den går til de tolv smidige prinsippene. Jeg har valgt ut tre for dere:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

“Simplicity–the art of maximizing the amount of work not done–is essential.”

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Det jeg har fått ut av smidighet, er erkjennelsen om at vi ikke kan anta perfekt informasjon. Vi er nødt til å få feedback på det vi tror og det vi gjør, og vi er nødt til å endre planene basert på denne feedbacken. Denne grunnleggende verdien ligger bak ønsket om hyppige leveranser og mye annet.

Så jeg står igjen med et siste spørsmål: Er det mulig å lage en leveransekontrakt som verdsetter denne dype verdien om feedback? Det håper jeg å få svar på i denne debatten.

This is a rough Norwegian language translation of the article JKE Day 1: Toyota Kyushu – The Manufacturing Ballet by Kevin Meyer (improvements on the language are very welcome, comments on the contents should go to Kevin). The reproduction has been authorized by the author. Unlike the rest of my site, this article is not available under creative commons license.

Jeg kom over en artikkel som demonstrerte hvor bemerkelsesverdig lean production system kan være. Den var så spennende at jeg bestemte meg for å oversette den til norsk:

Jeg trodde at jeg forsto lean ganske bra. Jeg tok feil. Jeg har fortsatt masse å lære.

På mandag besøkte jeg Toyotas Kyushu fabrikk som en del av Gemba’s Japan Kaikaku Experience. Anlegget har en kapasitet til å produsere 40 000 kjøretøy i måneden, produserte 430 000 kjøretøy i 2007 og produserer akkurat nå 1150 kjøretøy hver dag gjennom to skift. Det er over 6000 ansatte, noe som er en reduksjon de siste par månedene på grunn av den lavere globale etterspørselen etter biler, men det er 2000 mer enn for ti år siden.

Det første du legger merke til når du kjører inn til komplekset er at fabrikkpipene er skarpt gule. Hvorfor gule? Med gule piper kan de enklere se om pipene er skitne slik at de vet om de må rengjøres. Det siste du opplever når du forlater området er guiden som sier “jeg er sikker på at jeg kunne gjort en bedre jobb og jeg vil streve etter å forbedre meg” og så bukker hun gjentatte ganger til bussen vår mens vi kjører vår vei og avslutter med et siste fullt bukk når vi runder hjørnet av parkeringsplassen… en halv kilometer unna. Ønsket om å forbedre arbeidet og respekten for mennesker gjennomsyrer fabrikken.

Erfaringen er vanskelig å beskriver, men her kommer noe friflytende tanker og observasjoner.

Dette er Toyotas mest lønnsomme fabrikk dersom man regner kroner per bil. Det er ikke den beste når det gjelder produktivitet av arbeidsstokken. Dette faktumet bør kaste kaldt vann over “arbeidstimer per enhet” metrikker som ofte brukes i industrien. Dersom mindre av tiden brukes på direkte arbeid, kan det medføre forbedringer i fabrikkens produktivitet som øker lønnsomheten. De forstår at arbeid er en verdi, ikke en kostnad.

Toyota produserer kun til bestilling. Bilutsalg må forplikte seg på antall enheter med 30 dagers varsel før produksjonsmåneden, og så låse sin bestilling 5 dager før produksjonsmåneden starter. På det tidspunktet sendes kravene videre til Toyotas underleverandører som så har 3 dager på å planlegge produksjon av de delene som trengs for hvert kjøretøy. Delene leveres i inkrementer på én time til fabrikkgulvet.

Høres komplisert ut? Det er komplisert. Legg til takt-tid, eller hvor ofte et kjøretøy ruller av samlebåndet for å møte etterspørselen, som kan variere fra 90 sekunder helt ned til under 50 sekunder. Sekunder. Takt-tiden endres hele tiden for å tilpasse seg etterspørselen. Se for deg hvordan endringer i etterspørsel leder tilbake til leverandørkjedekrav og og leverandørkjedefleksibilitet.

Så… tenk på dette: De samme operasjonen brukes ikke bare til å lage kjøretøy med varierende farger eller kjøretøy med varierende opsjoner eller til og med til å lage kjøretøy med radikalt forskjellig teknologi (for eksempel bensinbiler eller hybrider). De brukes til å lage helt forskjellig kjøretøy. Det endres hele tiden, per enkelt enhet. Hundrevis av variasjoner, mange så radikalt forskjellige som kjøretøy med forskjellig chassis. Hvert minutt. En personbil, så en SUV, så en hybrid av den samme SUV-en, så en bil igjen… se for deg flyten av materialer, balansering av produksjonslinjene, standardisering av arbeid som trengs for å få en slik produksjonskjede til å summe. Det bør få de som tror at Toyota ikke tror på en produksjon av varierende modeller til å tenke seg om to ganger. Eller de som tror at raske endringer av produksjonslinjer kun er en drøm.

Og til sist… tenk på dette: Det var ikke en eneste synlig datamaskin på fabrikkgulvet. Noe sted. Et stort elektronisk skilt viser tilstanden på hver produksjonslinje, men alt annet var manuelt. Hver kasse med deler ble håndtert med manuelle kanban (men med strekkoder, slik at papirkortene ikke blir overlevert). Når en kasse er tom, blir den fylt opp igjen av arbeidere som kjører vogner opp og ned mellom produksjonslinjene. Når en kasse med deler blir tømt, erstattes den med en ny kasse. Tusenvis av deler, fra så små som skruer og muttere helt opp til motorer og dører, over flere mål med fabrikkgulv.

Toyota automatiserer kun farlig arbeid (som sveising) eller det som er for tungt for mennesker. Alt annet er gjort av arbeiderne… fordi kun mennesker kan komme med forbedringer. Og disse kontinuerlige forbedringene er en av de mest imponerende aspektene ved denne fabrikken.

I motsetning til mange andre bilprodusenter, lar Toyota fabrikkene sine forbedre seg individuelt i stedet for å påtvinge detaljerte arbeidsstandarder på tvers av fabrikker. Endringer og innovasjoner er synlige over alt, på alle arbeidsstasjoner. Arbeiderne bruker PVC rør til å skape sine egne måter å vise den eksakte plasseringen av deler for å effektivisere arbeidet. Disse Rube Goldberg-trallene følger dem mens de flytter seg sammen med bilen for å utføre forskjellige operasjoner.

Hver bevegelse er koreografert og perfeksjonert. Man er nødt til å stå og se på hver arbeider gå gjennom flere runder med sine arbeidsoppgaver for å se nøyaktig hvor koreograferte de er. Hver bevegelse har et formål og er designet for å minimere arbeidet for den nåværende og neste operasjon. I det arbeideren går ut av frontsetet etter å ha installert fire skruer, vrir han litt på venstrehånden slik at bakdøren åpnes og så glir han ut av frontsetet og inn i baksetet. I det han forlater baksetet etterlater han et verktøy som neste arbeider trenger. Det er vanskelig å beskrive, men det er i sannhet en produksjonsballett.

Hvis en arbeider har et problem, trekker han i en snor som utløser en alarm. En annen person kommer løpende. Eskalering av problemer er noe mange sliter med, og Toyotas løsning er å lage veldig enkle avgjørelser og flere avgjøringspunkter. Arbeideren starter med “er det et problem, ja/nei?” Hvis “ja” så trekker han i alarmen. En mann med hvite hansker kommer løpende og har en annen enkel avgjørelse: “er det virkelig et problem, ja/nei?” De to har bokstavlig talt under ett minutt, en takt, å komme til en avgjørelse. Dersom “ja” så stoppes produksjonslinja, og en arbeidsleder kommer løpende. Han har en ny enkel avgjørelse av “kan problemet løses innen to takter (cirka to minutter), ja/nei?” Hvis nei, så går problemet opp ett nivå til “stopp fabrikken”. På under tre minutter har et problem blitt identifisert, angrepet, nesten alltid løst, men en avgjørelse har blitt tatt som potensielt kunne stoppet hele fabrikken.

Hvor ofte hører man alarmen? Cirka hvert minutt over hele fabrikken. Det er ikke noe i veien med å rapportere et problem. Formålet er å finne det og fikse det, raskt. På under ett minutt. Hvor lang tid tar det deg å identifisere, rapportere og løse et problem? Jeg vet hva du tenker: Jeg skammer meg også.

Det er cirka syv parallelle produksjonslinjer som løper fra hode til hale, hvor hver bil produseres. De er synkroniserte men uavhengige for å gjøre det mulig å ha en buffer på tre til syv biler, noe som tillater at en linje kan være inoperativ i to takter to eller tre ganger per skift uten å stoppe fabrikken. “Buffer” er antageligvis ikke riktig ord… husk at dette utgjør kanskje fem minutter. Fabrikken har planlagt 100 % oppetid, men målet er 97 %.

Takt-tiden justeres hele tiden basert på etterspørsel. Tregere takter blir sett på som en mulighet til å forbedre arbeidet. Jeg vet at den nåværende krisen har medført nedgangstider for mange, men hva ville skjer dersom du gikk til sjefen og sa at du ønsket å redusere den tiden arbeiderne jobbet direkte med produksjon slik at de kan forbedre arbeidet? De ville antageligvis sjekke gyldigheten av MBA-graden din.

Men dette er hvorfor denne fabrikken er så lønnsom… uten at den er den beste når det gjelder å utnytte arbeidskapasiteten. Menneskeskapte forbedringer mer enn utjevner forskjellen. “Kaizen” (Toyotas begrep for “kontinuerlig forbedring”) på denne fabrikken, som på alle andre Toyota-fabrikker, innebærer alle typer forbedring. Noen kan være så små som “i stedet for at jeg strekker høyrearmen over venstrearmen for å hente en del, plasserer jeg delkassen til venstre”, men det er fortsatt en forbedring. Hver arbeider forventes å komme med en forbedring i måneden. Hver forbedring blir dokumentert på et enkelt ark. Hundre tusen forbedringer i året. Små forbedringer som utgjør en massiv endring.

Vi strever ofte med om vi skal kompensere eller belønne arbeidere for forbedringer og hvor betalingen skulle hentes fra. På Toyota, i stedet for å forsøke å beregne lønnsomheten for hver enkelforbedring, betaler hver forbedring fem til ti dollar fra fabrikkens opplæringsbudsjett. Dersom ideen medfører mindre arbeid, får arbeideren fordelen av redusert arbeidsmengde i en måned før produksjonslinjene rebalanseres.

Opplæring er naturlig nok essensielt. Nye arbeidere bruker tre måneder på å lære sin første jobb, for det meste i et opplæringssenter som ser nesten identisk ut med fabrikken. Etter at de har lært denne jobben, lærer de jobben som utføres før sin egen og så jobben som utføres etter. De bruker én måned på hver av disse.

Å balansere arbeidskraften er også viktig. Uplanlagt fravær kan være døden. Fabrikker har 5 % overkapasitet i bemanning for å tillate ferier og fravær. Ut over dette… så må sjefen erstatte en manglende arbeider. Dersom arbeideren trenger å bruke toalettet utenfor sine vanlige pauser og lunsj, så må sjefen ta hans plass. Dersom arbeideren plutselig er borte, så må sjefen ta hans plass. Denne filosofien gjelder helt til toppledelsen i fabrikken.

Det er pauserom og toaletter innen 50 meter fra hver arbeidsstasjon. Overraskende nok får de ansatte lov til å røyke i pausene sine… på produksjonsgulvet. Alle tar pause samtidig, og produksjonslinjen stoppes…. lyset over produksjonslinjen skues av for å spare energi. Ti minutter senere spilles Edelweiss, og alle går tilbake på plass.

Nedgangstidene merkes. Hundrevis av vikarer, en tradisjonell og akseptert form for arbeid i Japan, har forlatt fabrikken. Men alle fulltidsarbeidere har sin jobb på livstid, noe som har vært praksis i årtier. Lojalitet begge veier hjelper begge parter. Men husk også at Toyota er unike i at de har, og følger, 50 årsplaner. Ikke femårsplaner som resten av oss. Femti. Krisen var forventet, likviditet var satt av, strategier var utviklet til å utforme opplæring for å komme gjennom krisen.

Hvem kan si meg hvem som er toppsjef i Toyota? Det er noen få som kan. Men ikke så mange som kan navngi Welch eller Nardelli. Ledelsen på Toyota er ydmyke. Fujio Cho has sagt “led som om du ikke har noe makt”. Etter å ha sett denne fabrikken forstår du virkelig den idéen. Toyota er et prinsipp, et system, som tilfeldigvis har en leder. Det er et prinsipp som understøtter mennesker og som utnytter forbedringene som disse menneskene skaper.

Tror du at du forstår lean? Da kan det være at du bør besøke Toyota Kyushu på The Japan Kaikaku Experience.

Her er det masse å lære, dersom man fokuserer på prinsippene og ikke teknikkene. Det er stor forskjell på produksjon og (software)utvikling. Men prinsippene om at de store forbedringene kommer fra en samling små forbedringer, om at det er de som jobber på fabrikkgulvet som skaper forbedringene og at god og helhetlig opplæring lønner seg er gyldige. Og jeg tror ledere innen IT burde være de som kan ta plassen til de som de leder og som leder uten makt.