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 also did...

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 are 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 it first feels 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?

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

To unwrap that it, of course, means that you need to have your code,...

My current client, Spotify, is really on the forefront when it comes to good, solid engineering practices. There are inventors, leaders and all-around great people wherever 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 realized 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 a...

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

This is the last post on my top 5 ways of making sure that your agile change initiative succeeds. Here’s the list - in order of importance:

1. Get a great “Or else”-reason for doing this change
2. Sit together
3. Let them change how they work
4. Support the initiative
5. Use visualized data to improve (this post)

5 - Use visualized data to improve

If there’s one thing that I’ve seen teams really get an aha-experience from, it’s visualizing. Simple stuff - just putting your work items on a board, having to talk about how your process actually is laid out or putting a little picture of yourself on every item you’re currently working on. Things like that.

But lately I’ve also been addicted to having data as the basis of changes. Quite often we seem to change based on what we feel is...

This is the second post on my top 5 ways of making sure that your agile change initiative succeeds. But this is not ideas made up in my head (MY GOD - the horrors…) but things that I’ve tried and failed miserably with. Over and over. And learned a lot from.

This is the list - in order of importance:

1. Get a great “Or else”-reason for doing this change
2. Sit together
3. Let them change how they work
4. Support the initiative (this post)
5. Use visualized data to improve

4 - Support the initiative

This should be a no-brainer but once you see it in action it’s seldom handled correctly.

If you want to change how people act and work you have to be a role model for that, supporting the new ways. This means that the change must start with management. Yes -...

This is the third post on my top 5 ways of making sure that your agile change initiative succeeds.

This is the list - in order of importance:

1. Get a great “Or else”-reason for doing this change
2. Sit together
3. Let them change how they work (this post)
4. Support the initiative
5. Use visualized data to improve

3 - Let Them Change How They Work

You need to open up and let go of the wheel. An agile transformation is, if anything, a culture shift. Towards autonomy and away from top-level steering. This should go into the agile transformation too. In effect, this means, in the words of all agile coaches, to take it to the team.

The guys that are going to live in this environment - they are the ones best equipped to know what to do about it. Hey - they...

I’m turning 40 years old today. This is a letter to Marcus 60 years old. Or maybe a new version of my 20 year old self, if I ever invent a time traveling machine.

If you’re not me you can still read it of course. But then think of that wrote this to myself. It’s pretty self-focused. Don’t think badly of me for that. Instead write one of these for yourself. Very inspiring actually!

Dear Marcus (future and past),

today 2012-10-09 you turned 40 years old. You are in a place of your life that you wouldn’t dream of and never planned to. I thought I’ll sum it up for you if you ever forget it (chances are!).

The main point is that there is not “but…” in your description. Everything is like it is and there’s no ominous but that throw it all over end.

You have Elin in your...

This is the second post on my top 5 ways of making sure that your agile change initiative succeeds. But this is not ideas made up in my head (MY GOD - the horrors…) but things that I’ve tried and failed miserably with. Over and over. And learned a lot from.

This is the list - in order of importance:

1. Get a great “Or else”-reason for doing this change
2. Sit together (this post)
3. Let them change how they work
4. Support the initiative
5. Use visualized data to improve

2 - Sit Together

Now that I’ve got your attention from the last scary post… We turn to a much much simpler thing. But it’s still super-important, entering number 2 on my top 5 change tricks.

Are you ready? Pens out? Here we go:

Sit together!

There. You read it here first. I’m...

This is a topic I rant talk about quite a lot nowadays it seems. I feel like an old LP with a scratch (just that analogy probably dates me pretty good I guess). But I do it because I see it missing from a lot of agile change initiatives, big and small. And they are then doomed to fail.

Just to be sure - I make no claim of being the inventor of this; I’ve picked it up here and there and everywhere. Not even sure where anymore. Half Lean, half agile, half right-shifting and half the Kanban Method I guess. For whatever I’ve learned I’m eternally grateful. What I’m saying is this; if anything strikes you as good it was probably invented elsewhere. If it’s bad - it’s probably me.

In this post, I wanted to quickly write down some ways of making sure that...