Mot fremtiden med jerndisiplin og fysisk avstraffelse?

Jeg husker den første prisutdelingen med Great Place to Work som vi var med på. Vi var et ungt selskap som akkurat hadde begynt med medarbeiderundersøkelser. Tre av oss dro på banketten, men var helt fri for forventninger.

Det viste seg at vi fikk en flott tredjeplass, og vi måtte selvfølgelig opp på scenen for å ta i mot. “Hvorfor er egentlig Iterate et så bra sted å jobbe”, lød spørsmålet fra konferansieren.

“Øh… vet ikke?” Jeg hadde ikke tenkt på noe godt svar.

gptw-2012

Fra førsteplassen i 2012. Stolte, ja!

I går var vi på prisutdeling og mottok en hyggelig oppmerksomhet for andreplass i kåringen. Igjen kom spørsmålet: “Hvorfor har Iterate vært blandt de beste i 6 år på rad?”

“Jerndisiplin og fysisk avstraffelse”, svarte jeg. For å være morsom, selvfølgelig, men også fordi spørsmålet er vanskelig og svaret er komplisert. Egentlig kan det deles opp i to deler – “hvorfor” og “hvordan”.

På spørsmålet om “hvorfor” hadde egentlig gårsdagens konferansier, Jannik Krohn Falck, deler av svaret i sin egen introduksjon. Han mente at vi er med på å skape en bedre verden gjennom å skape bedre arbeidsplasser.

Jeg vil snu på det. Å skape bedre arbeidsplasser er en nødvendighet for å bevare det vi har bygget i Norge når den store omstillingen kommer. Gode arbeidsplasser handler om å skape en virkelighet hvor alle får sluppet løs sin skaperkraft og innebygde lyst til å bidra. Slik vil vi lykkes med den nyskapningen det er behov for når vi ikke lenger kan leve på inntektene fra Nordsjøen.

Hvordan har vi gjort dette i Iterate?

Jeg tror det aller viktigste er vår felles identitet. Iterate består av en gjeng engasjerte nerder. Vi snakker om ny teknologi og nyskapende forretningsmodeller med samme intensitet som vi diskuterer hva som er god kaffe (nei, det er ikke Nespresso).

Dette krever faglig ydmykhet og nysgjerrighet. Konsulentene i Iterate har spisskompetanse på mange ulikeområder, fra programmering og design til forretningsutvikling og ledelse. Allikevel har det aldri vært greit å være stolt av det man ikke selv kan. Jeg tror ikke et sekund at jeg selv kan gjøre jobben våre konsulenter gjør ute hos kundene, men jeg bruker mye tid på å lære og forstå hva de gjør.

Et annet aspekt er at vi har bygget selskapet sammen og for oss selv. Ikke for kundene. Det er det kanskje ikke lov å si, men jeg tror at et selskap hvor de ansatte trives og utvikler seg til syvende og sist også er den beste leverandøren for våre kunder. Det fører også til at alle føler ansvar og tar tak i ting de mener må forbedres. I Iterate elsker vi initiativ.

Det siste poenget, og kanskje det viktige er at vi har mange møteplasser. Dette er kanskje anderledes i bedrifter hvor alle møtes hver dag, men i Iterate er konsulentene ute hos kunder og i ulike prosjekter i hverdagen. Derfor møtes vi ofte. Hver uke har vi frokostmøte med faglig og sosialt innhold. Hver måned skjer det mye, alt fra konferanser til ølbrygging på kontoret. Hvert år arrangerer store fester og hyggelige turer. Så vi endelig kan lande diskusjonen om hvilken kaffe som er best.

Vår oppskrift på en god arbeidsplass kommer ikke til å være lik din, men den har sannsynligvis ingen elementer av jerndisiplin og fysisk avstraffelse. En god arbeidsplass i 2015 er en arbeidsplass som gir ansatte frihet, mestring og mening. Jo flere slike vi har, jo høyere er sjansen for at Norge kan fortsette å være et “Great Place to Live”.

There will be failures – On systems that live through difficulties instead of turning them into a catastrophy

Our systems always depend on other systems and services and thus may and will be subject to failures – network glitches, dropped connections, load spikes, deadlocks, slow or crashed subsystems. We will explore how to create robust systems that can sustain blows from its users, interconnecting networks, and supposedly allied systems yet carry on as well as possible, recovering quickly – instead of aggreviating these difficulties and turning them into an extended outage and potentially substiantial financial loss. In systems not designed for robustness, even a minor and transient failure tends to cause a chain reaction of failures, spreading destruction far and wide. Here you will learn how to avoid that with a few crucial yet simple stability patterns and the main antipatterns to be aware of. Based primarily on the book Release It! and Hystrix. (Presented at Iterate winter conference 2015.)

Continue reading

The race for new revenue – across the chasm

From time to time I stumble across customers that ask me: – Can’t we just build a “Google search”? Or: – We need to develop new products with great user experience faster!

Increasingly over the last decade the world has experienced new products and business models popping up all over the place. They challenge the established players – and often win in the contest of customer engagement.

In the meantime our clients (large organizations) come to us and ask us to help them improve – and speed up – their product development process (they rarely ask us to help increase customer engagement or earn more money). They often refer to the Lean Startup process.

