I do!!

If you look up ‘Self-fulfilling prophecy’ at Wikipedia you will find:

The self-fulfilling prophecy is, in the beginning, a false definition of the situation evoking a new behavior which makes the original false conception come ‘true’.

So if you think you will fail a test because for example you are simply not good at math, chances are you will fail that test!
Often we associate a self-fulfilling prophecy with negative events, but why wouldn’t we use it to make something positive happening?

Just last week I had a problem to solve where I had a hard time finding the right solution. I had tried things that didn’t work and was kind of stuck. Then I decided to do something different. Not looking at the past or even the present, but at the future! I suddenly ‘knew’ what the solution would be and what was going to happen. Instead of thinking how I would get there I just kept that feeling and I wrote down what would happen. Just ‘seeing’ it is probably fine too, for me it works best if I write it down. In this case I wrote an e-mail and actually sent it to somebody ‘telling them what happened even before it happened’.
As with a true self-fulfilling prophecy it worked! The beginning of the solution is already there. I am going to succeed with this! I know it; I have seen it with my own eyes 😉

So next time you have a problem that you can’t seem to solve, try this. Write yourself a letter from a perspective of a week a month or year later, telling yourself what you have done to solve the problem. Make it as real as possible, ‘see’ what you have done. Chances are you will have yourself a self-fulfilling prophecy!


One of keys to success in Agile software development is the ability to learn and embrace change in order to deliver value. This applies to both teams and individuals in that team.
In the solution focused approach we like to use resources we already have as a basis for learning and getting better at what we are doing.

Should be easy to combine these two…..

How do we find these resources? Say we have a problem and we don’t know how to solve it. Instead of looking for the cause of the problem we go looking for solutions.
The problem usually isn’t there all the time and even if it is there are times it is a bit better. Or there may have been situations where we have solved similar problems.
Often we ourselves have the knowledge to find a solution but just can’t get to it.

We can find our resources by asking questions like:
-When are things better
-What is better at those moments?
-What did I do last time?
-How did you manage to do that?

The answer can lead you to a first step in solving our problem en getting closer to our goal. I have seen this work, both for myself en with other people. It gives a real kick to see that someone only has to ask you the right questions for you to find out your solution! Besides, it is much more satisfying to implement a plan that is your own than doing what someone else told you to do!

You can ask yourself these questions or ask a (scrum) coach to help you on your way. In agile teams, team members can help each other finding the (team) resources. It would be interesting to hear what you and your team have learned by using your resources!

Besides blog posts about combining Solution Focused and Agile I would like to offer some links to both practices.
If you just Google either Solution Focused or Agile you get millions of results. Where do you start?
This is where I would like you to help me. If you are familiar with Solution Focus and you meet someone that isn’t. He or she wants to get to know some of the basics. What links would you suggest? The same question about Agile? What would you say is basic reading material?

Your nightly build breaks more often than not and you really need to fix it.

You ask one of the team members ‘Why does the build break almost every night?’ You don’t have any intention to blame him for the broken build, but what would he feel?

What if you tried using this question: ‘Just imagine it is two months on from now and we have managed to fix our nightly build. How have we done that?’

What would be the difference in these two questions. Asking the ‘Why’ and trying to find the problem or asking the ‘How?’ and focus on the solution?

With the second question there is no suggestion of blame at all so there is no need to start defending. Furthermore the second question implies that the problem is solved, so there IS a possible solution.
Last but not least, the ‘how’ sets the stage for thinking about all kinds of possible solutions. When combined with the ‘What else?’ question after every answer you are really ‘digging for gold’ in solving your problem!

So where have you been able to replace ‘Why?’, or even ‘5 Why?’ with ‘How?’

OK, “Hello World!” was not my first blog post. I wrote my first blog post a couple of weeks ago and it can be found at SOLWorld. I will re-post it here:


This post could be read as a follow up to last year’s post on by Martin van Gogh ‘R&D goes SF’ . At the end he wrote: ‘Next time: What is our goal and how are we following up?’ In this post I’ll write a bit about the following up.
Almost a year later we see more and more results from using SF in our organization. Not just in a coaching context, but in all aspects of our day to day work.
At the beginning of this year, our software development team decided to start experimenting with working ‘Agile’.
For those new to this terminology my short summary would be : 

“Working with a bunch of technical ‘best practices’ combined with more communication, listening, giving and receiving feedback, eagerness to learn together, finding your own solutions, positive goals and small iterative steps in a team”

The last part sounds familiar? That’s what I thought when starting to work in an agile way with my team!
An important part in working as an Agile team is continuous learning. For this we have a retrospective meeting once every two weeks. In this meeting we talk about what we did the last two weeks, what went well and what could be improved. For this I find the SF scaling technique very useful.

I started with a scale from 1 to 10 and asked all team members to write down a number for how well they thought these last couple of weeks went. Everybody wrote down their number and put it on the scale on a white-board. Next I asked them to write down what was already in that number and write it down on a post-it note. After this we also put these notes on the white-board and they explained what they had written. The next step was to ask them to use another post-it to write down what could be done to go one step forward for example from a six to a seven. This all gave us lots of ideas about improving the way we work and gave us individual and team goals to work on! 
To me this is just a small example of how well SF can be used in the daily work of a (profit) organizationThe learning continues, for me and my team. SF and Agile, they really work together and I’m looking forward to talking to and learning from other people who have similar experiences!

Hello World!

As a developer usually the first program you write is ‘Hello World’ so why not start my first blog post with a simple Hello World?

More soon!