(French translation, Spanish translation, Japanese translation)

A couple of years ago I drew this picture and started using it in various presentations about agile and lean development:

Since then the drawing has gone viral! Shows up all over the place, in articles and presentations, even in a book (Jeff Patton’s “User Story Mapping”  – an excellent read by the way). Many tell me the drawing really captures the essence of iterative & incremental development, lean startup, MVP (minimum viable product), and what not. However, some misinterpret it, which is quite natural when you take a picture out of it’s original context. Some criticize it for oversimplifying things, which is true. The picture is a metaphor. It is not about actual car development, it is about product development in general, using a car as a metaphor.

Anyway, with all this buzz, I figured it’s time to explain the thinking behind it.

Continue reading

Varje produkt börjar med en idé. Det första man behöver göra är att validera den idén och det görs bäst genom att bygga det minsta möjliga som förklarar den idén och gör idén mätbar. Låt oss kalla det den minsta mätbara förhandstitten.

När man mäter så får man data för att kunna avgöra om idén var bra eller inte. Det vi lär oss av att mäta och utvärdera idén kan vi sedan nyttja för att ta nästa steg, såsom en detalj av idén eller en ny idé baserad på den förra, som vi också behöver mäta och utvärdera. Vi vill validera problemet, målgruppen och möjliga lösningar för att vara säkra på att inget lämnas åt slumpen. Detta blir en lärandeprocess baserad på riktiga resultat.Continue reading

I recently attended a course (the excellent LeanUX course held by my colleague Martin Christensen) and again the topic of what a MVP is or is not came up in a discussion. In the Lean startup-world an MVP is defined as the smallest thing you can make to validate a hypothesis which helps you decide if you should continue developing something or if you should stop. For more information about this, I suggest you read Eric Ries’ blog post on the topic. However, in (very) many companies and organisations the term is used to describe the first version of a product released to the end customers. This “version one release MVP” usually contains as little functionality and features as is possible without making the end customers too upset, disappointed or unwilling to pay.

Another colleague of mine, Henrik Kniberg, wrote a quite thorough and lengthy blog post about MVPs a while back where he touched upon the point I’m about to make. While quite a few people see the different uses of the word MVP as problematic, I see it as a symptom of a need for a better word for describing at least one of its currently used meanings, i.e. the “version one release MVP”. Luckily enough a good friend and coworker gave me the answer to that need a few years ago: He called the first release of the hardware product we were working on at the time the “Minimum Loveable Product”.

Continue reading

This is the second article in my series on integrating discovery and delivery. In the first article I outlined some common challenges I have seen holding organizations back from benefiting fully from both.

In this article I will introduce some patterns that will help you integrate product discovery and product delivery in a way that works. These patterns have all been field tested in practice.

Estimation seems to have gotten a bit of a bad reputation lately.

One misconception I sometimes see is that estimation beyond just a few weeks is “not agile”. Another trend is that some people advocate against doing estimation at all mostly because they view it as a beginner tool, so by not estimating we are no longer beginners.

To me doing estimation or not does not really say much about “how agile you are”. The way I look at it is that we should estimate when the reasons to do so outweigh the reasons not to do so. That simple.

In some scenarios this also includes doing estimation of large backlogs.

So in this article I want to share what I see as some of the reasons FOR and AGAINST doing estimation of a larger backlog. You can then decide for yourself if your situation justifies doing it or not.

Continue reading

Du har en idé om en tjänst.
Hur kan du snabbast och enklast verifiera att någon vill använda den?
Det är vad Lean Start-up handlar om.

Continue reading

This is a guest post from veteran Agile UX coach Anders Ramsay who’ll be visiting Crisp in March.

In a traditional UX practice, there tends to be a strong focus on whole product design.  In other words, we want to integrate all the features of a product into a unified and coherent experience, before we can consider the design work to be done.

Big Design Up-Front is like growing a tree in a “wireframe nursery” before planting it in the real world of working software.

But if you are taking this approach in designing the user experience, and you’re also part of an Agile team, then that might be a major reason why you’re struggling to integrate your UX practice into an Agile model.Continue reading

One of my biggest surprises when I first met the squads I where going to work with at Spotify was that none of them were using User Stories. At first I observed to see their alternative. Unfortunately there was none. Instead most of the work got done as big chunks of work (what I would tend to call Epics) that was sliced into a todo-list of tasks (named that way by the developers) and also divided according different platforms.

Squad focus on technical tasks

A typical board contained one or more business cases and lanes for each developer/platform with tasks that were executed upon. These big “busses” where on the board blocking other works for weeks, which of course meant there needed to exist one or more emergency lanes for all expedite work (in the long run, most work).

This is a setup that does not foster collaboration, focus on value and art-of-the-possible. From an agile fluence point of view I would say it is a way of working that does not even reach fluence level 1 (Christian and I will describe agile fluence in more depth in a follow up blog post). From my experience focusing on User Stories is a great way of fostering the above values, and reach fluence level 1.

Continue reading

I just love Kickstarter.com! For me it has become the best place to discover new stuff on the web. The creativity gathered there is simply staggering! Kickstarter succeeds in raising and focusing creativity by offering a mechanism to finance projects that is not based on risk-aversion and profit-focus, but on anyone’s dream to create something that they