Smidig 2014: Smidig vs Lean Startup

Nei, vi skal ikke rope “dette er ikke lean startup” fra taket på Oslo Plaza i årene som kommer. De fleste av oss har måttet høre på utsagn som “this is not proper Scrum” mang en gang, uten at det hjalp verden nevneverdig videre.

Vi lover.

Dette er en liten oppsummering fra Smidig 2014 og workshopen “The idea that wins” (også kjørt på Oslo Innovation Week tidligere i høst). Vi skal forsøke å bruke læringen fra workshoppen, og Smidig-konferansen forøvrig, til å nyansere forskjellen på Lean Startup og det vi kjenner som Smidig.

Det heter ikke Lean Startup-"metoden", eller Lean Startup-"prosjektet". Fjern bindestreken og det etter.

The Idea that wins er en workshop om å få Lean Startup til å fungere i etablerte virksomheter

I år var det flere lyntaler om Lean Startup på Smidig-konferansen. Det er gøy og nyttig å høre fra andres erfaringer. En av lyntalene handlet om et kortvarig Lean Startup-prosjekt der produktet ble levert på åtte uker, men hvor produkteieren senere ble presset av samarbeidspartnere til trekke produktet tilbake. En kritisk antagelse som ble falsifisert først etter at prosjektet var ferdig?

(For ordens skyld: Åtte uker er “ingenting” i et smidig prosjekt. Det er en evighet for en Lean Startup.)

Tilbake til workshopen. “The idea that wins” handler om å få Lean Startup til å fungere i en etablert organisasjon. Her leker vi med tanken om å bygge en liten startup i moderselskapet, og få alle rundt oss til å heie på oss. Ideen kom for lenge siden på en kaffebar i San Francisco i 2011, hvor jeg fikk anledning til å ta en kaffe med Eric Ries. Det var en svært interessant samtale, hvor han blant annet påpekte at han, tross navnet, hadde skapt Lean Startup for å hjelpe etablerte virksomheter.

Der har du også hint nummer én: Det begynner med en liten, autonom enhet – en startup inni moderskipet som itererer over en visjon ved å validere forretningsideer. Smidig på sin side, dreier seg mer om å validere funksjonalitet (mens vi forutsetter at prosjektet har livets rett).

I workshopen var Evry, NAV, Compello, Dossier, SOL og Iterate representert. De to sistnevnte i kraft av å være fasilitatorer. Målet var å lære noe viktig fra “mannen i gata” om deltagernes forretningsidéer – innen dagen er omme. Det klarte begge teamene.

Det er neste hint: Uansett hvor stor og tung ideen din er bør du klare å innhente læring fra den store verden på dag én.

“Dette produktet koster 30 kroner” (a)

“Dette produktet koster 80 kroner” (b)

“Dette produktet koster 160 kroner” (c)

Gruppen “No Such Box” sin ide var å tilby brukere skylagring med distribuert kryptering, slik at ingen Storebror kan trenge seg på dataene dine uten at du vet om det.

Før den fjerde timen var passert, var de igang med pristesting av idéen. De tre gruppemedlemmene fordelte påstand a, b og c mellom seg, og testet dem på adskilte personer de fant i og utenfor Oslo Plaza. 160 kroner er for mye var den unisone tilbakemeldingen fra noen folk i farten.

Hint nummer tre: En Lean-startup er ikke det samme som et (kort) prosjekt. En Lean Startup er skikkelig langvarig om idéen er god. Men læringen kommer fort. Det er derfor vi lever så lenge.

En Lean Startup kan forøvrig være kortvarig, men allikevel en suksess, hvis vi dreper dårlige ideer raskt og sparer moderskipet for feil bruk av tid og penger.

“Vi vil at du tar bilde av din faktura og sender den til oss på mail, så legger vi den ut i en Dropbox-folder for deg.”

Det er begrenset hvor fancy et eksperiment kan være når man har seks timer til rådighet på en workshop. Allikevel kan tidlig dialog fremkalle de utroligste tilbakemeldinger. Spesielt når vi kommer i prat med personer som ikke kjenner oss. Gruppen “Handsome and the douche” sin ide var et “Dropbox for fakturaer”. Det første de lurte på var om bedrifter i målgruppen var villige til å gi slipp på de fysiske fakturaene. På en time fikk de ringt fire daglige ledere eller økonomisjefer og spurt dem om behov og villighet til å ta i bruk nye verktøy.

