Skip to content

Poisonous projects kill your organisation silently

2. June 2014

(n) toxicity (the degree to which something is poisonous)

Management of an organisation that is quite obviously based around products but chooses to see everything as projects creates a mismatch between how an organisation is run and what they try to accomplish. The structure in use to enable the accomplishment of work defines the foundation which future work is built on.

You would not, I hope, build a sprawling villa on ground that does not carry, lest you do not seek to repeat a classic scene from Monty Python and the Holy Grail:

“When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built it all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And that’s what you’re going to get, Lad, the strongest castle in all of England.”

There are several lessons to be extracted from that quote about trying and failing, iterating, feedback loops, starting over, et cetera. Our focus is on the obvious one; do not build on unstable foundation.

A project by definition is something that should be accomplished with a fixed amount of resources within a fixed timeframe. When the goals are achieved the project is dee-oh-en-ee:  done.

Ergo projects have limited lifespans, which is something products do not. A product strives to live as long as it can. If it cannot pay for its own way in terms of further development and operational costs it is proven to not have a place in the market in its current form.

A few trends that emerge every time I work with an organisation that has structured themselves around projects can be summarised by this little tale about a man collecting sticks.

Read more…

A very quick way to A/B-test

30. April 2014

In discussions about A/B testing, everyone usually agrees that it is a good thing. To get started, however, somebody must first have the time and the resources to build the A/B test rig. It will take weeks, and will probably involve some interesting big data technology. Also, it usually never gets priority enough to actually get done.

Read more…

Don’t hate the player, hire him!

25. April 2014

When you think about a typical successful company, who is it that comes to mind? Apple? Toyota? Ford? Those are all good examples, by all means. But what about Valve, Blizzard or Id Software? Or a company called Wargaming.net? These are all, as you might have noticed, gaming companies. And in a lot of cases, gaming companies have been miles ahead of other (IT-)companies when it comes to innovation, company culture and how we relate to our customers and community. Read more…

Serial innovation starts and ends with guidelines on the wall

4. April 2014

I wonder – what would work be like, if you and your team would agree to the following four guidelines?

I thought about having a designer work on a poster but decided it was better to monitor how many actually downloads my Keynote screenshot

I thought about having a designer work on a poster, but I decided it was better to monitor how many actually downloads this slide that I made in Keynote

1. Exploration over back-logs

There, I won’t forget it now. Phuh. Writing down future work is therapy to the overworked innovator.

Read more…

This is why I work for Iterate

31. March 2014

I have recently published quite a popular blog post Frustration-Driven Development – Towards DevOps, Lean, Clojure. My good colleague Tom Bang has pointed out that it actually shows nicely the reasons why many of us work for Iterate and why Iterate does what and how it does. I therefore republish it here under a modified name.


 

A post about development practices, speed, and frustration.

My wife has mentioned that she likes my passion for doing things right in software development. That made me thinking, why do I actually care so much and do not just enjoy the coding itself? It boils down to that I am not happy until my code is in production. Seeking the satisfaction of having my code used by and helping people while trying to eliminate all unnecessary mental drain is behind all the practices that I embrace and evangelize. It’s a drug I like to take often, in small doses.

practices = f(max(delivered value), min(mental energy))

So how does this relate to DevOps, Continuous Delivery, testing, single-piece-flow, Lean Startup, Clojure? It is simple.

Read more…

Lean Startup as an invisible hand

25. February 2014

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

19. February 2014

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

Follow

Get every new post delivered to your Inbox.

Join 87 other followers