Jez Humble posted a blog entry with the same title in 2010, but if you haven’t read the entry, or just want a quick explanation, here’s the short version: A continuous delivery pipeline automatically tests the application, but keeps the deployment decision as a manual step. A continuous deployment pipeline, on the other hand, will

I have had to deal with memory problems in Java applications a few times. A lot has been written about this already, but this time I ran into a slightly different issue that surprised some of my colleagues so I decided to write about it here. Contrary to popular belief, a big JVM heap size is not always better when it comes to performance.

The problem

I came to the customer site to help them with their performance problems of a fairly large J2EE-system Web Service/Hibernate/MySQL system. They had several customers running the system, but only the largest was experiencing problems. The application suddenly froze and stopped processing transactions. All sorts of hypotheses were discussed, but no one could really for sure say what the problem was. And there was little data to work on.

Continue reading

What will software development be like in the future? “Agile” as we know it, will not be around, nor will test-driven development, continuous delivery, or BDD-like methodologies. I’ve been pondering this for a while, and based on some observations and a dose of wishful thinking, I’ve arrived at the conclusion above. Do you agree?

Continue reading

It is important to collect all bugs, or TR for Trouble Report as some call it. You will learn that some of those creepy agilists have a tendancy to fix bugs immediatley instead of collecting them.

Continue reading

Continuous delivery is a hot topic. A lot of people are talking about it, but implementation in the real world is scarce. I lucked out at my last assignment when I was at SVT (Swedish Public Television) and got the chance to work on implementing a continuous delivery pipeline.

When I started, the project had delivered once and was gearing up for its second delivery. Representatives from each team met, and we decided to aim for an (at the time) aggressive schedule of one release per week! Our first “fast” release would go out in January, and we would continue from there.

It would be nice to say that this worked out well and we were continuously delivering from then on, but this blog entry is about our road to continuous delivery, so my story starts here!

Continue reading

After having worked with various legacy codebases one discovers certain recurring traits and patterns. The topic of today is the Custom Exception Hierarchy encountered in Java legacy code. This phenomenon is rather Java-specific because of that language’s checked exceptions.

So what is a Custom Exception Hierarchy? It’s an exception hierarchy, with some strangely named exception at its root, present throughout the entire codebase and used everywhere. The author(s) of such hierarchy obviously felt that exceptions like IllegalStateException or IllegalArgumentException, or the like weren’t sufficient for the sophisticated needs of their application, so they came up with a better suited hierarchy of checked exceptions.

Continue reading

Hi there, scouting the enemy, are we? This agile thing is spreading like the flu and the resources are starting to notice. Soon they’ll be out of control. We can’t have that, can we? Fret no more, this blog is here to rescue managers like you, who appreciate command and control. If you can’t win a war with a strategy, then it is not worth considering.

I will provide you with some handy tips to counter the agile movement before it gets out of hand. We don’t want to be fired, we want to be feared!

Continue reading

I gave a talk to a group of mechatronics students at KTH (Royal Institute of Technology) today. The topic was agile software development with an emphasis on Scrum, and some information about Kanban and Lean Startup. Here are the slides: KTH-2013 Get in touch via my homepage if you have questions or comments!

At Spotify we recently did full-day retrospective with 65 people. The goal was to capture learnings from a large coordinated effort involving dozens of teams for over half a year. The teams had been doing sprint retrospectives during the project, but we also felt the need to get a larger group together and look at

On Feb 7-8 Tom & Mary Poppendieck will be in Stockholm, we are running a workshop called “Lean Mindset“. Mary and Tom are only here 1-2 times per year, so this a good opportunity! The workshop emphasizes research, case studies and exercises. You will learn what a lean mindset is, how other companies have exposed

Product development isn’t easy. In fact, most product development efforts fail, and the most common reason for failure is building the wrong product.

Spotify is a Swedish lean startup with an awesome track record of product delivery. The products are designed to be easy, personal, and fun. Even Metallica, long known as die-hard opponents to music streaming services, now say that Spotify is “by far the best streaming service” and are “stunned by the ease of it”.

Here’s the paradox though: Successful companies like Spotify only want to deliver products that people love. But they don’t know if people love it until they’ve delivered it. So how do they do it?

Check out the article “How Spotify Builds Products”

Continue reading

Finns nu i bokform på Leanpub

Detta är den tredje posten i en serie om agil HR “from the trenches”.

Del 1: Continuous investment
Del 2: Lägg ner utvecklingssamtalen
Del 3: Lön är rättvis ersättning – inte belöning
Del 4: Släng titlarna
Del 5: Ny kunskap – ett gemensamt ansvar, avsnitt 1
Del 6: Hitta rätt folk – släpp dem lös

 Lön är rättvis ersättning – inte belöning

Så här är alltså läget: Vi har lagt ner utvecklingssamtalen och allt arbete sker i team där deltagarna tar gemensamt ansvar för sitt arbete och resultat. Då reser sig förstås frågan: hur sätter man lön i en sådan organisation? Ingen enskild prestation, ja, egentligen inte ens ett enskilt (synligt) ansvar finns ju att bedöma och ersätta eller belöna. Och inte heller har vi ett samtal där medarbetarna (lite i hemlighet) kan bedömas. Svårt läge.

