Cat herding – best done by cats?

Managing creative people are often compared to herding cats (link 1, link 2, link 3). And that can be a daunting task as cats are known to do mainly do what they want to do.

However this is not a blog post about the usual answers to leading creating people. As usual  I have connected som related things and got this crazy idea that I just have to share (and I hope that ranks me as one of the creative peole).

Well, leading creative people may be like herding like herding cats, which sounds stressful, and often taking part in a software development project is almost the definition of a stressfull environment.

This is a bit funny as actually research shows that owning cats have many benefits. One of the benifits are that having cats around reduces stress. Having worked from home the last couple of month I can attest to that having a cat sleeping on your desk next to your keyboard while you work has a very soothing effect that lets you concentrate on the job. And if you need a quick laugh just take 2 minutes watching a cat play with a string (not my cat, allthough one of my cats are called Arthur).

A couple of month ago, I stumbled over a refence to cat cafés. At that time I thought it funny, and was wondering if a cat café would work here in Copenhagen where I live. But recently I have thought further – what about cat offices? Would it be an improvement to an office if there was a cat or two present?

On the top of your head you will probably call the idea ridiculous but try to give it some more thought. Cats are very clean animals and they sleep 60-70% of the day, and are generally not hard to keep. It is a very little expense and that could easy be recovered if they help create a less stressfull enviroment with a less negative mood that increases the productivity.

I am not saying this is an idea that will work for everybody – perhaps it will only work for a few – but on the othe I hand I do believe it should not be completely written off either.

Do any of you know offices where they keep cats? Then please leave a message in the comments.

The user is never right

The user/customer is never right – at least when it comes to designing good IT systems. This might seem like a odd statement to come from someone like me that thinks agile is great. Because agile places a lot of weight on commucation and customer collaboration, and most agile methods uses user stories or use cases as their basis for development. And if we base our design on user stories they must be correct, right?

Well, sorta but not quite. In the recent massive amounts of articles about Steve Jobs that have appeared after his death I came upon this qoute: ”You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.". I know from personal experience that this is often the way customers act when you present somenthing to them. There is always changes or imperfections, or their problems and processes have changes. I am sure many other developers out there know the feeling.

So if we do not trust the user/customer to supply us with what to do, should we then just do what is awesome? Well, that often do not work either. I found this qoute in a blogfrom CCP about the problems they face when developing (they use Scrum): ”..when we start off with an awesome idea rather than an actual problem we want to fix or a feature that has a clear, functional and necessary goal, it generally requires painful fixes further down the road”.

Does that leave us with a catch-22 problem? We can't rely on customers and we can't rely on what we find awesome.

No – we actually have all the tools needed in agile thinking. As I see it much of the agile way if thinking is based on that the user never really know what they want. We – the developers – need to help them. So lets look at it that way.

First – as agile developers we are always ready to respond to change over following a plan. We know we can not trust the user/customer to know exactly what he wants, so we make short iterations and continiously deliver stuff to the user, so he can see if he can use what we have made – if the system solves his problems.

Secondly we collaborates with the user/customer. This is usually done by frequent interactions with the user/customer to build trust between them and us – we need them to trust that we understand their problems and that we will deliver something that helps them.

Which leads me back to user stories and the qoute from the CCP blog. User stories is a great tool if used correctly. They are however not requirements. They are a tool that facilitates communication with the user/customer, and grounds our – the developers - understanding of their problem. It is not the solution to the problem – the solution is experessed in deployable code that solves the problem.

When we look at the standard template for a user story (*) it has often struck me, both as a developer and business analyst, how often the last part is omitted – the benefit. But that is crucial for understanding the problem that we want to solve. It is the benefit that creates value not the action. So I find that the trick to creating a good solution is to focus on the benefit and how to achieve that and not so much on the action. If we can find a better/faster/smarter action that achieves the same goal surely we will deliver value. But if we assume that the user/customer is right, we often focuses on the action – which is usually also easier, but also leads us much more in the direction to focus on contract negotiation instead of customer collaboration – afterall the system can do all the required actions, right?

