Posts tagged ‘LeanStartup’

Leseliste zu Lean Startup

Lean Startup wird immer bekannter. Entsprechend sprießen Bücher, Blogposts, Vorträge etc. zu dem Thema aus dem Boden. Die folgende Leseliste soll bei der Orientierung helfen. Die Empfehlungen sind nach der Lesereihenfolge geordnet, die ich empfehle. Es beginnt mit kurzen Überblicksartikeln, geht dann zu den Grundlagenbüchern und endet mit konkreten Erfahrungen, die helfen, den möglichen Einsatz von Lean Startup im eigenen Unternehmen zu diskutieren.

Lean Startup verstehen

Stefan Roock: “Lean Startup”, Artikel in Objekt-Spektrum 1/2013, deutsch

Dieser Artikel gibt einen kurzen Überblick über Lean Startup und sollte hilfreich bei der generellen Einordnung des Ansatzes sein. (Der Artikel ist tatsächlich noch nicht erschienen. Aber solange dauert es nun auch nicht mehr 🙂

Eric Ries: “The Lean Startup”, Buch, englisch & deutsch

Eric Ries ist derjenige, der Lean Startup unter diesem Namen bekannt gemacht hat. Daher ist das Buch in gewisser Weise ein Must-Read. Man sollte allerdings nicht zuviel erwarten. Das Buch argumentiert gut, warum und wann der Ansatz nützlich ist. Er gibt aber wenig Hilfestellung dabei, wie man Lean Startup konkret anwendet.

Das Buch gibt es auch in einer deutschen Übersetzung. Die habe ich aber nicht gelesen und kann daher nichts zu deren Qualität sagen.

Ash Maurya: “Running Lean”, Buch, englisch

Dieses Buch ist deutlich handlungsleitender als “The Lean Startup” und daher meine Empfehlung für alle, die sich ernsthafter mit Lean Startup auseinander setzen wollen.

Lean Startup für den eigenen Kontext bewerten

Doreen Timm, Sandra Reupke-Sieroux: “Lean Startup – Lessons Learned”, Artikel in Agile Review 2/2012, deutsch

Dieser Erfahrungsbericht beschreibt, wie 7 Kollegen von it-agile einen Monat lang ein Startup nach dem Lean-Startup-Ansatz betrieben haben. Dabei werden insbesondere auch die kritischen Punkte deutlich herausgestellt, die nicht funktioniert haben. Es ist daher ein sehr nützlicher Artikel, der hilft, nicht nochmal in die selben Fallen zu tappen. Wer die “Agile Review” noch nicht besitzt, kann sie bestellen bei info@it-agile.de.

Stefan Roock: “Pivots in grown companies“, Blogpost, englisch

Der Artikel beschreibt ein wichtiges strukturelles Problem bei der Anwendung von Lean Startup in “erwachsenen” Unternehmen, die eine funktionale Abteilungsstruktur haben. Wenn man Lean Startup in “erwachsenen” Unternehmen anwenden möchte, ist es aus meiner Sicht wichtig, diese Fußangel zu kennen. Dann kann man sie früh adressieren und angemessen damit umgehen. Es zeigt außerdem, dass Lean Startup in “erwachsenen” Unternehmen durchaus auch Unternehmensentwicklung bedeuten kann.

Lean Startup anwenden

Stefan Roock: “Lean Startup: a classification of MVPs“, Blogpost, englisch

Der Artikel präsentiert eine Klassifikation von MVPs (Minimum Viable Product), die dabei hilft, den passenden MVP-Typ für die vorliegende Fragestellung zu identifizieren.

Steve Blank: “The Startup Owners Manual”, Buch, englisch

Das Buch von Steve Blank ist umfassend und entsprechend dick. Es ist eher als Nachschlagewerk konzipiert als ein Buch, das man von vorne bis hinten durchliest. Entsprechend ist das Buch nützlich, wenn man konkret beginnt, mit Lean Startup zu experimentieren.

Unterstützung durch it-agile

“Lean Startup mit Scrum”, Schulung, deutsch

Diese Schulung vermittelt praxisnahes Wissen zu Lean Startup. Mehr Informationen findet sich unter http://www.it-agile.de/leanstartup-mit-scrum.html

Lean Startup Coaching

Natürlich ist Coaching viel teurer als ein Buch oder eine Schulung. Dafür ist die Vermittlung von Wissen und Fähigkeiten durch Coaching viel schneller und direkter anwendbar. Wer externe Lean-Startup-Expertise für sein Team sucht, wird fündig unter: http://www.it-agile.de/innovative-produktentwicklung.html

Lean Startup Team

Wer eine neue Produktidee hat und ein komplettes, erfahrenes Lean-Startup-Team sucht, wird hier fündig: http://www.it-agile.de/innovative-produktentwicklung.html

 

 

 

November 7, 2012 at 9:15 am 1 comment

Pivots in grown companies

Thesis: Pivots in grown companies are challenging

When you pivot in a real startup the situation is quite simple. The product team recognizes the need to pivot and then does the pivot.

In a discussion with Markus Andrezak I realized that the situation is quite different when you want to pivot in a grown company. Then the pivot often affects not only the product team but completely different departments. And therefore you may need to get the commitment of the CEO to pivot. In a larger company this may increase the time you need for the pivot to weeks or months.

An Example

Let’s look at an example of a marketplace platform with a transaction oriented pricing model like eBay or Amazon: The company earns money everytime a transaction is completed. According to this model the KPIs of the marketing department are based on transactions. The KPIs of the sales force may be based on new registered sellers.

Now let’s assume that in our imaginary example company revenues have stopped to grow. After some investigation the product team thinks it should pivot the transaction based model and just connect buyer and seller. While the product may need only minor modifications it changes nearly everything for marketing and sales. The marketing KPIs based on transactions become senseless and need to be replaced. For the sales force the change may be even more dramatic. Perhaps registered sellers are not that important any more. Perhaps there is even no need for a sales force any more?

The product team would not be able to make these changes happen within the company on its own. The changes would need the intervention of the CEO.

Rationale

The situation described in the example is not a special exception. It is the result of the nature of a pivot. A pivot is not just a modification to a product feature. Pivots address the product strategy – revenue streams, cost structure, key partners, target group, customer needs as well as key features.

The most aspects of the product strategy are built into a grown company. The revenue streams and key partners affect sales. Target group and customer needs affect marketing. The cost structure affects operations. And so on.

Therefore: In a grown company a pivot is a major change to the whole company.

The consequences are:

  • You need to analyze what parts of the company may be affected by the pivot.
  • You often need commitment or at least explicit support for the specific pivot by the CEO.
  • You may have to market your pivot to the whole company.
  • The pivot may take weeks or months.

August 19, 2012 at 7:09 pm 4 comments

Lawless Agile

In march 2012 seven it-agile people (including me) formed the StartupMarch team. We decided to build a product to make online discussions more effective. In the end we had built http://www.discuss2decide.com and http://www.discumeter.com.
This blog post is about the “process” we used. We just started to build the product – without any discussion of the process to use – Scrum, Kanban, XP? We just didn’t talk about it. This is what emerged:

  • Before the start of the StartupMach we only had decided on the problem to solve (online discussions) and the technology we would use (Rails). So we invested the first day for some conceptual work.
  • At the second day we started the development of the first ideas. We had the first product (Duscuss2Decide) live at day 3 and the second (Discumeter) at day 5. After that we had more than 15 releases per day. The rule was simply: whatever you commit into the master (aka Trunk/Head) will go live immediately.
  • Typically we started the day with an informal wrap up of the product usage (a kind of review if you want). Then we discussed what to do during the day (kind of planning). And then we did it. For both “meetings” together we invested 30 to 90 minutes.
  • During the day we had 2 to 4 sync meetings to check where were and how to proceed (kind of Daily Scrum).
  • We did no Task Breakdown but Story Splitting on a very tiny level. We worked with MMFs (Minimal Marketable Features) that we broke down into User Stories. Most stories were done in less than 2 hours.
  • We managed work in progress by gut feeling. Normally we all would work on the stories of one MMF (single piece flow). That way a MMF normally needed one day to complete.
  • We did Pair Programming in most cases and often switched pairs at the sync meetings.
  • We had two retrospectives. One in the middle of march, one at the end of march.
  • There were no roles. No Product Owner, no ScrumMaster, no Testers etc. Just team members. During our second retrospective we had a discussion about the roles. The conclusion was that we sometimes would have profited from a ScrumMaster for facilitating discussions and forcing us to face uncomfortable facts. And we thought that the absence of a Product Owner person was helpful. The team was not only empowered to decide on how to do the work but also on what to work on.

It was a great time. We had a lot of fun, we learned a lot and it felt very productive. Although we didn’t acquire millions of venture capital for our products, Discuss2Decide seems to have value for users. There are some regular users of the tool and most online discussions at it-agile are done with the tool today.

Will it travel?
Will the “process” travel to other contexts? I don’t know. I think there were two special ingredients that are uncommon and may have been crucial:

  1. With the seven team members we had roughly 45 years of experience with Agile of different flavors in the room: Scrum, XP, Kanban, FDD.
  2. All team members shared a common cultural background (it-agile) that showed up as an extreme openness for other’s ideas, perspectives and needs.

Read more about the Startup March.

May 17, 2012 at 6:58 pm 1 comment

StartupMarch@it-agile 2012

In March 2012 seven it-agile members formed a Startup team that tried to solve common problems with online discussions. We created two products (http://www.discuss2decide.com and http://www.discumeter.com), learned a lot and had a barrel of laughs.

Me and my collegues will write and talk about our experiences with Lean Startup, customer development, agile to the extrem, continuous deployment (we had about 15 live deployments per day) and more. I will collect all these ressources at this page.

Here is, what we have by now:

March 30, 2012 at 8:20 pm 4 comments