Eksperimentene i workshoppen på Smidig 2014 var altså dialogpreget. Slike eksperimenter er imidlertid bare begynnelsen. Å validere antagelser trenger nødvendigvis ikke, og bør helst ikke, ta mye tid, uansett hvor vi er i prosessen. Produkter som bygger på programvare har unike muligheter til å formes for læring. Dyktige fagfolk klarer å få små features i produksjon, sette opp analyseverktøy og gjøre justeringer fortløpende. Vi er da smidige, tross alt.

Den tidligere omtalte lyntalen fortalte altså om et prosjekt som fikk kritisk læring etter leveranse. De hadde begynt med en planleggingsuke for å kartlegge hypoteser. Deretter hadde de ukentlig presentert arbeidet sitt for kunde og brukere. Så ble produktet levert. Smidig og effektivt, helt klart. Men det er altså etter ferdigstillelse at eksterne krefter presser produkteieren til å trekke seg. Kunne de funnet ut av dette tidligere, og kunne eieren brukt investeringsmidlene anderledes?

Som en utenforstående kan jeg bare stille spørsmålet. For det er nettopp slike spørsmål som er kvintessensen for en Lean Startup.

Siste hint: Når en kritisk antagelse blir falsifisert, hvor lenge har du jobbet under den forutsetning at antagelsen var sann?

Ingen fasitsvar. Dropbox måtte utvikle i nesten et halvt år før de hadde første versjon av sin synkronisering på plass. Heldigvis ville folk ha Dropbox, og en demo-video på Youtube hadde tidligere gitt en viktig pekepinn på dette. Zappos solgte sko fra en lokal skobutikk på ebay på første dag. I en Lean Startup-workshop Telenor og Iterate kjørte i 2011 ble et produkt lagt ned etter bare to dagers eksperimentering.

Det kommer an på både forretningsideen og dine egne ferdigheter. Det krever kreativitet å “se” hvordan du kan eksperimentere smart. Det kan være ganske gøy å plutselig finne ut hvordan du kan “hoppe over” måneder med arbeid, og heller velge en raskere vei til mål.

Smidig er fortsatt her som en viktig del av hvordan vi jobber. Det finnes mange gode, smidige prosesser der ute, flere av dem har vi hørt om på Smidig-konferansen i en årrekke. Så husk: Selv om Lean Startup er noe nytt, trenger du ikke rename backloggen din til “hypoteser” og kalle prosessen Lean Startup. Vær stolt av smidigprosessen din, og bruk den der det passer.

Deltagerene på workshoppen var nybegynnere på Lean Startup. Det var ingen hindring. Læringen kom raskt, var verdifull og ga nye perspektiver. Vi ønsker dem lykke til videre med å finne ideen som vinner.

Da skal vi klatre opp på taket på Plaza og utbasunere det glade budskap.

Anders Haugeto (36) is software engineer, experiment designer and entrepreneur helping the customers of Iterate innovate faster. He shows intrapreneurs how lean thinking helps their mission in life – to disrupt their organization from within. Follow his tweets about entrepreneurship and experimentations here: @hauge2.

Lean Startup as an invisible hand

Torve Indahl on Please share your opinion on what prevents lean startups in enterprise

invisible-hand

Business cases are in most large corp the key follow-up tool to measure your projects success and growth. When business managers do the traditional thinking and “lock” the business case at the project starting point, they then also lock or restrain the projects ability to learn and change. Eg. working with a norwegian telecom post acquisition for my 2006 startup in 2008, we where following the telecom´s 1 year old pre-acquisition business case and followed that path for 4 years. The company does not exist today. Many factors played in, yes, but fore sure the set path was one.

Working with lean startup for large and SME on a daily basis and as an MSc in Business, I frequently us this mindset (lean Startup) as an invisible hand. We don´t explain everything, we just use it. We change the business cases at every board/steering group meetings and wait for them to start asking questions about way there are all this changes. We are proud then to look them right in the eye and tell them “Sorry, we were wrong the last time“. We then show them the evidence from our market experiments on why we where wrong and let them in on the discussions on what to do next. Now you suddenly are on the road of trustchanges is expected and the board executives starts digging into if we are doing enough experiments….”what about the MVP then” (yes, they start using your words).

The best part is when our “success formula for new stuff” then becomes demand. Life is good

