Continuous Delivery, Uncategorized

Continuous Discussions – Metrics That Matter

On January 26th I participated in an online panel on the subject of Measuring DevOps, as part of Continuous

Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery and DevOps. Watch

a recording of the panel:

Continuous Discussions is a community initiative by Electric Cloud, which powers Continuous Delivery at businesses like SpaceX, Cisco, GE and E*TRADE by automating their build, test and deployment processes.

I felt that the atmosphere in the webinar was nice and friendly. The other panelists were knowledgable and nice to talk with, that goes for the hosts too, who facilitated the discussion in a very professional way.

Continue reading

Agile, Change, Continuous Delivery, Uncategorized

Simplicity Will Improve Your Team Effectiveness

Maintaining focus can be hard when developing software. There are a bunch of things that has the ability to steal our attention during a day. Mail, meetings, other projects etc. Over the last months we have found that keeping things simple, and not waste time on stuff that we believe don’t give us any value. So we have the following principle:

“Don’t introduce things you don’t need”

From a technical perspective we always try to keep things as simple as possible. We therefore have:

  • No branches
  • No un-necessary libraries


We also try to delay architectural decisions, keeping options open as long as possible. But more on that in a later post. Lets get back to avoiding branches and libraries.

No branches

If you are doing continous delivery, having no branches is a key element. But sometimes this is easier said than done. At one point we were about to introduce a more complex branching strategy. The reason ? We had a couple of incidents where defects were introduced in production, we released code that weren’t ready for production. So we gathered around our desks and started to discuss a branching strategy. As the discussion progressed we started to get a bad feeling. Things were starting to get complex. The concern was raised, and since we all really prefer to keep things as simple as possible we decided to look deeper. Was the no branching strategy really the problem ? Looking at how the work flows it became evident that the problem was that we didn’t really follow our own process (our Kanban board had a separate testing phase, where all our features need to pass an acceptance test). So instead of complex branching strategy, we agreed that we needed to improve our own testing:.

No unnecessary libraries

From the beginning the team has really done it’s best to keep our architecture and code as simple as possible. Whenever someone wants to bring a library, one of us put the “sceptic hat” on and asks: “Do we really need this?”. As a consequence, our code is still quite simple with reasonable few external dependencies. This makes our software easier to maintain and we can move faster when writing new features. The same goes for architecture (more on that later).

But it’s not only from a technical perspective we have valued simplicity. From the very start we have tried to create as little process as necessary, letting the process grow as we learned. The focus for the team should be to write working software that solves a business needs. Everything else should help the team accomplishing that. If it doesn’t provide any value, we simply don’t do it. Thus, we have:

  • No (un-necessary) meetings
  • No emails
  • No estimates
  • No testers

More details about keeping your processes simple in later posts.


From IT to Product Mindset

Two weeks ago we started an experiment to test out how we can improve lead times of new features for one of our customer facing teams.


The team is responsible for three customer facing channels and publish new content on a regular basis to the different channels. There are no developers on the team, so for more complex changes they are dependant on developers working off-site. The process for developing new features have many hand-overs. As a consequence, the following problems occur:

  • Long lead times
  • Poor quality

In 2015 this represents a problem when you need to react to changing customer needs. Currently, there is a thick wall between the business side and the IT-department, which I believe is the root cause of the many handovers.
Continue reading


My first post in a veery long time

It’s been quite a while since my last blog post. 2014 was a busy year, with both ups and downs, with a lot of learning atteched to it. Sometimes things don’t go quite as planned, that was certainly the case for a few things last year. Well, it’s a new year with lots of new possibilites. One of the things I will like to improve in my work is to become better at saying no. Being an optimistic guy, I realize that this can be hard.

Continue reading


Announcing First Speaker At DareFest Oslo 2014

joakim_sundenWe are happy to announce that Joakim Sundén, agile coach at Spotify, will speak at Dare Oslo 2014. If you are interested in learning more about how Spotify manages to stay lean while having rapid growth in a n extremely tough and competitive market, then you should come listen to Joakims  story from Spotify.

Joakim is a frequent speaker at conferences around the world and an important contributor to the community. In 2013 he spoke at several big conferences like Agile 2013 and Lean Kanban North America, sharing the story of how Spotify manages to stay lean through rapid growth

This February will also see the release of Joakim’s book, Kanban in Action, which he has written together with Marcus Hammarberg. It’s based on the real-world experience and observations from two kanban coaches who have introduced this process to dozens of teams.


Step Out of Your Comfort Zone

Since I started my own business almost 2 years ago I have been way outside my own comfort on numerous occasions. Being your own boss gives you a lot of freedom. Freedom to do things you like. Freedom to try new things. When you try new things there is a good chance that you are stepping out of your own comfort zone.   
“Before every breakthrough there is a moment of uncomfortableness” – Christopher Avery. 
Sometimes that moment is short, sometimes it’s longer. I will probably never stop feeling uncomfortable when moving down an unclear foggy road. I have come to the realization that this is something I have to live with, that feeling uncomfortable in situations where you let go of control, is in fact quite normal. So over the last couple of year I’ve become better at recognizing this feeling, which makes it easier to deal with.  
From time to time I’ve asked myself why I get into these uncomfortable situations. After all, feeling comfortable, cruising on what you already know and already know how to do, is convenient and easy. When this gets too tempting I try to return to my “why”, to remind myself of why I’m doing this: Helping myself and other people/organizations improve. To improve you need to change. To change you need to do something new. 
So I’ve done it again. Something I believe in and think will be very cool, will be announced this coming week. Over the next 7 or 8 months I’m sure I will find myself way out of my comfort zone on many occasions. Our mission? To help other people step out of their comfort zones, dare to try new things and by that; help both themselves and their organizations change into something better.
Today Dare Festival was launched. It gives a nice short overview of what to expect. There is more to come. Watch out for some announcements the next couple of weeks 🙂