In my experience it is the projects that take user/customer inputs as absolute requirements that fail – at least in delivering value. The ones that succeed is the ones where the developer solve the user/customers problem often using novel technology or solutions that the user/customer did not think of. So the user is never right – but neither is you – but that does not matter if you have a little faith and trust in each other and look at the problem and what creates value.

(*) "As a <role>, I want <goal/desire> so that <benefit>" 

Poetic simplicity

"If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea. ”

                                                   - Antoine de Saint Exupéry

Since I first saw this qoute a few years ago I have had a piece of paper with it in large letters hanging by my desk. I find that it captures the the way that I the best way to develop somehting and that it also catches the essence of agile. Essentially I read it as saying, that if you can create a shared vision in your team and get everybody passionate about reaching the goal, then the team will self-organize and use all their enegy to reach that goal.

I have long wanted to write about this quote but each time found that I extracted more and more meaning and the post got longer and longer and still did not really catch the spirit of the qoute. So today I realised that perhaps I should do it the other way around. Because the qoute is short and simple and yet expresses so much, lets just keep it simple and remember that agile is about simplicity and that sometimes less is more.

This qoute has helped me a lot when both planning and executing a project – I hope it will help you to.

When you have to code … code! Don't document.

The inspiration for this blog post has very different roots. I have for a long time wanted to write a blog post about the ”working software over documentation” part of theagile manisfesto but could not find a good way to write a blog about it. And then suddenly a podcast I heard yesterday, a book I read last week and and qoute from a movie from 1966 made it all clear: It's all about getting things done.

Yesterday I was listening to the danish tech podcast Harddisken where they had visited the startup weekend  and talked to several of the participants. One of the participants was asked if he was not afraid that once you had told people about your idea in a public forum like the startup weekend that it would be copied by other people and diluted. And he said no – the idea is not the important part – it's about making it happen and that require the correct team – and the startup weekend was a good place to meet smart people that you could recruit for your team. An idea has no value in itself – it is the execution that matters.

Last weekend I stumbled over a book by Joel Spolsky called: ”Smart & get things done”. It adresses how to hire the best programmers which is something that has been a problem in all the companies I have worked at so I eagerly read through it. The thing that is interesting for this blog post is that it is not enough to hire smart people – you have to hire smart people that get things done. Again an emphasis on execution.

The last thing is this scene from the film: ”The good, the bad, and the ugly”. I have had it on my list of stuff that I felt embodied agile and leans pragmatic approach to making software, but could not fit it in. But the other two things put it into context. So when Tuco in the film says: ”If you want to shoot .. shoot! Don't talk.” he is in a way saying that ideas and intentions do not really matter if they are not executed.

And that leads me back to the agilemanisfesto and ”Working software over comprehensive documentation”. This part of the manisfesto is for me all about execution. Beacuse while some documentation is necessary the documentation in itself holds no value – only the working code holds value – and you could probably even expand that to that only working deployed code holds any value. And getting the code done and deployed to the customer that is all about execution. You can have endless good ideas, make tons of documentation but without execution you have no value. And to me that pragmatic getting things done is one of the things that have always attracted me to agile and lean methods, and I find that valuing working software over comprehensive documentation is a good hands on approach to gettngs things done.

So remember: When you have to code … code! Don't document.

Why is it good to fail fast?

The concept of failing fast seems to be part of much agile and lean thinking. However the concept is not in the agile manifesto nor the principles behind it. Traditionally failing is not seen as something good so that got me wondering why agile think it is good and if there is both a right way and a wrong way to fail fast?

In agile we do want to be able to respond quickly to changes and most agile methods (1) prefer short iterations and it is also one of the guinding principles that we should deliver software frequently. The reason we want short iterations is so we can quickly get feedback, and respond accordingly.

But failing fast is not just something related to iterations and feedback – failing fast has also become somehting to strive for in the daily work and coding. For example in this article by Jim Shore he tells about failing fast in code and how that can help you debug faster and build more robust code.

