Slik lykkes du med smidig utvikling

Har du startet å bruke smidige metoder, men lurer på hvordan du skal få det til å fungere bedre? I denne artikkelen kan du få konkrete tips om hvordan å forbedre kommunikasjonen, kvaliteten og forretningsfokus på ditt smidige eller ikke-smidige utviklingsprosjekt.

Bedre kommunikasjon

  • Inkluder produkteier på morgenmøtene: Daglig kommunikasjon mellom kunde og leverandør har en dokumentert enorm effekt på hvor vellykket et prosjekt blir. Teamets fokus blir mye bedre dersom det er noen på de daglige standup møtene som er interessert i å prøve ut det som har blitt laget i går, som er interessert i å komme med innspill på det som lages i dag og som har myndighet til svare på avklaringer angående dagens oppgaver.
  • Programmér sammen: Utviklere på prosjekter innehar enorm kunnskap, både om de delene av systemet man lager og om programmering generelt. Når man programmerer i par og roterer hvem som jobber sammen hyppig, blir denne kunnskapen spredt til alle. Spe også gjerne på med seanser der hele teamet går gjennom deler av koden på storskjerm.
  • Bruk en Scrum-tavle: For å hjelpe alle å huske på hva som er målet med sprinten, er det lurt om teamet holder standup møtene rundt en tavle med lapper for alle aktiviteter teamet har planlagt i iterasjonen. Lappene henger i kolonner «venter», «under arbeid» og «ferdig». Hver lapp bør ha et så lite omfang at teamet flytter flere lapper til «ferdig» hver dag.

Bedre kvalitet

  • Verifiser krav med funksjonelle tester: Når teamet skal jobbe med en oppgave i en iterasjon, er det viktig at alle har konkret forståelse av oppgaven. Produkteier bør beskrive eksempler for å gjøre oppgavene konkrete. Om mulig, bør produkteier uttrykke eksemplene i et verktøy for automatisert funksjonell testing (for eksempel FitNesse eller Cucumber). Teamet kan da kjøre testene og automatisk sjekke at de oppfyller produkteiers forventning
  • Skriv enhetstester før koden den tester: For å kunne utvikle funksjonalitet inkrementelt, må man kunne endre på kode som allerede har vært ferdigstilt, samtidig som man er (rimelig) sikker på at endringen ikke ødelegger noe som har virket før. De funksjonelle testene kan gi et sikkerhetsnett, men det tar typisk lang tid å kjøre dem og de gir ofte ikke en eksakt indikasjon av hva som er feil når noe ikke virker. Derfor bør teamet skrive raske tester som verifiser at klassene i systemet fungerer, gjerne før man skriver koden.
  • Integrer endringer kontinuerlig og automatisk: Automatiske tester er kun verdifulle dersom de kjøres! Sett derfor opp en Continuous Integration server som sjekker ut og tester alle endringer hver gang en utvikler har sjekket inn en endring til kildekodekontroll. Om mulig bør dette systemet også automatisk installere den siste versjonen av programvaren til et egnet testmiljø, slik at produkteier alltid kan se hva som er siste versjon av systemet.

Bedre forretningsfokus

  • Inkluder alle oppgaver i en prioritert produktkø: Mange team lurer på hvilke oppgaver som skal puttes på produktkøen. Dersom noe gir forretningsverdi og tar betydelig tid å utføre, bør produkteier inkludere oppgaven på produktkøen. Ikke-funksjonelle krav må som regel testes. Det tar tid å sette opp testene og rette opp eventuelle mangler. Ikke-funksjonelle krav skal på produktkøen. Brukerdokumentasjon må skrives og kvalitetsikres. Det tar tid å skrive god brukerdokumentasjon. Brukerdokumentasjon skal på produktkøen.
  • Bli helt ferdig med funksjonalitet: Teamet får kun «poeng» for helt dønn ferdig utført arbeid. Etter en iterasjon bør alt som tilhører en oppgave være så ferdig at det er greit dersom man aldri mer bruker tid på koden. Koden, tester og dokumentasjon må være i en akseptabel tilstand. Det betyr ikke at koden er frosset. Dersom man for eksempel utfører en oppgave for å verifisere responstid, må teamet oppdatere eksisterende kode slik at den støtter tidsmålinger og at man korrigerer eventuelle ytelsesproblemer man oppdager. Dette arbeidet tilhører det å implementere responstidskravet – den originale funksjonen er ferdig.
  • Ta med brukere på demo: Dersom du lager et system som interesserer dine (fremtidige) brukere, bør teamet ha noe spennende å vise dem på demo etter hver iterasjon. Bruk demo-møtet til å involvere brukerne. Sørg for at input fra brukerne blir tatt hensyn til, og at de får beskjed om innspill som har blitt implementert, slik at de fortsetter å interessere seg.