Tyvärr är det värre än så.

Continue reading

Finns nu i bokform på Leanpub

Detta är den andra posten i en serie om agil HR “from the trenches”.

Del 1: Continuous investment
Del 2: Lägg ner utvecklingssamtalen
Del 3: Lön är rättvis ersättning – inte belöning
Del 4: Släng titlarna
Del 5: Ny kunskap – ett gemensamt ansvar, avsnitt 1
Del 6: Hitta rätt folk – släpp dem lös

Lägg ner utvecklingssamtalen

Första gången jag hörde någon på allvar utmana utvecklingssamtal var på ett seminarie med Jeff Sutherland (Scrums fader). Jag tror det var 2007 eller möjligen 2008. Jag hade då erfarenhet av att sitta i bägge ändarna av utvecklingssamtal.

Som medarbetare kunde jag inte minnas ett enda sådant utvecklingssamtal som verkligen varit meningsfullt. Några hade möjligen varit harmlösa och trevliga samtal, men åtminstone ett par av dem hade varit direkt demotiverande och framförallt minskat mitt förtroende för samtalspartnern: min chef.

Continue reading

You know, every system has a software architecture and a software design. Whether you think about your system’s architecture or not, it will have one. Here is an example of two methods in a class I recently saw. It is not architecture, it is good old OOD, but it exemplifies what can happen if you

I guess you have heard about T-shaped people, that is, people with deep skills within one or a few areas combined with some knowledge in many areas.

Now it’s time to introduce U-shaped teams. That is, teams that are balanced and where teammates are helping each other. It’s a team where you might have a bad day and are allowed to fail without causing consequences. It’s where the teammates help you get back to normal and what’s more make you feel comfortably included in the team. Your team becomes your safety net and it’s the place where you can dare to be vulnerable. U-shaped teams are also good for productivity since safety means productivity. *

Continue reading

Finns nu i bokform på Leanpub

“Software developers…principal work is human communication to organize the users’ expressions of needs into formal procedure” Tom DeMarco, Peopleware

Detta är den första posten i en serie om agil HR “from the trenches”.

Del 1: Continuous investment
Del 2: Lägg ner utvecklingssamtalen
Del 3: Lön är rättvis ersättning – inte belöning
Del 4: Släng titlarna
Del 5: Ny kunskap – ett gemensamt ansvar, avsnitt 1
Del 6: Hitta rätt folk – släpp dem lös
Del 7: Kontor – låt teamen bestämma
Del 8: Tidredovisning – och andra onödiga system
Del 9: Bortom agile – unmanagement

Continuous investment

Våren 2011 slutade jag med utvecklingssamtal. Jag var då utvecklingschef på ett produktföretag och hade som alla andra chefer i Sverige (och den anglosaxiska världen) ett årligt återkommande samtal med var och en av mina medarbetare där jag – det ingår ju i själva grundidén om utvecklingssamtal – skulle hjälpa dem att utveckla sig i sitt arbete.

Min tanke var att göra som jag så ofta gjort när det handlar om (agil) organisationsförändring: gör ett experiment, mer eller mindre i det tysta, och se hur det går. Nu är just utvecklingssamtal lite svåra att lägga ner i det tysta, och då inte bara för att jag pratade om det på Agila Sverige det året – det var ju inte ett så diskret sätt att göra det på – och inte heller för att det ju blir uppenbart för de som blir av med den enda chansen på året att utvecklas (ironi), men framförallt eftersom det just är en av de ganska få väldefinierade processer som företag normal har. För att lägga ner utvecklingssamtal måste man (oftast) prata åtminstone med HR (och antagligen med ledningsgruppen, så var det i varje fall i mitt fall).

Continue reading

All teams have some sense of what is regarded as acceptable or good behavior within the team. Most people know that colleagues don’t appreciate it when you’re late. Perhaps you have a silent agreement regarding how you vote and make decisions. Some teams write down their behavior and collaborative “protocol”  in a Working Agreement.

You might think that common sense covers it and writing it down seems silly, but surprise – common sense is subjective and you will have different opinions about things. Great! Let’s discuss and find our common ground.

The act of discussing it and writing it down is also a strong team building activity and forges relationships between team members. Any new team, or any team for that matter, could benefit greatly from a one-hour workshop. It could be part of a retrospective or a stand-alone meeting.

Continue reading

Sammanfattar i min presentation från Meridiumdagen ett antal Agila kontrakt som är i bruk idag och vad man bör tänka på när man använder dem. ——————   For the English reader: What does Agile contracts really mean? –  I walk through a number of real contracts that are in use today (presentation was given in

If you prefer this as an article – you can download it here.

What is continuous improvement?

Continuous improvement always starts by observing previous results. That is our baseline for improvements forward on. We strive to improve steadily, a little at a time – 10% is great! But first step is always to accept the facts, regardless if we would have liked it to be better.  It is way too easy to sweep failed projects under the carpet rather than used as a baseline for improvements forward on. A mistake easily made is to base improvements on dream targets rather than previous results, it is hard to learn something from failure to meet those targets.

Continue reading

A couple of months have passed since I wrote the post “Responsibility the Agile way” and I have refined it since then. Here is the new and more slim version:

1) I promise to look for improvements, both opportunities and problems.