However if I was to tell a team to fail fast and gave them Jims article as an example, it could still easily be viewed as one one to solve a particular problem and not an explanation of why it is generally good to fail fast.

Reading the article something else hit me when Jim starts to talk of assertions, how and when to put them in your code, and how to structure the message that you want the assertion to give. Perhaps it is not the failing fast that is important, it is the fact the we get good information about a problem early on – or in other words: we get structured feedback that lets us act on it.

That harmonises very good with this article by Braden Kelley that I found while researching why failing fast is good. The authors advocate that the central question you should always as yourself when experimenting is: ”What do we hope to learn from this effort?”. And I think that is the same that Jims does with his assertions – he only inserts them when he can learn something significant from them, and uses a lot of time structruring the information he gets back – i.e. he thinks about what he hope to learn from inserting the assertion at precisely that place.

So to me ”fail fast” cannot be seen as a meme in itself – it has to be put into a context and serve a purpose before it becomes valuable. Failing is just one outcome of an experiment and unless you have procedures in place to learn form it (like the Deming circle: Plan-Do-Check-Act) or it holds no value.

Being a language oriented person I agree with Braden Kelley that failing is a negative word, and since what we really want people to do when we say fail fast is learn fast, why not just say that: ”Learn fast”. To me that much better catches the thinking behind agile and lean than fail fast.

1. I say most because I do not know all agile methods out there. However all the ones I know prefer short iterations.

What playing games can teach us about organizing work

I have for some time been thinking of doing a series of blog posts that focus on what we as software developers can learn from other parts of life to make us better at developing software. And this is the first go at that.

I have always been playing a lot of games – both board games and computer games – partly because it is fun and partly because you can learn a lot from most games. For the last couple of years, I have primarily been playing a game called EVE Online. And it was when reading one of their blogs on how they plan to develop the game, that a particular part struck me as more universally appliable than just for having fun in a game.

The blog post is part of their design effort for how to improve the game and when I read this quote I immediately thought it had wider appeal than just in a game:

Maximize "can", minimize "must"

• Nullsec features should always maximize the amount of valuable options available to the player, and minimize the number of mandatory tasks they must complete
• Nullsec features should always encourage players to solve their own problems rather than using mechanics to regulate things

EVE Online is what they call a sandbox game where everything (almost) is player built or player interactable and Nullsec is the most deregulated part of the game and hence both the most dangerous but to many also the most fun part of the game.

However what struck me was that changing a few words in that statement will change it from speaking of how to enjoy a game to speak of a way that we can organize work that must strike most people in software development – especially if you are using lean or agile methods – as something to strive for:

• The way work is organised should always maximize the amount of valuable options available to the employee and the business, and minimize the number of mandatory tasks they must complete
• The way work is organised should always encourage employees to solve their own problems rather than using rules to regulate things

I think that Maximize "can", minimize "must" is a good meme - It is certainly one that I will use in the future, because I think it is a good way to quickly expess the gist of these priciples from the agile manifesto:

Build projects around motivated individuals.  Give them the environment and support they need,
and trust them to get the job done.

Simplicity--the art of maximizing the amount of work not done--is essential.

So one of the lessons I think we can draw from playing games, is that work get more fun and rewarding if we can maximise ”can” and minimise ”must”. This might not work in all companies but I feel that in software development where creativity and innovation is essential to make a good product this is the vision I would like managers to have in a company I work in. And I do not think I am the only one that work harder, longer and get better results if I find the work to be fun and rewarding in itself (read my earlier blog post on motivation here and here).

Agile vs Lean startup - is there a conflict?

Check out Todds blog post about it. I agree with Todd that there should be no conflict between the two, and I find that trying to say one is better than the other, is a sign that you have not understood neither agile nor lean.

However Todd might be over reacting, as when I read the blog post from Abby Fichter and listen to the video in the blog post, it is really about how we can improve agile. And that is a very agile mindset.

