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

This is basically a 1 day product ownership course compressed into a 15 minute animated presentation.

Over a million views! Some call it “The best 15 minutes on the Internet” 🙂

There’s obviously more to product ownership than this, so see this is a high level summary.

• Here’s the complete drawing (.png format)
• Here’s a downloadable version of the video, in case you don’t want to stream (.mov format, 90 Mb)

Special thanks to Alistair Cockburn, Tom & Mary Poppendieck, Jeff Patton, Ron Jeffries, Jeff Sutherland, and Michael Dubakov for providing many of the models, metaphors, and ideas that I use in this presentation.

Translations: (see also the translation guide by Cédric Chevalerias)

• Chinese – simplified (subtitles)
• Chinese – traditional (subtitles)
• French(subtitles)
• French (voice)
• German (subtitles)
• German(voice)
• Italian (voice)
• Japanese (subtitles)
• Polish (voice)
• Portuguese – Portugal (voice)
• Portuguese – Brazil (voice)
• Russian (voice)
• Spanish (subtitles)

Below is a full transcript in english. But I recommend watching the video instead of reading the transcript. The video is 100% visual, the transcript is 0% visual…

Continue reading

Hi! Just back from a great conference – LKCE 2012 –  and a great town – Vienna. A really cool thing was the illustrator who worked around the clock to visualize how he interpreted the difference presentations. He did a great job (see below). What would you do – learning from charts I challenge the

Building a well-functioning software delivery team is complicated. There are many factors to consider. Current team (if any), needed skills, available people, company politics etc.

There are some fundamentals that often (but not always) seem to work.

My fundamental principles for teams

• Static
• Cross-functional
• 5-9 people
• Co-located
• Dedicated team members (belong to only one team)

I find these principles to be a useful basis for discussion, when helping managers configure their teams.

The principles are goals, and one must realize that all cannot be achieved all of the time, nor instantly.

Continue reading

For the past couple of years I’ve had to work with Jira. Really, it’s mostly been dreading working with Jira. At both projects I’ve had Greenhopper available, and that hasn’t really made things better. My frustrations have had to do with the complexity of setting up the right fields, to creating a new sprint to creating a new project, down to mundane things like problems with ranking. I don’t particularly enjoy spending hours just tidying up my data. I want to quickly organize so I have time to actually work. I also want to easily see how much work we’ve done, and how much we have to do. Cards and a physical board are great for this, but I end up with stacks of cards everywhere, and after several sprints I don’t know what to do with them anymore. Enter Trello!Continue reading

För några veckor sedan var jag på Crisp Hack Summit (en och en halv dag valfritt hackande) och då jag jobbar med Android-utveckling kände jag för att testa skriva en liten app som man kan kommunicera med via SMS. Det är ju inga större problem att kommunicera med en telefon om man har en fungerande IP-förbindelse, men om man inbart har 2G så blir det lite värre. Dagens prepaid abonemang har oftast en obegränsad mängd med SMS (åtminstone om man inte är tonåring) som man kan skicka. Så varför inte göra en app som när man skickar strängen “ping” svarar med “pong” 🙂
Continue reading

Lite i skymundan pågår något av en revolution inifrån i IT-branschen, och då särskilt i företag med många programmerare. På gräsrotskonferenser, i nätfora och i management-litteratur äger vår tids kanske mest avancerade och levande diskussion om hur man bäst organiserar arbete rum. Om det skriver jag i en längre essä om hur programmerarna visar vägen

Today I decided to update my canned wicket test examples to the latest version of Wicket.

I still think Wicket is a really nice web framework for the following reasons, primarly.

1. Hot deploy from the Maven archetype. The quick start setup offered from the Wicket site gives you “change-and-reload” out of the box.
2. Unit testing framework built in. You test the logic of the web application without resorting to click simulation.
3. HTML separation. Allows you to work in a tight loop with an interaction designer that can use any HTML editor.
4. No need for JavaScript. Well, for the basic stuff at least. The examples here all use AJAX.