Today is the last day I work for Avega Group. It’s the best place I ever worked at to date. I’ve been there for almost 8 years and see the company grow from 50 people to about 400 people.

During this time I’ve learned a lot from a lot of amazing people. I’ve grown as person and in my career to someone that I never thought that I could be. A lot of this has been due to the support Avega and all the people there have given me.

To say good bye properly I recorded a little (8 mins) movie with some memories from the Avega office that I will carry with me forever. It’s in Swedish so for all you english people (68% according to Google Analytics) I’m sorry about that, but this one goes out to my colleagues at Avega.

Today I rode the tram to work and was faced with the barbarian horde of school kids going the other way; to their school. After I had managed not be run down and falling of the tracks from them running towards the closing doors of the train, I got an image in my head.

School kids and teacher are excellent examples of command and control vs autonomy in action.

In this blog post I’ll contrast the two models of management and see if there’s any similarities with our normal working conditions.

Command and control

Imagine the whole school going to a boring outing, probably to a place the have been to many times before. To learn stuff that they are not interested in (by now you realize that this is TOTALLY made up - that would NEVER happen in real school. right :)).

For a school with, say, 500 pupils organising...

Today I’ve experience a rare thing. I went into a restaurant in Stockholm. It was a new place to me I’ve never been there before, to my knowledge. The restaurant was crowded as it was lunch hours. One by one the queue in front of me disappeared and went out the door again. So I started to realize that something wasn’t right here. Food’s out? Food’s bad? Only veggies left? When I came up to counter to order the man behind the counter let me and then said:

“The card machine has not been acting up during the last hours. Let’s see how this goes…”

Sure enough - the card machine was broken. I couldn’t pay. So I put my card back into my pocket and turned around to go. Then he said it:

“You know what … It doesn’t matter. Take a seat and we’ll bring...

I had the opportunity to do something exciting yesterday. I was invited by my good friend Tristessa to teach a class on programming for her 13-14-year olds. She teaches at the International School of the Stockholm Region and had introduced them to programming just a couple of weeks before I came.

Since the first time I learned TDD I’ve always thought that it’s a bit like thinking like a child; challenging the code, come up with more examples, try to break/understand your code and just being curious. Also - when TDD works it feels much like doing a puzzle - the next piece just comes to you in a nice way, another kid-activity. So I thought I’d try to teach them TDD during an hour and a half. We did the Fizz Buzz kata together and during the class brushed on a number of interesting subjects. They...

Sure enough… There’s an abbreviation for Continuous Delivery. It’s CD.  I think this means that it’s important :)

The last couple of days I’ve run into a lot of expressions, true-isms and problems that we take for granted that is turned a bit on their heads when looking into releasing often. And with often I mean real often - like all the time. No really I mean continuous delivering.

Yes, I know that if first feel a bit scary and unachievable  but in this blog post I’ll try to show you a couple of things that make that strive worthwhile. I think

Continuous Delivery?

| | |:————————————————————————————————:| | | | From Industrial Logic |

So the short and sweet introduction is really this; push EVERY change to your code, configuration and environment...

My current client, Spotify, is really on forefront when it comes to good, solid engineering practices. There are inventors, leaders and all around great people where ever you look. So this gig has rendered me a lot of learnings, even in the areas that I don’t touch much (being hired as an agile coach that reads coding people…).

So the first week or so heard the term “Model based testing” for the first time in my life. Investigating further I realised that it had strong similarities, technology-wise, with Specification by example. And there’s some fundamental differences in the thinking and reason behind each approach too.

In this post I’ll take a brief look to clear out the differences and similarities  I think that you can have great use for both approaches but you should probably know why or you’ll find yourself fighting the tools and process for...

Continuous delivery is something that everyone seems to be talking about these days. And it’s very cool. Put very simply you can say that it’s striving for releasing every change you do in your code base and configuration to the production environment.

This can seem like a very daunting task to take on but if you think about it, it only has to do with us taking on to much work in process. In this blog post I’ll elaborate on some thoughts around that.

Continuous delivery is not hard at all

This little conversation took place the other day when I explained continuous delivery for a colleague:

“When is the easiest day to release a system?” “Huh?” “The first day. Continuous delivery is to just keep doing that ever day”

Yeah - it’s one of those; that’s easy for you to say, but there’s a great amount of truth in there as...