Perhaps it just boils down to words - perhaps lean startup is not better but just different and another way to adress the problems that agile adresses. In which case it is just a case that we need to communicate more about it and try to understand what the other side means and not try to defend ours as the best - we can probably learn something even if we do not adopt it.

What are the best personalities for an agile team?

A discussion in one of the groups am I am member of in LinkedIn asked the question – specifically which of the Briggs-Myers personality types fits best.

This off course got me thinking. First I tried a test myself so I knew what type I was myself, and if that fitted both the role I have filled on agile teams (product owner) and agile thinking in general. It turned out that I was an INTJ which means that I am Introverted iNtuitive Thinking Judging. Having an INTJ personality as a product owner is probably is probably a good fit, as evidenced by this qoute: ”INTJs are known as the "Systems Builders" of the types, perhaps in part because they possess the unusual trait combination of imagination and reliability.”.

Then I turned to look at if it possible to determine if there is a single or range of characterics that fit agile thinking better then others. But I actually could not find any. Is it easier for an extrovert than introvert to think in agile terms? Is a judging personality worse at agile than a perceiving?

If we look at the agile manifesto, there is probably a good chance, that an extrovert would be better at having people and interactions come before processes and tools – and a thinking personality worse at selecting working code over documentation. But with four dictomies the Briggs-Meyers personalities have sixteen different outcomes and when I read them they all have some advantages that could be useful on an agile team.

Thats when I remembered that behind the agile manifesto there are 12 guiding principles and 3 of them are about teams (see below). Agile thinking is very team oriented. And normally you would look for a synergistic effect of a team where the whole is more then the sum of the component parts. This often require different personalities that supplement each other. A team of 5 masterminds like me (the INTJ type is called the mastermind in the Keirsey temperaments sorter) would probably not make as good a team as a team with 5 different types.

This has lead me to the conclusion, that there are no best personalities for agile thinking or teams. It will probably be a good idea not to have opposite personality types on the same team, as they might disrupt the team, unless there is also a mediator type that can talk to both of them. The Briggs-Myers personalities can be used a tool when you select your team, but you have to remember that as with any other tool individuals and interactions comes before tools and processes.

---
The 3 guiding principles about teams in the agile manifesto are:

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The best architectures, requirements, and designs emerge from self-organizing teams.

Intrinsically or extrinsically motivated - that is the question

I just took this test that Daniel Pink has made to see if you are more intrinsically (Type I) motivated or extrinsically (Type X) motivated. To my surpise I was mostly Type X. I have never seen myself as extrinsically motivated as I have always had a focus on having fun doing my job and helping others..

The definitions of the behaviors are:

Type I behavior: A way of thinking and an approach to life built around intrinsic, rather than extrinsic, motivators. It is powered by our innate need to direct our own lives, to learn and create new things, and to do better by ourselves and our world.

Type X behavior: Behavior that is fueled more by extrinsic desires than intrinsic ones and that concerns itself less with the inherent satisfaction of an activity and more with the external rewards to which that activity leads.

However I had answered truthfully on all the questions including the questions that concerned the work I have been doing until a month ago. And it struck me, that the answers to these questions where not all as I wanted them, but was dictated by the job and the company I worked at. So I took the test again, answering all questions as if the job I had now was my dream job and everything was as I wanted it. And even though I only changed my answers to about a thrid of the questions, it now deemed me a Type I.

I recommend to take the test – but remember that if you get another result than you expext it might be because of things you do not control at the moment or in your current job.

Are you an agile robot?

I had this sort of revelation when I read Neil Strauss's ”The Game” last week. The book is about the community that exist on the net that relates to pick-up artists and how to seduce women. The particular thing that caught in my mind was a short post he had made called ”Are you social robots?” on a seduction forum  (step 8: chapter 10 in the book). It describes how some people becomes social robots – defined as someone who knows all the theory and has the rotines and methods trained to perfection, but uses all their time solely on this – the routines and methods – they have no other interests and therefore often fail when they run out of material (hence social robots – if they have no program for it they do not know how to react).