Gjort riktig kan et smidig prosjekt levere ferdig funksjonalitet for hver iterasjon. Men det krever fortløpende kommunikasjon, kvalitet og fokus på forretningsverdi. Dét er hvordan du lykkes med smidige prosjekter.

Jeg planlegger å publisere en Steria 3-minuttersguide basert på denne artikkelen. Innspill til forbedringer mottas med stor takk!

Principal Software Engineer i Sopra Steria Norge. Har jobbet i 15 år med utviklingsprosjekter, hovedsaklig i Java. Arrangør og initiativtaker i fagmiljøet rundt Smidige utviklingsmetoder i Oslo.

13 thoughts on “Slik lykkes du med smidig utvikling

  1. Kjempebra, Johannes!

    Jeg har et par spørsmål og noen kommentarer –

    Når du sier Cucumber… Hva slags erfaringer har du der for automatisk GUI-testing? I prosjektet jeg sitter har vi hatt litt så som så erfaringer med Cucumber for dette – vi sleit vel mer for at ” agurkene kunne holdes grønne” enn det som ble riktig i forhold til hvilken avkastning testene gav. Vi har landet på at det har vel så bra eller bedre effekt at «mange nok – og de riktige – forretningsressurser» er med og avklarer og tester hyppig på det som slippes ut. Da har vi sjanse til å få de raske tilbakemeldingene på både misforståelser, mangler og feil som vi trenger.

    Når det gjelder produkteiers deltagelse på standupene – problemet vi ser, er ofte mangel på tilgjengelighet på produkteier eller produkteiers representant. Vi har funksjonelt ansvarlige på utviklingsteamene som skal være bindeledd mellom Forretningen/Produkteier og teamene. Det som da er sentralt er at i det minste funksjonelt ansvarlig er på standupen. Min opplevelse som funksjonelt ansvarlig er at det er utrolig hva som kan fanges opp av misforståelser på standupene 😉

    Det kan være vanskelig (tid/tilgjengelighet) å få demonstrert/prøvd ut daglig det som ble ”laget i går”.
    Så – at man sørger for tilstrekkelig tidlige ”Minidemos” med Forretning/Produkteier er et alternativ. Og da er det viktig ikke å vente til oppgaven er ”100% ferdig”. Ta en 30%, en 50% og en 80% gjennomgang av de biter som til sammen gir en fornuftig funksjonell enhet.

    Hvor ofte/hvor mye/hvem/når etc. kommer jo også an på hva slags prosjekt man er i – størrelsen, kompleksiteten på det som skal lages, antall utviklingsteam, hvor mange steder Produkteier må være tilstede samtidig…, rett og slett 🙂

    Jeg gleder meg til 3-minuttersen!

  2. Hei, Gudny

    Tusen takk for kommentaren!

    Min erfaring med Cucumber er kun på samme prosjekt som deg. Den perioden jeg var med, virket det ikke spesielt problematisk på meg, men vi innså jo senere at testtiden økte og økte. Dette var dog ikke et problem med Cucumber, men med Flex. Brukt på en dårlig måte med utestbar teknologi kan både Cucumber og FitNesse bli en klamp om foten. Men prinsippet om å formulere krav som tester er bra selv dersom man ikke kan automatisere disse testene.

    Et problem flere prosjekter har er at når man blir større, lager man et produkteierbyråkrati. Det er klart at produkteierrollen blir mer komplisert i et større miljø og at dette må håndteres. Trenden i dag ser å gå mot en idé om en superprodukteier og maktesløse ambassadører hos utviklingteamet. Jeg tror man hadde vært mye bedre tjent med å gi myndighet til å ta valg til noen som hadde tid til å møte med utviklingsteamet regelmessig og med brukerne flere ganger per iterasjon.

    Problemet er universelt og løsningen er universell: Hva gjør man når den som har myndigheten har for mange som rapporterer til seg til at han eller hun kan forholde seg til dem direkte?

  3. Hei Johannes!
    Mye visdom her, og jeg er sikker på at rådene du kommer med her kan brukes av mange. Men ikke av alle! Husk at Scrum/Agile brukes av veldig mange ulike organisasjoner. Noen utvikler egne systemer andre på oppdrag. Noen lager web-applikasjoner, andre embedded. Osv..

    Jeg synes du i det minste må nevne retrospectivene i artikkelen din. Jeg har sett mange organisasjoner fra innsiden og det er de som evner å lære av egne erfaringer som ender med rubust og god praksis. Det er selvsagt fint å lære av andre – som for eksempel deg. Men det er minst like viktig å lære av egne erfairnger!

    Vet ikke om det er riktig å inkludere retrospective som et tiende tip, men det ville vært fint om du nevnte at disse tipsene ikke nødvendingvis passer for alle og at det til syvende og sist bør være retrospectivene som avgjør.
    Mener nå jeg:)

    -geir

  4. Hei Johannes,

    Jeg sier meg bare kort enig i Geir Amsjøs innspill. For å klare å kommunisere tydelige råd ender man ofte å komme med konkrete anbefalinger på teknikker og verktøy man skal bruke for å løse sine utfordringer. Selv opplevde vi, etter mye frem og tilbake, at det var retrospektivene som hjalp oss videre. Dette debatterte vi så utførlig i et blogginnlegg med den noe tabloide tittelen «No Scrum. No more»

    Som Geir også påpeker, er vår situasjon relativ spesiell. Ettersom vi er et produktutviklingsfirma, har vi ingen eksterne premissleverandører å forholde oss til. Vi kan fokusere direkte på kundens behov, og gjøre egne vurderinger. For oss ble f.eks daglige standups helt meningsløst.

    Alle har sine variasjoner. Tar man seg god tid til å diskutere hva som fungerer og hva som ikke fungerer, får man en finslipt prosess som vokser frem innenfra organisasjonen, slik den i alle tilfeller bør.

  5. Takk til Geir og Geir for kommentarer om retrospektivet. Jeg er enig i at dette er viktig og ofte ikke brukt nok. Jeg har forsøkt å velge ut de 3 ganger 3 viktigste elementene folk ofte ikke gjør i Scrum, så jeg har tre vurderiger:

    1. Det jeg har å si om retrospektiver er ikke så mye mer enn «standard scrum». Siden denne blogposten er for viderekommende, kan jeg utlate det.

    2. Jeg kan finne ett av de 9 elementene som fortjener mindre oppmerksomhet enn Retrospektiver. Jeg liker 3×3-formen fordi den tvinger med til å tenke på slike ting. Hva synes dere? Hvem skal ut?

    3. Jeg kan bryte mot 3×3 og gå over til 3×3+1. Det kan passe fint, for da sier jeg «bedre kommunikasjon, bedre kvalitet, bedre forretningsforståelse og bedre bedre», hvor «bedre bedre» kun inneholder retrospektive.

    Hva synes dere?

  6. OK, jeg synes på en måte retrospectivene er på et litt annet plan enn de andre tingene. Dette er grunnmuren som må være på plass. Egne systematiske erfaringer er på en måte hevet over alle gode råd og modeller. Så jeg synes du kan beholde det fine 3×3 formatet, men bare gjøre oppmerksom på at disse erfaringene ikke er almenngyldige og med fordel kan utfordres av gode retrospectivmøter. Kanskje du kan si noe om konteksten du har erfart dette i?

  7. Takk for tilbakemeldingen, hyggelig å kunne diskutere litt.

    Selv om retrospektivene hjalp oss videre, synes jeg ikke de fungerer så godt i Scrum. Man gir full gass for å nå sprintmålene, også tar man alle vurderinger etter dette. Dette er batching, om ikke i fossefallskala, så batching likevel. Man gjør feil ting bedre.

    For meg er det viktigste at man går helt bort i fra fokus på ressursoptimaliseringer på denne måten. Man må bygge inn slack i prosessen til å ha et retrospektivt mindset, ikke en påkrevd retrospekt «sit-down» hver andre uke. Det bør skje spontant og daglig. Min erfaring er at det gjør det om det bare er tid til det.

    Og tid er det nok av, sålenge man ikke blir presset av produksjonsmål, budsjettmål, kort «motiverende» deadlines eller andre tilfeldig satte målsetninger. Du får det du måler, men ikke alt det andre som betyr noe.

    Man bør fokusere på flyten, på å ha tid til å diskutere og jobbe med å fjerne hindre for god arbeidsflyt — hver dag. Ikke hver andre uke (eller hvor lang en sprint er hos deg). Dette er sunn fornuft, men sunn fornuft presses som regel ut av en organisasjon av overnevnte årsaker. Dette er lasten vi sitter igjen med fra industrialderen og «scientific management» a-la Sir Frederick Winslow Taylor. Les aldri hans bøker.

    Vi har en tendens til å gjøre alt til prosjekter og verktøy her i vestlige land. Det har vi også gjort med Smidig. Jeg ble lettere sjokkert over verktøysfokuset ved XP2010. Jeg har ikke noe i mot teknikkene (god kommunikasjon, retrospektive, hyppige versjonsoppgraderinger, osv, osv), men jeg har et stort problem til at alt skal ha definerte intervaller, tidspunkt og regler.

    Det koker ned til teknikker som mennesker selv naturlig vil tilegne seg med minimalt med coaching, bare der er tid til det og man ikke påtvinges produksjonsmål, backlog-mål, eller annet som tåkelegger vurderingsevnen over hva som er det som egentlig er viktig å jobbe med nå.

    Hva som er viktig defineres ut fra strategi, og ut fra dialog med stakeholders om hvilke utfordringer man står overfor. Hvordan dette oversettes i krystallklare krav er det bare å spørre Tom Gilb om (@imtomgilb). Han er et lysår foran oss andre.

    Min oppskrift for en god utviklingsorganisasjon er enkel.
    * Organisere seg tverrfaglig etter utfordringer og målsetninger heller enn i funksjonsspesialiteter.
    * Sett kompetansen nær problemene (f.eks utviklere i direkte dialog med kunden).
    * Fokus på å utvikle ferdigheter, kunnskap og innsikt. Dropp budsjettering, planer og andre antakelser om fremtiden — utvikle ferdighetene til å takle fremtiden som viser seg å komme.
    * Kast den skrevne backloggen. Bruk prototyper og dermed en levende dialog med stakeholders som «backlog». (Skreven backlog mister verdi og over tid, en prototype i produksjon øker gjerne i verdi, og stimulerer feedback)
    * Fokuser på flyt og retning. Ikke sett mer eller mindre tilfeldige produksjonsmålsetninger. Vi produserer ikke noe, vi utvikler.

    Dette blir selvsagt veldig kort og svært forenklet for noe som er såpass altomgripende, i et lite kommentarfelt.

    Du ba om innspill til noe som må ut fra din liste. Jeg foreslår å endre eller fjerne punkt 2.2. Vi har brukt mye TDD, og vi har funnet ut at TDD _uten_ T ofte er tilstrekkelig. Igjen er jeg ikke fan av regelbundet utvikling, man må bruke erfaring og skjønn. Ved å lære seg TDD, tilegner man seg en kodestil som er bra. Man skriver renere grensesnitt som er lettere å teste. Selv når en da slutter å skrive tester først, skriver man fortsatt gode grensesnitt. Ettersom hovedmålet med testing er å ha modifiserbar kode, har man nådd målet med rene grensesnitt. Kode med gode grensesnitt er lett å endre på. Vi har en regel om testing : vi har ingen code-coverage-mål. Test kode som er kompleks og som kan skape vanskeligheter når vi skal endre koden senere. Skriv kode som er lett å teste.

  8. Hei, Geir (B)

    Spennende tanker om utviklingsorganisasjonen. Jeg tror oppskriften din er god, men kan være mer enn de fleste er forberedt på å svelge med det første.

    Selv startet jeg med å ville ha en bedre hverdag for meg som utvikler og startet med smidige teknikker som kun berører meg (TDD og CI). Så innså jeg at dette var suboptimalisering dersom jeg ikke involverte teamet mitt (stand-ups, retrospektiv, parprogrammering). Så innså jeg at dette var dømt til å motarbeides med mindre jeg involverte hele prosjektet (produktkø).

    Nå har jeg holdt på lenge nok til å skjønne at jeg må påvirke organisasjonen (produkteiers myndighet, teamsammensetning). Men jeg er fortsatt ung nok til å ha begrenset mulighet til å endre styringsparametrene til organisasjonen og naiv nok til å tro at det lar seg gjøre å gjennomføre gode prosjekter allikevel.

    (Men jeg setter veldig pris på krefter i organisasjonen som drar i den retningen du beskriver)

    Er denne inndelingen i nivåer en illusjon? Må vi «angripe» organisasjonens styringsmekanismer for å kunne ha en positiv effekt. Eller er det nok å hente på å forbedringer på individ-, team- og prosjektnivå?

    Jeg kan se at TDD kanskje er den mest aktuelle å fjerne, selv om det er med et tungt hjerte. Men som Geir A var inne på: Å kjøre retrospektiver er basisteknikk. Og å endre organisasjonen er på et annet nivå enn jeg diskuterer her.

    Jeg lener litt i retning det @leftieFriele skriver på Twitter om selvorganiserende team. Standup-møter, programmering sammen og mer er midler for å få dette til, men kanskje selvorganiserende team fortjener en egen plass på lista?

  9. Hei Johannes,

    Dette har du reflektert svært bra rundt, Og som du riktig påpeker, har jeg tatt diskusjonen for langt i retning organisasjonen, i forhold til ditt innleggs kontekst. Jeg må nesten beklage at jeg rir mine egne kjepphester.

    Jeg beundrer at du beholder optimismen for hva du faktisk kan gjøre noe med, spesielt gitt din innsikt i realitetene. Jeg er selvsagt svært opptatt av organisasjon ettersom jeg er både utvikler i, og leder av vår lille organisasjon. Jeg er svært opptatt av å lytte til behovene for de som faktisk utfører jobben, som jo er det viktigste vi gjør — altså til slike reflekterte sjeler som deg selv.

    Sett i lys av hvilken kontekst innlegget ditt er ment i er teknikkene du nevner gode, og sammen med retrospect skal dette nok spre seg som gode vaner utover i organisasjonen og påvirke godt.

    Det mest effektive du kan gjøre, er forøvrig å starte en dialog med din ledelse, og toppledelsen (f.eks Kjell Rusti, og de som rapporterer til han – http://steria.no/2009/01/ledelsen). Med bakgrunn i dine innspill har han og ledelsen bedre informasjon til å gjøre de riktige valgene for helheten i organisasjonen. Vær åpen med hva som begrenser dere i å utfolde dere. Hva stopper dere i å gjøre det dere vet er riktig for kunden, og når. De vil lytte, men man skal selvagt ikke forvente endring over natten. Hold denne dialogen levende i årene som kommer, så vil du se resultatene av det.

    I en sunn organisasjon ønsker alle å gjøre det beste for organisasjonen, vi må bare passe på at alle kan ta beslutninger med god informasjon tilgjengelig. Som utviklere må dere aktivt sørge for at ledelsen til enhver tid har god informasjon om deres refleksjoner i utviklingsdelen av organisasjonen. Gi feedback!

    Start, og hold ved like, en tverrfaglig dialog.
    Spre informasjon for god beslutningstakning, på alle nivå.

    Det er viktig å påvirke organisasjonen, den igjen påvirker alle. En liten endring til det bedre kan dermed ha enorm effekt. Alle burde kunne påvirke organisasjonen, og alle burde benytte seg av muligheten.

    Forøvrig (og litt sent) vil jeg kommentere at jeg synes innlegget ditt er bra. Jeg vil påpeke at jeg ikke er så glad i produktkøer, men de fungerer sålenge man holder det på høyt nivå (målsetninger) inntil man skal påbegynne arbeidet på de. En produktkø må aldri inneholde detaljerte spesifikasjoner eller «tasks», som blir so antakelser om fremtiden å regne.

    En annen ting er det du sier om brukerdokumentasjon i produktkøen. Brukerdokumentasjon er siste utvei, mener jeg. Se heller om du kan forenkle funksjonene så behovet for brukerfunksjonalitet bortfaller. Klarer man ikke det, får man skrive brukerdokumentasjon.

  10. Takk for hyggelig tilbakemelding og god kommentar, Geir.

    En av tingene jeg liker med Steria er at jeg har hatt akkurat et slik møte som du beskriver. Steria er flinke til å finne de som har interesse og meninger og sette dem i kontakt med ledelsen. Det negative er at som for alle konsulentbedrifter, så har kundens organisasjon mer påvirkning på muligheten til å gjøre en god jobb enn leverandørens organisasjon. Men kundene våre er for det meste flinke. 🙂

    Jeg regner med at du som erstatning for produktkø tenker på en mer kanban og/eller EVO-aktig innfallsvinkel. Jeg er enig i at dette høres besnærende ut, men det er få organisasjoner som er modne for noe sånt.

    Akkurat nå ligger ambisjonsnivået mitt på å notere meg de tilfellene der produktkø som teknikk kommer i veien for prosjektets mål.

    Jeg er også enig i at brukerdokumentasjon er et signal på utilstrekkelig brukskvalitet. Men her må prosjektet bevise brukergrensesnittet er bra nok, og her er produktkøen fin: Dersom vi viser produktet til brukerne med jevne mellomrom og vi har gjort en god jobb, kan vi forvente at kunden nedprioriterer brukermanual på produktkøen helt til det blir klart at den kan utgå. Dersom dette ikke skjer, har kunden forsikringen på at jada, vi skriver en brukerdokumentasjon dersom du vil ha det.

    Hadde jeg i stedet kranglet på at «la oss vente med å inkludere brukerdokumentasjon til vi ikke har noen annen utvei», ville jeg bare skapt unødvendig konflikt om noe hvor vi egentlig er enig.

    Så jeg er enig i at dersom man leverer et system som ikke krever brukerdoc, så har man gjort en god jobb. Men dersom man først skal skrive brukerdoc, bør denne oppgaven plasseres på produktkøen.

  11. Godt observert om at kundens organisasjon har mye å si for deres leveranse. Tenker man helhetlig på sin leveranse, og ikke bare «vi skal levere en software som gjør noe» så vil man da adressere dette problemet hos kunden, fordi man får igjen mer per time innsats ved å påvirke kundens organisasjon i positiv retning, enn man får for å skrive kode. Jeg mener man som leverandør har dette ansvaret.

    Det er også derfor vi på sett og vis bort fra å være ren produktleverandør, til å være løsningsleverandør der vi ser an hvordan leveransen bør sammensettes for å ha mest effekt per kunde. Kode er selvsagt stadig vårt sterkeste våpen, men vi sper altså på med rådgivning, coaching og andre former for verditilførsel, der vi har noe å bidra med og der kunden er mottagelig for det.

    Moro å høre at man i ledelsen i Steria dyrker en feedbackkultur fra de som faktisk kjenner de daglige operasjonene. Det forteller meg at Steria vil utvikle seg positivt fremover, sett fra en kundes perspektiv. I andre rekke slår jo dette selvsagt positivt ut på bunnlinjen. Men det er i denne rekkefølgen man må tenke på dette — først kundens suksess og profitt, deretter sin egen. Det gir bærekraftig utvikling og motivasjon i all organisasjonens ledd. Det er gøy å skape verdi.

  12. Johannes,

    Jeg skriver litt fra tid til annen, og avrunder vår dialog for denne gang med et klipp fra det siste innlegget jeg skrev:

    /———

    What are the Real Solutions?

    We need to acknowledge that the way work is organized is broken and start addressing it from the core. What makes this challenging, is that the entire organization needs to be in on this, not just the lean tools team or the new empowered Scrum team. These teams are usually not empowered to change the system. Start by getting that power. Talk to your management. Talk to your CEO. Be patient. Discuss. Elaborate. Start small, but do it every day.

    You need to design your organization towards challenges (think in terms of what you are solving for your customers, and design against that), rather than just defaulting to functional departments with their meaningless budgets and policies.

    This means organizing in cross-functional teams empowered to change the way work is done, with management as a support function embedded into the work. Everyone’s goal becomes to establish good flow in how we solve real problems for real customers in the most effective way possible.

    This is when magic starts to happen, and the fun kicks in. Solving a real problem for a real customer, and actually being there to witness it, is motivating and stimulating. Communicating directly and related to real challenges, not just via plans, sprint-/project backlogs, meetings, reports, Gantt charts and budgets.

    Freed from this burden we can spend time improving the way we work, just a little, but every single day. It’s really quite simple. It’s fun. It’s motivating. And not the least, it is very, very profitable. And it is sustainable. It scales.

    No more factories with human cogs, no more economies of scale. We all want to be a linchpin.
    We need economies of flow.

    ———/

    Og nå har du havnet på min RSS-leseliste, så jeg skal nok overrumple deg ved neste anledning, også.

Legg inn en kommentar