5 MAGISKE LYKKEFORMLER FOR BUSINESS DEVELOPMENT

Lykkes du – så del med andre hva du har lært. Deler du, så lærer du og det tror jeg er en god formel!

Her er fem ting jeg har lært om forretningsutvikling i store organisasjoner:

#1. Finne flere personer som vil det samme:

Det er viktig å finne engasjement på mange nivåer som vil det samme. Du trenger støtte på høyeste hold, på ledernivå og 2-3 operative som motor. Dvs. at man må ha 5-6 personer som finner ut av at dette skal skje og bli enige om dette.

#2. Skille ut fra eksisterende tankesett og beskytte mot makta som rår:

Hovedargumentet for å skille ut er å beskytte funding og passe på at ressurser ikke dras i flere retninger.

Schibsted har mange gode eksempler på dette, eks. vis VG når de skulle «vinne» kampen på mobil, startet de et eget AS. I 2013 tok de det inn igjen siden mobil nå er blitt en så stor del og kan måle seg med avis delen. De skilte nylig ut VGTV og kommer til å føre det tilbake igjen når det er oppe å går.

Nokia kjører et super hemmelig prosjekt som skal rette opp skuta. Norsk sjef. De er skilt ut som et eget miljø, med egne budsjetter og med topplederstøtte gjennom at Elop og noen andre VP sitter direkte i styringsgruppen. De stiller nær sakt aldri i møter, men alle vet at de bare er en telefon unna om noen prøver seg på å stjele funding eller trekke ut ressurser.

#3. Utholdenhet og utålmodighet, på en gang!

Det er utrolig vanskelig å lykkes med nye ting!

Hva skjer om man er utholdende uten å være utålmodig? Jo, mange titalls, kansje hundre millioner kan være bruket før noen setter ned foten.

Det å finne beslutningstakere og «stake holders» som har akkurat den perfekte balansen mellom utholdende og utålmodig er sjeldent. Finner du en så hold godt fast i denne/disse!

Å finne miljøer som klarer å komme frem med «udødelige» ideer. Dvs, på tross av alle som prøver å rive ned, hindre, utsette osv. så klarer miljøet å sjonglere stake holders, produktet, marked og penger på en unik måte. Disse personen vet at om de feiler på bare en, så faller alt.

#4: 3D forståelse av terrenget du er i

20140206091024

I en 2D verden trer man inn i et terreng hvor du bare ser det som er rett fremfor deg. Du ser et produkt, en tjeneste eller en forretningsmodell, men du ser egentlig ikke så godt hva kunden egentlig prøver å få gjort, hvordan endrer dette vår posisjon i markedet, hvordan kan vi gi kunden mer verdi?

Hvorfor har droner tatt over krigsmarkene? Jo, de sparer potensielt krigerens eget liv, men det er noe mer her.

De gir beslutningstakerne en 3D forståelse av situasjonen, hva som er under oppseiling og ikke minst: Hva betyr det av endringer i planen!

Jeg mener man kan oppnå dette 3D bildet gjennom å bruke flere personer med ulik bakgrunn og erfaringer som sammen diskuterer og lager planer innen et gitt området. Disse må relativt raskt kunne settes ut «live» gjennom simulering og testing i terrenget – på ekte kunder. Gjennom dette kan du som tilegne deg denne evnen til å forstå ditt marked i 3D.

#5. Kontroll på NÅR

Kanskje det vanskeligste.

Når brenner det akkurat passe under beina på «stake holders»?
Når er markedet klart for noe nytt?
Når passer det for intraprenøren å ta egen risiko (kan jo miste jobben/posisjonen)?
Når har org nok selvtillit (det har jo vært noen fiaskoer i historien bak)?
Tror du lett kan finne 20 viktige NÅR faktorer og de skal alle stemme…..det er sjeldent, temmelig sjeldent, dessverre.

Deler du så lærer du og det tror jeg er en god formel!

Torve

Done in 18 bananas

Even though the word consult comes from Latin and French and has nothing to do with it, giving estimates feels closer to conning than advising.

Naturally we feel bad about this, we do not want to feel like con-artists. We want to feel like we are helping and in response to the embarrassing emotion of guilt, we banish the problem to another realm where we do not have to take responsibility for the inevitable estimate gone awry. It really is a pretty clever way of making ourselves feel better about the estimates that we give. You may break out your inner maniac’s laughter now. Go on, you know you want to, it is all right; for you are in the company of maniacs.