This made me think because both from personal experience, from talking to people at conferences and reading about how to introduce agile methods in a company and how it oftens fails, I think that it is because systems thinking leads people to become agile robots instead og agile humans. People get caught up in this athing and says: ”OK - how do you do it? Where is the checklist?”, and then get caught up in the thousands of different agile methods out there and tries to implement them all or try to find the best practices out there and then introduce them.

This in itself is not bad – but it can become bad if you concentrate to much on the methods and routines and forget the first statement in the agile manifesto: ”Individuals and interactions over processes and tools”. And there you have to remember that any method or tools – even if it is an agile method or tool – is just that – a tool – something that you can use to faciliate interaction, but holds no value in itself – you need to add something yourself be it creativity, mastery of analysis and design or just plain old common sense to create value. If you can only follow the agile methods, run the routines, then you are an agile robot. And you are likely to fail if your project hit something unexpected that there are no routines for.

I have tried below to ask a couple of questions that you should ask yourself to find out if you are an agile robot. If you answer yes to all or most of these questions, you are most likely an agile robot. This is by no measure a complete list so feel free to add more questions in the comments, if you have observed other signs of people becoming agile robots. I will myself try to revise and update the list in the coming months.

1. Have you stopped reading books and articles that are not about agile methods?
2. Is your reaction to something unexpected to search the net for a new method that handles it?
3. Are you unable to talk about a story without first asking how many story points it is?
4. Is your backlog your bible where everything holds true now and forever?
5. Do you always use an estimation technique (e.g. planningpoker) to get estimates?
6. Is producing and updating your burndown chart the most important thing?

Don't become an agile robots - remember that there is more to mastering development and delivering value to customers than mastering agile methods and techniques.

By the way – Neils book is in itself a good book and well worth a read. Allthough it describes the rise and fall of a particular subculure, the questions it raises can be used on other subcultures and my claim is that the agile community is sort of a subculcure. And much of todays society is riddled with different subcultures of which most of us are members og at least 1 or 2 if not more.

2 for the price of 1!

Looking for a new job has made me think a lot about what motivates me and how I can motivate other people and how I like to be motivated myself. So being a person that likes to read, I of course read a couple of books about it. And although they are written more than 25 years apart I find that they have very much the same message at their root. Since I find the two books very good I thought I'd share them with you and write a short review of them.

The first book I had actually read before – several times. I originally found it on my parents bookshelf about 10 years ago when I had just started abakion with a 6 former co-workers and was looking for information about how to lead a company. I found it so inspiring I tend to reread it every 3-5 years just to remind myself of how easy leadership can be if done right. It is called “the one minute manager”.

The thing about the book is that although it is about management and leadership It is not a traditional textbook on how to become a good manager. Instead it is a tale of a young man looking to become a good manager and how he discovers what it means as he speaks to a manager and the people that he manages. As it turns out you just need to understand and do 3 things to be a good (1-minute) manager:

1. Give 1 minute Goals
2. Give 1 minute Praisings
3. Give 1 Minute Reprimands

The basic idea is to give your employees simple but clear goals – they must not be more than 250 words and be able to be explained in a minute. Then try to catch them doing something right (i.e. getting closer to the goal), and then immediately praise them and give them feedback. Only if they are clearly not doing the right thing – i.e. getting closer to the goal do you reprimand them and then

your reprimand is targeted clearly at the work they do and not the person, again with clear feedback.

The book is so good because it promotes very simple ideas and do it in a way that lets you discover them and why they are good along with the storyteller – it becomes your own personal discovery. It also give you a very simple (you could even say a 1 minute) check-list of how to be a good manager so it is very easy to act on in the real world.

Probably the best thing about the book is that is is very positive – I love this quote they have: “Everyone is a potential winner – Some people are disguised as losers – Don't let their appearances fool you”.

