Lessons from our Lean Startup Experiment

So - last week, two friends and I conducted this four day long lean startup experiment. Which lessons did I take away? The first and foremost lesson is: It's great fun, to work focused and hands on in such a small team on a nice product!

Further lessons were:

• You should formulate your hypotheses clear and write them down on a piece of paper. Do really ask yourself which assertions you want to verify - and if the experiment you are conducting will indeed give you evidence for that.
• Even if you did this, you will be inclined to neglect negative evidence - especially if you are in love with your own product. Your head will always tell you that everything was wrong (data, experiment, people) - but not your idea. This is a real challenge! And it makes the first point even more important.
• An MVP is not necessarily very small. There are some hypotheses, you will have to invest a good amount of work into, to proof or disprove them.
• You should have enough time and reserves to do some pivots. Otherwise your are relatively certain to fail with your first or second wrong hypothesis.

I asked myself after the experiment if we did pivot at all. Since we did not write up our hypothesis formally (we only talked about them), I did not know immediately. But thinking about it, I found that we pivoted quite some times in that four days. On the first day we switched from the idea of building a mobile app to building a website first. There were further pivots - and I think all of them helped us to get a much better understanding of what we should build.

Conclusion: Taking a lean startup approach really forces you to get in touch with real people - potential users. Those people are able to give you extremely valuable feedback in very early stages of product development. It's a great approach for product development - but there is still much more to be learned and done to build great products!

Lean Startup Experiment - Day 4 (and last)

At this moment we decided to finish our lean startup experiment. We were currently coping with technological difficulties with a relatively simple feature. It is now clear, that we will not be able to accomplish everything we wanted to until Friday evening. Thus, we all agreed to stop and use the last day somehow else.

Why did we struggle? A short retrospective revealed the following issues:

• We did by far not do enough marketing - thus we had almost no real customer feedback on our site (there was exactly one person subscribing the service :-(). We did get some feedback indicating, that potential customers did not really get the idea of our page.
• We did not prepare well enough for our experiment. We used a whole lot of technologies, we did not really know. This broke our neck today.
• One week is really short for delivering even a relatively simple project in a serious manner.
• Summertime is a really hard time to stay focused on such a project ;-)

But after all, we all still learned a great deal. Not only technology, but also how to work in short cycles as a small team. Setting small reachable targets every day and having short status syncs worked extremely well for us.

A big thank you to all readers of this blog and all supporters giving us valuable feedback on our little product! We will now go on and enjoy a great free three days before going back to business as usual :-)

Lean Startup Experiment - Day 3

Day 3 of our experiment is over. It was a day full of work and (from our point of view) huge progress on the project. We improved the layout massively and included some hints on the page about our intentions. We got the large image view working and took care of some legal aspects. You are now able to register yourself as a prospect customer by clicking on the login button and sending an email. We solved several infrastructural problems including deploying our app to the Amazon cloud (EC2).
If you would have asked us this morning, if we would be able to accomplish this - nobody of us would have said "yes" probably :-) It was a great day and we learned a great deal of things about all the new frameworks and technology we never used before!

Sven working hard to keep the backlog up-to-date. We are working to fast :-)

We are very proud of our layout. Especially because there are no designers in our team. If you like our design, too - or hate it: Please tell us! We need feedback! Fastly! (You may use the comments section, for example)

The current UI prototype contains some description on what we want to achieve. We love it :-)

Key learnings of Day 3

• Working with lower outside temperatures is MUUUCH better!!!
• JavaScript is shit
• JavaScript is cool
• We did not get any customer feedback today - which we regret. We will have to improve on that massively tomorrow!
• On the other side - we got a lot of things done, which was really great fun!
• IT guys cannot live without becoming sarcastic - even if successful ;-)
• We think the purpose of our project is not clear enough for visitors on the first view. We will have to improve massively on that!
• We are not able to acquire enough prospect customers by doing marketing over Facebook, Google+ and Twitter only. We will have to try out other marketing mechanisms.

Our main goal in the next two days is to come so far as to be able to go outside and sell our idea to passers-by. Functionality of the site should be so far, that those people will immediately see a value for themselves in using our project. Ambitious goal! Let's see...

Lean Startup Experiment - Day 2

The second day of our lean startup experiment is over now. What did we accomplish? What did we learn?

What did we accomplish? 

The first thing we did this morning was to reprioritize our product backlog. We then managed to sketch some (seventeen!) paper prototypes and chose the one we liked best in fifteen minutes. Afterwards we kicked the complete technology stack we wanted to use yesterday and set up a new one. But still we managed to get a first UI prototype online this evening. You can find it here: http://thatsmykid.de/

First UI live prototype of ThatsMyKid

Key learnings:

