Public Secrets of Mount Change

Change is hard!

To change something does always mean, to risk something - to loose something. In exchange we always have the chance and hope to win something. Ideally, we loose something bad and win something good. But we do almost never know...

What we know is, that it is deeply human trying to adhere to the current state.We call that e.g.

• Loss aversion
• Risk aversion
• Ambigutiy aversion
• ...

So: Change is hard!

Does this mean that you should never change? No! But if you think you have to face a big change initiative, you should be able to really answer two questions for yourself:

1. Is there a desire, necessity or urgency perceptible that will make the effort of climbing Mount Change seem smaller than bearing the consequences of standing still?
2. Do you have a clear vision, mission or goal that will ensure that people roll down Mount Change together and in the right direction?

Only if you have clear and simply understandable answers to these two questions, you should start your efforts. For that you will not forever start and never reach the top of Mount Change. Nor will you roll down the hill and fall of some cliff because some people took the wrong direction.

Don't misunderstand me. You are not done with answering these two questions. But it is an important point to start. And you are ready to take up your hiking stick, then. Good reads on the change topic are:

• "The Corporate Culture Survival Guide" by Edgar H. Schein
  This book exposes the rich set of experiences of Edgar Schein, who is one of the first, most famous and influencial organizational psychologists.
• "How to Change the World" by Jurgen Appelo
  This book stresses out a view on organizational change that is based on systems- and complexity theory. It is not a complete collection of steps for a succesful transformation, but a brilliant guide to getting the right attitude towards organizational change.

Great Teams!

Last week, I attended the ALE 2013 unconference. This is definitely one of the most awesome conferences I have ever seen. There is lots of energy, ideas and passion around there and it is an extremely inspiring environment.

I used the opportunity of open space to facilitate a session on "Great Teams" there. I will share the result of this session here. The format of the session was very simple. Every attendee got the opportunity to tell the story of a great team he was part of or has seen. After the story was told, I asked something like "If you should pick out one thing, that made this team a great team, what would it be?". Many attendees told great stories and we finally came up with the following list of things, that make teams "great".

Do you have stories to tell? What is the one thing, that makes your team great? Feel free to use the comments section!

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

Empower! Your! Teams!

Empower the Team!

I have seen it time and again: Teams that would probably be able to be high performaning, but are not able to live up to their potential. Why? Because they are used, seen and organized as efficient task processing units.

Most teams could deliver a much greater performance and experience, if they would only be given serious challenges and the freedom to act.

Unleash the potential of your teams and

• compose them in a way that they are able to resolve real holistic challenges (you might call it cross-functional)
• let them use their creative potential by not giving them only tasks - but challenges (maybe a Product Owner that writes some demanding and sufficiently unclear User Stories)
• let them really self-organize and find the best local process to resolve those challenges
• let them evolve as a team (and not only a bunch of individuals) - e.g. have carreer paths for teams
• tell them clearly what they are responsible for and what not
• give them some useful coaching (e.g. a ScrumMaster)

You might now say: Hey, that sounds like I should do Scrum with my teams. But the bad news is: Scrum is only a process and might probably help you to identify the problem of an underperforming team. But it will not solve your problems. Besides this, Scrum has the disadvantage to introduce the roles ScrumMaster and Product Owner, which empirically draw to much attention away from the teams.

So - don't wait! Not for Scrum and not for any other useful or useless framework. Start tomorrow and seek ways to EMPOWER YOUR TEAMS!


Disclaimer: I love Scrum! It is the best framework for software development I have seen so far. The roles Product Owner and ScrumMaster are very essential and useful roles and in my opinion absolutely necessary. Nevertheless you should never forget, that the ultimate goal should always be to deliver a great product - which lays in the hands of the team in great parts!

Does Stoos Need a Manifesto?

Summary of a Stoos Stampede session, jointly facilitated by Steffen Lentz and my humble self.


Since Stoos was kicked off in January I had several discussions on this topic with different people. A question, that always arose was, why the initial Stoos21 did not come up with a manifestiish kind of document to make a bold statement on the mission of Stoos.

Now you cannot say, that the Stoos21 did not come up with anything. There is at least a description of the targeted problem and a vague idea how a different szenario could look like on the main page of the Stoos network. Additionally there is the clear message, that Stoos' intention is to change the world:

We are trying to change the world

Given the fact, that 21 people (mostly strangers) had only two days to come together, introduce each other, set up an atmosphere of trust and respect, this result is not bad! Still, to me - and most of the people I discussed with - there was a very central questions left open:

What exactly is the mission and vision of the Stoos network?

To address this question, I proposed the session "Does Stoos Need a Manifesto?" at the Stoos Stampede 2012. At the Stampede Steffen and I decided to join his session "Pitches and Propositions" and mine, since we seemed to have similar targets.

What happened at this session?


The somewhat provocative title of the session worked out nicely and some interested people came together. Steffen already described his view on the session and the participants at the StoosXChange-Wiki.

The discussion was really interesting and very clarifying! Initially some of the participants wanted to agree on a common set of values for the Stoos network, which was kind of obvious since there were certain values mentioned in nearly every session. But the attending Stoos21 participants resisted this move by explaining, that Stoos is not about values, but about "finding different ways" and that those ways can be different for every single organization. It became clear fastly, that this was a point accepted by all participants and that a manifesto would definitely not be the right way to express this.

But after approximately 30 minutes of discussion everybody in the room felt, that there was something missing. That the mission of Stoos could be made more concrete without commiting on certain values. The key common elements were: "finding a better way", "we believe in people and bring them together", "we want to create epiphany/enlightment moments and learning opportunities", and this should happen by "self-organization", which needs a certain container.

Result of the "Manifesto"-session

I will try to summarize my current understanding of the Stoos mission in short:

We believe in people and their potential! We bring them together to create epiphany moments and learning opportunities. Together we will find different and better ways to manage our organizations.

Does not fit into one tweet, thus there will probably still be a lot of work to do ;-). I am curious if there will pop up other views besides this and this (nice video!) in the next days and if a clear mission will be articulated.

Staying tuned :-)

Thanks to all participants! This was clearly one of the epiphany moments at the Stoos Stampede for me!

Update: Peter blogged about this session at his blog.

Update 2: Steffen blogged about the topic here.

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.