The second book I read is “Drive – the surprising truth about what motivates us”. I read this because almost all the speakers that talked about agile development at the GOTO conference in May in Copenhagen recommended it and cited it as an inspiration. Furthermore I had seen this very good animated short version of the book and found that it resonated well with how I think. But 10 minutes of video is just an appetizer so I wanted to read the whole book to get deeper into the material.

And I was not disappointed. What I found good about this book, is that it seems to make explicit all the tacit knowledge that I have myself accumulated our the past 10-15 years working as a consultant and product owner on what motivates me and what I have seen work when I have tried to motivate others.

The books basic tenet is that command and control oriented way with extrinsic rewards as the prime motivators that has been the standard for managing businesses the last couple of hundred years is out of date. In a work environment where problem solving and creativity is the norm, extrinsic motivators actually is detrimental to good performance. And the book backs it up with solid scientific studies.

If you want to get good performance from your employees in the creative and constantly changing environment most businesses find themselves in these days, the best way to do it is if they are intrinsically motivated – i.e. they want to do a good job themselves. And the way to that is to let them solve tasks they way they want to, allow them to get better at it, and make it clear why the tasks is important. He sums it up in these three words:

• Autonomy – the desire to direct tour own lives
• Mastery – the urge to get better at something that matters
• Purpose – the yearning to do what we do in service of something large than ourselves

The book is packed with references to studies that prove what it says. And at the end there is a couple of chapters with a tool-kit, that helps you transform yourself and your business to use intrinsic motivators to get better results.

In the start of this blog post I wrote that I find both books have the same message at their root. And that is that at the core of good leadership is the fact that I is all about people and caring for people. If you trust in people to get things done they rarely let you down if you can convey that you trust them to do it themselves.

By giving people a 1 minute goal you give them both ample autonomy to solve it and at the same time give them the purpose of the tasks because 1 minutes goals are something that is agreed on between the employee and the manager. And because both minute praisings and minute reprimands concerns feedback on how well or how bad the job is done it does not comprise autonomy and helps the employee towards mastery.

If there is only one thing I could change it the “Drive” book, it would be to add “the one minute manager” to the fifteen essential books list it contains. Apart form that both books are both easy to read and have a very important message for everybody. I highly recommend both of them to any manager that wants to know how to become a leader and improve the results of both his own work and that of the company he works for.

Getting there the Columbus way

As noted in my earlier post I want to use this blog to talk about different themes in a essay like format. And since I am very interested in agile development, I want to explore the 4 statements of the agile manifesto, and talk about what each of the statements mean to me and my view on software development.

The agile manifesto goes like this:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on 

the right, we value the items on the left more.

The one I want to talk about today is the last one – Responding to change over following a plan. There are two reasons that:

Firstly I think responding to changes is what makes agile methods agile in the original sense of the word agile – i.e. someone that can move quickly and well-coordinated. The other 3 statements are enablers that allow us to reach the goal of being able to respond quickly to changes – changes that experience has taught will always be there in any software development project.

The second reason is much more simple – it is the easiest one to write about and I have a couple of good ideas of how to explain my view on it. So in the agile spirit I choose to get something out there fast, so I can get feedback early.

I called this post: “Getting there the Columbus way” because when thinking of planning I always remember a little story, that a speaker told at an AIESEC meeting many years ago. I cannot remember his name, but I think it in a very simple way explains why responding to change over following a plan is a good thing.

To get somewhere in a ship there are essentially three ways to navigate – they are

• The Viking way
• The Titanic way
• The Columbus way

The Viking way of navigating is to drop 40 vikings and a priest in a boat, and pray that you get where you want to go and that there is something to loot when you get there.

The Titanic way of navigating is to have so much certainty that nothing can go wrong, that you will lay your course in a straight line to the target and not deviate from it, since you KNOW it is the fastest way to get to the target.

The Columbus way of navigating is to have a clear goal of where you are going, but knowing that the way is uncharted and may have hidden dangers, you prepare well and bring 3 ships. And you are smart enough to realise that when you miss your original goal of finding a new way to India, there is probably a buck or two to be made from this new continent you found.