• The prioritization of a product backlog in a lean startup project is stable for at most half a day...
• Do not start lean startup experiments if it is 35 degrees celsius outside - can be quite demotivating :-(
• The open working environment at Coworking Space Nuremberg is really cool and enjoyable.
• The new technology stack (Meteor, JQuery, JavaScript) is really good for rapid prototyping.
• Having an hourly status (review) meeting before commiting code helped us a lot to stay focused and avoid trouble.
• Technology is waste (it takes a LOT of time - even if you are not an expert with it)
• Driving three different technological approaches to our first prototype was a good idea, since we learned very fastly, which one would fit our project.
• No design is the best design (at least almost none :-)
• If you have your first UI prototype this is REALLY motivating!

This day started out very frustrating but had an amazing turning point when we first saw our UI prototype in the first review working. The deeper we dive into technology and minimal feature set, the more obvious it becomes, how massively complex a simple application must be. We are optimistic to learn a lot during the next three days and are glad that we love our design so much.

Lean Startup Experiment - Day 1

At this moment the first day of our lean startup experiment is at an end. What did we accomplish today? Essentially, we "proved" our hypothesis, that there might be some interest in an application as we imagine it. Additionally we got some valuable feedback for our app based on the paper prototype we constructed in the morning.

Paper prototype of ThatsMyKid

Sven showing our valuable feedback vom passers-by

Key learnings for today:

• The paper prototype massively helped us to show people, what our idea of the app is. The feedback for our prototype was very helpful and good. Having something to present and touch is an invaluable advantage!
• Feedback from potential future customers can be very motivating. Get feedback from customers as fast as possible!
• Establishing a backlog - even for a product you have a relatively clear vision of - is hard. It is hard work to focus on the key features of your product!
• The last step today was setting up the infrastructure to build a first prototype, which was very time consuming. We didn't expect it to be that hard. Even if many Google services (which our technology stack depends heavily upon) are really easy and convenient to use.

Preliminary ThatsMyKid logo

A lot is done. But there is still more to do...

We are now keen to see, what we will be able to deliver after the second day of our little lean startup experiment. Stay in touch!

A Lean Startup Experiment

Today we (Sven Schäfer, Sven Winkler and myself) are starting a lean startup experiment. We all took one week of and want to explore, how to apply lean startup methods and how much of an app we are able to develop in this time. The experiment startet this morning at 9:00 CEST in the coworking space in Nuremberg. It will be finished on Friday evening - no matter what we accomplished in that time. We are now eager to learn :-)

Our first step currently is to formulate and validate our first hypothesis, which is: "In addition to Facebook and Google+, there is still room for an app that allows parents to share and show photos of their children in a clear, easy and secure manner."

We do currently try to validate this hypothesis in two ways:

1. We set up sites on Facebook and Google+ and uploaded photos of a paper prototype of our new app. We liked and postet on this platforms and will observe how many likes and "+1" we will get. If there will be a great number of likes, this is one indicator, that our hypothesis might be right. If nobody likes - we might be wrong with our assumption.
   Help us with feedback and have a look at our social media pages on Google+ and Facebook. 
2. We will soon go outside into the city of Nuremberg and try to show our paper prototype to some passers-by. We will observe their reaction and therefrom derive, whether our hypothesis is right or wrong. This channel has the advantage, that we can ask for additional feedback and maybe adapt the initial idea and to formulate new hypotheses.

First paper prototyp of the ThatsMyKid app.

Retrospectives of all days can be found here:

• Day 1
• Day 2
• Day 3
• Day 4

When is Scrum applicable?

Over the years, I was oftened asked the question: "Is Scrum applicable in this context?" or alternatively "When or under which circumstances can I apply Scrum?". I gave (and read) lots of more or less sophisticated answers to that question, but have a very simple approach to answer this now.

You are able to (and probably should) do Scrum if:

1. You are able to fill a Product Backlog
2. You have - or can establish - a Team (which means team - not group!)
3. You have - or can establish - a Product Owner
4. You have - or can establish - a Scrum Master

That's it.

Of course you can still use several single practices and tools of the Scrum framework if these conditions are not fullfillable - which is not a sin. But you should not call it "Scrum" then!

The Thing Missing in Scrum

I am working with Scrum very successfully for several years now. And it is by far the best methodology crossing my way in software development. Yet, I think there is one thing, missing in Scrum - its slack time.

Most Scrum coaches would probably say: "No, no, no... Slack is not missing. It is ...

1. ... automatically emerging, because the team is self-organized. It is in the responsibility of the team to take whatever slack is needed to accomplish their work."  
2. ... an optional add-on to Scrum. You can just implement some slack additionally as you like. But Scrum does not lack slack. Slack is not missing more in Scrum than it is in traditional work environments."

I personally think, those arguments are not valid. 

Argument 1 is questionable: Nobody knows when he "needs" some slack, to be creative and thoughtful. Slack happens to help sometimes and does not help on other occasions. Thus, slack must just be there from time to time (for every single individual - not the team as a whole), so you get a chance to let your brain defocus and accidentially stumble over some very good ideas and thoughts. The tricky thing about slack is, that you will not "miss" it at a specific point. The need for slack ist not foreseeable. Thus a even a self-organized team cannot be expected to know when to take some slack time.