2) I promise to participate in implementing the improvements. I will at least communicate the improvement possibilities I have found.

Continue reading

Have not all of us been in a spot where we feel an urgent need to fix some quality such as performance or availability, which takes a change in the architecture for effect? And yet we are pushed to work on new features instead?

There is a chasm between the tech side and business side that has to be bridged before a sound dialogue about system architecture can take place.

Continue reading

(UPDATE: see Spotify Engineering Culture, two short animated videos showing how we work)

Dealing with multiple teams in a product development organization is always a challenge!

One of the most impressive examples I’ve seen so far is Spotify. I’ve had the pleasure of working with Spotify on and off ever since the company was founded, and it’s one of the few companies I’ve seen with a truly agile culture. Spotify has grown a lot lately and now has hundreds of developers divided into 30 agile teams spread over 4 cities in 3 timezones. So how is this managed?

Check out the article: Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds. I wrote it together with Anders Ivarsson, one of the agile coaches that I’m working with (Spotify has a truly awesome group of coaches!).

Continue reading

Aaaaaah…  Nice. *Dumdi dum di dum*   .. what? Ah! I can walk around and pull from the other side!  *clever* 🙂   Darn! Not always easy being a kanban coach 🙂

Yuval Yeret (@yuvalyeret), Lean/Agile Coach extraordinaire, compiled a very practical list of avanced Kanban reading/watching materials. Reading the list I get a view of Kanban centered around continuous improvement towards a True North (as described by Toyota Kata’s Mike Rother). This is has also become my understanding of Kanban, especially when trying to motivate and

Here are the slides for my talk “Lean from the Trenches” at Øredev, Malmö. And here is the book/ebook, in case you want more details. There may also be some copies left at the conference bookstore. Thanks for attending!

Are you building a Lean Startup, and want fast results? Twitter Bootstrap could be the solution you’re looking for. Are you a “backend” programmer who would love to have a beautiful site, but you “don’t know frontend”? Twitter Bootstrap could be the solution you’re looking for. Are you just looking for a simple frontend that works? Twitter Bootstrap could be the solution you’re looking for. Nice rounded corners, customizable colors, margins that look good, padding that’s right, JavaScript that just works: that’s what Twitter Bootstrap offers.
Continue reading

Introduction

I got into agile development during the late 90s when I read Kent Beck’s book about extreme programming (XP). It was mostly the technical aspects of XP that attracted me; I liked test driven development and continuous integration and I understood the benefit of continuously reviewing the code by doing pair programming. It took some time for me to turn my attention to what I mainly focus on today, and what I see is a cornerstone of agile, teamwork. Product development is in most cases a complex endeavor where you need a high level of collaboration and teamwork to reach required outcome. To succeed you have to make sure the participants build on each others strength and knowledge, and where they see differences as something valuable and important. But it is not certain that all working groups ends up as a true team. As a team coach you need to pay attention to building the team at the beginning. This post will describe a few tools that I have used in order to form teams.

Continue reading

It’s pretty tough to explain to a 6 and an 8 year old what it is you do all day at work as a programmer. They take the computer programs they use for granted, and just assume that websites work because they’re supposed to work. Explaining that someone had to write “code” to cause a button press on the screen to do something is a bit too abstract. A simpler example though worked wonders! I was working on a little HTML5, Canvas application for a Crisp seminar a couple of years ago called Ball Bounce (a simplified pong-like game), and the girls were mesmerized by how changing a few characters in the editor made huge visual changes in the web browser. Finally a break-through! But JavaScript is not really an entry level language, and teaching kids about events is probably not the best start. So, what is an easy, visual program with instant gratification? Well, why not Logo?
Continue reading

As JavaScript is transitioning from the dark ages as a language of ridicule to a respected language of it’s own, it is obvious that some of the rough edges need polishing.

There is no rougher edge than the global namespace issue and the difficulty providing encapsulation. Even for a seemingly trivial JavaScript application, it is no longer OK to just whip up some JavaScript files and assume that you can maintain the code base as it grows. The application now lives in the browser and the amount of code you need to maintain requires modularization.

Continue reading

After years of programming in Java with frameworks like Spring, GWT, JBoss, Hibernate, Seam and other traditional stuff, I needed a new learning curve. My colleague Mats Strandberg invited me to create a new version of his code kata/hobby project SignUp.

SignUp has been built and rebuilt several times before, but for this incarnation (number 4 of the more prominent ones) we decided to use some stuff we haven’t used so much before: Scala, Play! Framework 2.0, Anorm, Twitter Bootstrap and Secure Social. We store the source code on GitHub and deploy on Heroku. In this article I’ll summarize some of the things I learned so far. Since I’m an IntelliJ IDEA user, there is some of that too…

Continue reading