I also find that the Columbus way fits well with another of my favourite quotes about planning:

“Plans are nothing. Planning is everything”

Dwight D. Eisenhower

The core of this quote is that once the plan is made, it holds no value in itself. The value lies in the planning that has been done. In the planning phase you have explored the goals you want to reach, and the capabilities you have at hand to reach them. And you have tried to come up with the best solutions to reach the goal given the capabilities you have. Knowing where we want to go and what capabilities we have is exactly what we need when something changes and we have to respond fast.

If the goals changes you know your capabilities and can quickly assess if the new goals can be reached with the assets at hand. If your capabilities change you can quickly determine if it is still possible to reach your goals with your current assets.

So in an agile world planning is performed so you know your capabilities, which in turn allows you to act fast when facing new situations. This is very much in line with the statement in the agile manifesto, that we value responding to change over following a plan. Note that it is the following a plan that is not valued in the agile manifesto - not planning itself.

And planing itself is indeed an important part of most agile methods. In most agile methods planning is something you do every iteration because you know the world has changed since yesterday, and will probably change again tomorrow, so in order to be prepared, to be able to be agile, good planning is essential. If find the backlog in SCRUM (link) a prime example of that as it is ever changing and improving, yet at any given time you are aware what is the most important goal.

This is in contrast to older methods, particularly the waterfall method, and which I based on my little story to start with will call the Titanic methods. Titanic methods tries to eliminate risk while Columbus methods tries to take them into account and navigate around them.

To sum up my view on planning and responding to change is that you have to remember:

Plans do not give you certainty, but planning allows you to act faster and more decisively in an uncertain world.

So when you are going to start a project next time which way do you want to go – the Viking, the Titanic or the Columbus way? For me there is no doubt – I'll take the Columbus way.

A short comment on language

Why does a Danish guy like me write a blog in English? Well this is something I thought about when I decided to start a blog. In the end it came down to English simply because that will give me a much bigger potential audience. And the fact that I already have friends that do not speak or read Danish and I really do not want to exclude them from reading the blog. Oh – and when writing about software development there is simply a lot of expressions and terms that are not translatable into Danish anyway.

If this blog becomes a succes I will consider starting a “shadow” blog, where I can post the blog entries in Danish as well, but right now that is a project for the future.

Common sense or your money back

When I was thinking about what to call my blog I quickly realised that the words “common sense” had to be part of it. Because that is what I hope to write a lot about – what I think is common sense and the lack of common sense often displayed by people I have met, or read or heard about in the media.

I added the “or your money back” primarily because it sounded fun, but also because I think that actions where there is something at stake is much more interesting. I am going to write about things that I find interesting and have a passion about. So the “or your money back” part is an invitation to all readers to comment on what I write whether they agree or disagree that it is common sense.

However If you are looking for a blog where an angry man that rants about stupid people, I will probably disappoint you. I plan to make this blog a series of essay's on different subjects that interest me like both professionally, like software development, and in my spare time, particularly gaming. And I hope that once I an while I can inject something about life and common sense in general.

First post!

So why am I writing a blog and why should you read it?

Well the answer to the first question is easy – I both hope to learn something and I think it will be a lot of fun. I have found that when I need to think about something it often helps to write it down. It clarifies my thinking, often leads to new insights and allows me to revisit my thoughts a couple of days later which often again leads to new insights.

So why put my thoughts on a blog? Well my experience tells me, that sharing thoughts with others and getting feedback on it makes for a better learning experience. And since blogging has become so easy to do, it is actually the easiest way to share small insights,experiences and other random stuff that pops up and that I find interesting.

The other question is far more difficult to answer – why should you read my blog? Well, at the moment I cannot give you a straight answer. I just hope that you will find what I write interesting and comment on it. And I hope you can learn something that way as well.

I am looking forward to writing this blog – and I hope that you, the readers, will enjoy it as much as I do.