Lean Summer of 2015 – Week 5

Can 6 tech students help a telecom giant innovate in 6 weeks? Telenor Norway wants to solve real problems for real people. As summer interns in Iterate – the lean startup consultancy in Norway – we’ve been hired to build, measure and learn how to unleash the power of future telco technology. Every week we blog about what we’ve learned.

Here’s week 5.

Navigating the corporate jungle.

Compared to the real world, student life is easy. We are free to do almost whatever we want, when we want to. You never really have guilt-free time off, but you also don’t have to get up early every day.

For many of us, summer internships are the first taste of a real job. We would soon discover that getting up early would be the easy part.


How many interns does it take to fire up a grill? One to light it and four to watch it in silence and scare away the seagulls

Continue reading

Flow: The idiosyncrasy of awesome engineers

“Earth to Anders! It’s the daily stand-up!”

It felt like being a boy again, hearing my mother calling me in for dinner when it finally was my turn to be Darth Vader.

I didn’t want to attend that meeting. Agile was great, but I wanted to code. To learn my tools. To be an awesome engineer.

Two weeks into my first iterative project, I was in conflict with myself.

It came unexpectedly; not only was this an agile project – I finally had the chance to code Enterprise Java using this innovative IDE with refactoring tools and other sophisticated code manipulation features called Eclipse. The project of my dreams, in other words.

(You guessed right, it’s some 10 years ago.)

My team and I had also read books about agile methodology, and we just loved throwing away late testing, early specifications and other anachronisms of the checkered past of software engineering. Our focus was on feedback: We had daily stand-ups, long retrospectives and pair programming.

But there was a snag:

Continue reading

A very quick way to A/B-test

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.

Continue reading

Lean Startup as an invisible hand

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


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

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.



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.”.


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

Don’t substitute MVP for beta

Experience shows that early product releases can be a smart move when doing innovation. What used to be called betas or even alphas is nowadays often referred to as an MVP (Minimum Viable Product).

In Lean Startup terminology an MVP is the minimum set of features that address the most important problems you are trying to solve for your customers (Ash Maurya, Running Lean). The motivation for building an MVP is to verify any assumptions you might have about customers’ problems and your ability to solve them.

A lot of people are however substituting the word “beta” with “MVP” these days, although there are some significant differences.


First of all, the MVP is not necessarily a technical solution. You might build an MVP without using any software at all. Nor is it the least amount of features it takes not to be embarrassed, to get some attention, or to make a sale.

Continue reading

The one idea-retrospective

I sometimes facilitate retrospectives for teams that don’t feel like they have the time to do retrospectives.

I know the feeling from personal experience: We’re in a toxic world about to crash to its doom. Coding is the protective suit we need to get the h— out of there. And it’s in short supply. Sitting in meetings feels like swimming in green, toxic slime.

Doom by id software

No time to think

Skipping retrospectices is obviously silly. However, the same goes for sticking to your old format for retrospectives. Not that a proper retrospective couldn’t alleviate your situation and even get you into less of a hurry: There is always a potential irony that you don’t have time to evaluate your work, which keeps you from discovering the very problems that steals time away from evaluating your work.

The problem with sticking to the old retrospective format is that you will eventally stop doing retrospectives all together. In my definition of not doing retrospectives I also include 10 minute rants around the table before we get into iteration planning. As fun as they might be, rants don’t count. Although the latter is commonly used to describe the former, ventilation and retrospectives serve two different purposes.

So. If you don’t have the time to do retrospectives, my suggestion is that you do them anyway. In 15 minutes.

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