It seems to me that someone has mistakingly interpreted the fact that new successful products are popping up faster than ever due to approaches like Customer Development and Lean Startup. The main reason is actually due to cheap distribution and available technology that enables almost anyone to compete with anyone – on a global scale. Building a product is easy. Anyone can do that in 2015.

Customers sometimes expect us to do this: – Can you teach us Lean Startup – to reduce time to market for a new product – and reach sustainable new revenue faster? This is however where we easily get things wrong. The fact that Lean Startup makes us learn faster doesn’t necessarily mean reducing time to market (we charge early customers to validate ideas, not to make money). In order to create sustainable new revenue we need to solve real problems and excite our customers. That is hard.

This is how the Lean Startup brings value to you:

  • reduce cost
  • reduce the risk of making a bad investment
  • increase our chances of building something our customers want (to pay for)

But we cannot guarantee reaching break even twice as fast.

To illustrate my point I have combined the “Crossing the chasm»-illustration from Geoffrey Moore with the process of building a Lean Startup.

Skjermbilde 2015-03-13 kl. 13.46.30

How fast should we expect to reach the “chasm” and fase our biggest challenge yet of getting into the mainstream? How do we know if we have successfully crossed it?

What is your criteria for starting to invest and scale your product, service or business model?

 

Lean Startup: Validation has no soul

I had this idea that I wanted to develop, but as entrepreneur and Lean Startup practitioner I immediately faced an inner conflict:

If I was to do as I preach, I should on the very first hour begin by exploring the world of potential customers. What I felt like doing, was to start programming. Under excuses like “I’m also doing this to learn a new web framework” and “this is just a hobby project”, I chose the latter. If nothing else, I also decided to pay close attention to my development process and how it evolved. I even promised myself I’d write about it, so here we are.

My customer segment is newbie textbook authors and novelists. I assume they have the following problem: Writing a book is a solitary process. I know this to be true for at least one person in the entire universe.

Myself.

In other words, like the 37signals guys, I’m solving my own problem. I’m well enough into Lean Startup and entrepreneurial thinking to know I shouldn’t be working like an author – in solitude – so I have a few users in play (and they have already given me valuable feedback).

Apart from learning a new web framework, I’m also realizing something about the Lean Startup: I think I may even have found a silver bullet.

Let me explain.

Continue reading

The Iterate Garage

We don’t foilware our work anymore, sorry, but no can do.

Instead we have turned ourselves into The Iterate Garage Enterprise Edition. We are the Action Team that builds new revenues, shares knowledge and lives in a tornado of learning loops in the commercially harsh and real world together with billion dollar corporations. When we are wrong, we learn and create the next iteration of ideas based on reality and live “build – measure – learn” loops.

Consultants have turned into product owners, customer journey specialists, prototyping artists, brand managers, experience designers, business developers, business model architects, or a combination of the above. Developers sit side by side with product owners and experiment designers.

Our managers have been turned into Experiment Designers, CEOs, Chief Commercial Officers, Head of Customer Voice and Chief Corporate Entrepreneurs.

We build and we cry – we build and we laugh – we build and solve real peoples problems.

And we love it.

Best Regards

Torve Indahl

@torve

I am a serial entrepreneur focusing on innovation in large enterprises and I head The Iterate Garage Team. 

“Want to learn more about how Lean Startup worked for other established organizations? Sign up for free Lean Startup School!”: http://info.iterate.no/lean-startup-skolen/ (in Norwegian)

Focus & Do the Simplest Thing Possible

Cross-posted from The Holy Java.

Credit: Dennis Jarvis, CC

Are you tired of days spent in front of the screen, with no results to show? Have you once again engaged in yak shaving? Today, after having failed previously, I have finally managed to solve a problem while avoiding this trap by following rigorously two guidelines preached by grandmaster programmers. Be warned: Following this approach, you will get a working solution – but you won’t like it. It will be ugly, stained by compromises, far from the elegant solution you wish for. But if your resources are limited and you want to avoid death by too many yaks, this is your only option. But first, what are these guidelines?

One: Maintain a laser-sharp focus. A great programmer is constantly aware of what she is trying to achieve and never strays far from it. If the path leads away, she backs up. If something else pops up, she writes it down for later and gets back to the job. This is essentially about deciding what not to do. (Many thanks to Kent Beck for sharing his focus secret!)

Continue reading

Continuous Delivery Digest: Ch.9 Testing Non-Functional Requirements

Digest of chapter 9 of the Continuous Delivery bible by Humble and Farley. See also the digest of ch 8: Automated Acceptance Testing.

(“cross-functional” might be better as they too are crucial for functionality)

  • f.ex. security, usability, maintainability, auditability, configurability but especially capacity, throughput, performance
  • performance = time to process 1 transaction (tx); throughput = #tx/a period; capacity = max throughput we can handle under a given load while maintaining acceptable response times.
  • NFRs determine the architecture so we must define them early; all (ops, devs, testers, customer) should meet to estimate their impact (it costs to increase any of them and often they go contrary to each other, e.g. security and performance)
  • das appropriate, you can either create specific stories for NFRs (e.g. capacity; => easier to prioritize explicitely) or/and add them as requirements to feature stories
  • if poorly analyzed then they constrain thinking, lead to overdesign and inappropriate optimization
  • only ever optimize based on facts, i.e. realistic measurements (if you don’t know it: developers are really terrible at guessing the source of performance problems)

A strategy to address capacity problems:

Continue reading