This rite of banishment is performed through the powerful, almighty word; oft used and abused, terms like rough estimates, story points, units of work, or anything that is not a direct reference to Time, are thrown around. Time becomes the elephant in the room, everyone is thinking about it, yet no one is addressing it. What context does this deep need of maintaining wiggle-room remind us of … ah, yes. The art of conning and the obsession with never giving absolute answers. Or, in the words of Bruce Lee, “Be like water, my friend”.

Surely every developer has had a discussion about what e.g. a story point actually represents. This is the bed we have made. Far too much effort has been put into creating abstractions in order to give the perception of more accurate estimates of length. That sounds like a paradox in itself; we make something abstract, Time, and make it more abstract, Points, in order to talk about it as absolute.

file3111258685095

-“Huh?”

That discussion about what the estimate means is a metaphorical train running full-tilt which if you get in front of, or find yourself in front of, you will have a Bad Time™. Eventually though, what happens is that everyone just kind of stops talking about it, externally accepting that it represents nothing.

Internally however, the conflict rages on. Every time the question, “How long will this take?”, is raised, an attempt to estimate length through conversion of abstract terms into some-what more concrete terms is made. This can lead to near Olympic-level mental acrobatics, which while impressive, is completely useless when pressured for an explanation on how the estimate was arrived at.

Especially a few weeks down the line, when the explanation of the acrobatics makes no sense at all because one or more factors changed between then and now. Much like dodging a bullet you have made an assumption about being fired in the future but never was.

Maybe we should strive to be plasma instead, existing in a state neither fluid nor solid. Flexible estimates? Fixed estimates? Pshaw. Plasma estimates!

Though if history has taught us anything, it is that just changing the terminology will not work in the long haul and this fanatical devotion to avoiding Time as a unit for measuring duration is actually more harmful than helpful. The nature of an estimate is that of a guess, so instead of making us better at guessing, which we have been trying for a while now, perhaps we should not make important plans based on guesses at all.

Consider this. Someone asks you how long it will take to drive to Paris from Oslo by car. You think about it for a while. You study a map. You create a mental model of the problem and apply your own unique problem-solving framework on the model and prepare your solution.

You are now ready to present them with your estimate on the trip’s duration, and so, you look them in the eye and say,

-“18 bananas.”.

/v.

Idle your product owner

As a first step towards dealing with an over-loaded development team, we showed an organization how to visualize their work by representing work items with Post-its on the wall, flowing from to-do, to in progress, testing and doneThe organization quickly catched the idea, and soon priorities were respected, deliveries became more predictable, and developers had a process to improve.

Which is what they did, and after some time we saw a new work pattern emerge:

  1. A product owner identifies a need and wants a designer to work on the details
  2. The designer grabs the task and sketches out a solution
  3. Developer tasks can now be defined, and they go into a special planning column, which gradually started to increase in size

Things are finally happening

Although tasks are completed at this point, the need is still not solved. Nevertheless, the message becomes: “Hold on tight everyone, things are finally happening now,” and while waiting for it, the product owner may start working on even more needs, which creates even more work for the designers, and subsequently even more tasks for the developers.

Which is what they did.

Continue reading

Agile Nearshoring with Yogurt!

At a recent beerstorming (*), we discussed how to make nearshoring of software development work. Funny enough, the smooth taste of Yogurt entered the picture.

(*) Beerstorm is a fun-name invention for a practice came out of experimentations; it has very good effects on my spirit, it literally drags me into the zone… 

A primer on Yogurt cultures!

Yogurt brewing, when done the natural way, is a fascinating process. A perfect example of nurturing a self-reproducing organism. The bacteria used to make yogurt is known as “yogurt cultures”. Fermentation of lactose by these bacteria produces lactic acid, which acts on milk protein to give yogurt the characteristic texture we love.

Continue reading

Know your feedback loop – why and how to optimize it

If you always write perfect code, know how to predict the future and don’t care how your money is spent, you don’t need to read this. The rest of you need to know this stuff.

What is a feedback loop?

A feedback loop is the path your assumptions travel before they are validated or invalidated. Naturally you will have different feedback loops for different assumptions. In this post we will discuss three levels of feedback loops that should be easily recognizable. They are:
Continue reading