Argument 2 has its flaw, too: You could similarly say that Scrum has no need to contain the role of a Product Owner, but one should implement it as an add-on to Scrum. But this is obviously wrong, since you need somebody giving input to the team, having a more global vision, and beeing responsible for creating business value. Scrum needs to define this role, since it removes the role of the project manager (who was responsible for this tasks earlier).
I think the same is true for slack: Scrum is much about focus and productivity. This is not wrong, but it lacks a necessary concept of slack. Even more, it squeezes some natural amount of - often healthy - slack out of the team that occurs in most classically organized companies from time to time. The point is: Because you are working so much more focused on creating value for the customer (which naturally comes with Scrum) and achieving Sprint goals, a certain amount of slack should be built in, too. This is why I personally think that slack is the missing thing in Scrum.

I guess it would be of great value to Scrum if the framework contained some slack space for every individual in the team (e.g. everybody has one "free" day, where he is not expected to contribute explicitly to the sprint goals).

What do you think? Is there the necessity for slack time in Scrum or are there indeed mechanisms in place substituting this need? What are good mechanisms to build slack into a Scrum team?

Why Agile is Doomed to Succeed - If Done Wholeheartedly

and why Scrum implementations sometimes fail - or do not deliver what they promised


I recently read the book "Drive - The Surprising Truth About What Motivates Us" by Daniel H. Pink, which is much about motivation in the 21st century workplace. There is a tight connection between the ideas expressed there and the thinking and principles behind the Agile movement (e.g. Stoos-Network, Scrum, XP, etc.). I want to try to work out this connection, so you can understand one of the key success factors of Agile. If one understands these, one has - as a byproduct - immediately a good understanding at hand, why Scrum implementations do sometimes either fail or not deliver what was expected of them.
I will at first try to explain the core drivers and levels of motivation Pink describes in his book. He destinguishes three levels of Motivation:

• Motivation 1.0: This is what essentialy motivates every kind of mammal to do whatever it does. It's about the basic necessities for survival: eating, drinking, reproducing, security, etc. In essence Maslow's hierarchy stages 1-3. This was probably fine for humans in stone-age and earlier times.
• Motivation 2.0: Essentially based on rewards and punishment (or as Pink states it - carrots and sticks). This was one of the main drivers of the industrialization era where thinkers and managers where broadly influenced by the theories of Frederick W. Taylor and his "scientific management". It is all about command & control and extrinsic motivation. Work in this times was in huge parts not very complex and consistet much of simple repetitive tasks, that are done by computers and robots nowadays.
• Motivation 3.0: There is strong evidence from scientific research of the last five decades, that Motivation 2.0 (rewards & punishment, extrinsic motivation) are very unreliable and weak motivators in our current social and industrial environment (but still relevant for some very specific settings). If you want to read about and understand this hints - read the book! Following the book there is a better motivation scheme than Motivation 2.0, wich is based on intrinsic motivation. This motivation scheme has three core drivers:
• Autonomy: Not to confuse with independence! Autonomy means the need and ambition to have as much as possible autonomy over the work to do. It means having the opportunity of acting with choice (e.g. choice over how to do the work and when to do it best). "Control leads to compliance; autonomy leads to engagement".
• Mastery: The willingness, to strive for excellence. It is about continuous improvement and perfection of the personal skills. Which is not the willingness to be the best of the best, but more the drive, to make the most out of the talents and abilities one has (which is the most you can expect!).
• Purpose: Everybody wants to see the work he does in a greater, meaningful context. The work one is doing from day to day should have some greater sense, which is indeed almost always the case, since most of all work is done for some customers.

So far - so good. But where is the connection to Agile?

It is essentially very simple. Agile is in big parts build exactly around the core drivers of Motivation 3.0. Let me explain this shortly:

• Autonomy: Starting with XP, continued with Scrum and now discussed in the Stoos-Network is the central idea of the self-organizing team. The idea is to give a team as much as possible autonomy over the work to do.
• Mastery: Here craftmanship (XP) and continuous self-improvement (Scrum, Stoos-Network) are the keywords. These postulations and processes are inseparably connected to agile processes and ideas.
• Purpose: Agile frameworks generally build upon integration of the customer. The tighter - the better. Direct feedback and collaboration with the customer is probably the best way of getting sense and meaning to your work. This is because you immediatly see, who benefits and get direct feedback.

OK, I understood that, but where is the point of failing Scrum implementations? How does this motivation stuff help me understanding the why of failure? It is not hard:

Scrum works out well, if you encourage these points, since motivation of your teams is very likely to increase. Increased motivation leads to increased productivity and - by the way - to increased satisfaction.
If you do only use the mechanics of Scrum, but do not really let the teams self-organize (giving them the freedom to make their own decisions!) or do not cultivate craftmanship (invest in education, encourage and set the stage for self-education) or do not bring the customer as close as possible to the team, motivation will not flourish. Thus, you are very likely not to improve very much - and be doomed with another process corset. Which I would just call failure.