Update: The book has since the publication of this blog been
made available for purchase at LeanPub.

A couple of weeks ago I published my new book ”Toolbox for the Agile Coach – Visualization Examples (How great teams visualize their work)” even though it’s still very much a work in progress.

I’ve made it public, thanks to persuasion from my colleague Hans Brattberg. I decided to try out Google Slides to make it easily accessible and to provide a simple way to give feedback. That turned out to be a great decision. The response has been overwhelming. There are at any given point 5-15 people reading the book, many of which provide great feedback, point out spelling correction and provides generous suggestion for more examples.

Continue reading

Having trouble with curled Post-its that won’t stick to the wall? Well, it could be due to bad glue or that you peel them off wrong. I would guess it’s the latter. Might feel like a silly blog post to write, but I found myself teaching people the technique of peeling Post-its quite frequently. It’s

Three months ago I stumbled upon a question which needed an anwer: Could Lego be used for business strategy development? I just had to go to London to find out the answer.

With a group of 12 I spent the full weekend.. building Lego! When was the last time I did that? (hint: some 30 years ago..). The real interesting part is of course the stories we tell about the models. Each time we do, the team moves closer towards a shared understanding and also generate new insights. That’s cool!

Below: Team members walking through our shared model.

Continue reading

A while ago I was asked to help out create a checklist for a team, a checklist that could tell something about whether or not a user story was “good enough”. I opened PowerPoint and starting to ponder over how I could help. I immediately realized that a presentation would be boring, shown once and then forgotten, and not invite to curiosity. I put my laptop away and created a cube instead.

A couple of days later I showed it to a friend and colleague (Viktor Sessan, Agile Coach at Spotify), who were also very intrigued by the concept, and we started to talk about how to take this further.

This is the result 🙂 We believe that if you let an idea loose, and it is a good idea, great things will happen.

Continue reading

Back in undergraduate school I had an artsy roommate who quickly dropped any intention of attending classes. Soon thereafter he picked up a line cook job at the local diner and took on a nocturnal lifestyle. That lifestyle led to a whole new set of friends who quickly helped him develop a recreational drug habit. To support his new found hobby, my roommate began dealing to his new found comrades and their acquaintances. The temptation of having all of that product around him turned out to be too much though and, soon enough, he was consuming more than he was selling leaving him increasingly in debt to his suppliers. This culminated in a day I’ll never forget. I had to take him to the pawn shop so he could trade his car (his last possession) for cash to get out of that debt. We rode home on the back of my motorcycle (which became our only means of transportation for the duration of our cohabitation).Continue reading

– “All kod är en skuld!”
– “Den bästa koden är den kod man inte skriver!”
– “Snabbaste sättet att få upp testtäckningen är att ta bort död kod!”

Jag tror att alla är överens om att det är bra att hålla sin kodbas så liten och kompakt som möjligt. Byggtider hålls korta, testsviter går fort att genomföra, driftsättningar går fort, statisk kodanalys går fort, nya teammedlemmar kommer snabbt in i koden, risken för buggar och sårbarheter hålls nere och så vidare. Kort sagt, man blir mer lättrörlig!

Så alla utvecklingsteam borde ägna tid åt att inte bara skriva ny kod, utan också att faktiskt städa efter sig. Men det är lättare sagt än gjort…
Continue reading

The Gist

• ToDo has a flow. It knows about cycle times and about being DONE. Trello does not.
• ToDo has Planning Poker Estimates. Trello does not have any estimates.
• ToDo has automatic burn up charts. Trello does not.
• ToDo has swim lanes which groups cards by your dimensions. Trello does not.
• ToDo has Work-In-Progress limits. Trello does not.
• ToDo has upgrade possibilities to the full tool set of Projectplace. Trello has a bunch of plugins from different vendors of various quality.

Already convinced? Sign up for ToDo by Projectplace! Want to know more? Read on.

Continue reading

I juni kommer min kollega Jimmy Janlén och jag hålla kurs i deltagardrivet och upplevelsebaserat lärande. Vill vi hjälpa andra att upptäcka och praktisera sätt att skapa sant engagerande och lärande undervisning, presentationer och workshops. Kanske slipper ni då mina egen långa resa bort från katedern.

Så vitt jag minns det var jag 24, kanske 25 år. Jag och min vän Göran hade blivit inbjudna att hålla föredrag inför en större samling människor. Det hade jag aldrig gjort förut. Visst var jag van att prata inför andra människor, från seminarierna på universitetet till redaktionsmötena på vår lilla tidsskrift, men inte att hålla tal. Jag gjorde det som kändes säkrast. Jag skrev ett tal och läste sedan upp det.

Förutom att det tog jättelång tid att skriva talet, så kändes det inte bra att stå där och läsa rakt upp och ner. Visst försökte jag läsa med inlevelse och dramatik, ungefär som när man läser högt för barnen, men det kändes ändå inte bra. Höll inte åhörarna på att somna? Lärde de sig alls något? Det går att trollbinda en publik med högläsning, om man berättar en riktigt bra historia. Göran var bra på det, men inte jag. Något behövde jag göra annorlunda.

Continue reading

Role Expectation Mapping is a series of workshop that explores, clarifies and establishes which expectations members of a group, team or project have on each other.

If you suspect that collaboration is undermined because of mismatch of expectations between people, then this exercise could boost the team’s ability to collaborate efficiently together. It is also a powerful way to jump start a new team and give them a structure to relate to.

People always have certain expectations on each other, behaviors, responsibilities, etc., but if those aren’t made clear and agreed upon among everyone – you are bound to have unconstructive conflicts, colliding agendas, difficulties in collaboration and things that fall between chairs.

Continue reading

I got the question “explain the difference between a feature team and a function team”. When I answered, I realized that many people uses the term without attaching an explaining what they mean. So here is how I define it.

Continue reading

Finns nu i bokform på Leanpub

Detta är den fjärde 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

Släng titlarna

Låt oss börja med två okontroversiella påståenden: Företag bygger på vertikala hierarkier och horisontell specialisering Ok?

Låt oss ta det en gång till.

Företag är hierarkier. Jag skriver här medvetet företag och inte organisationer i största allmänhet. Huruvida organisationer måste vara hierarkiska låter jag nämligen vara en öppen fråga, men företag är hierarkier, per definition.

Det finns förvisso många olika teorier om varför företag finns, men i princip alla går ut på att förklara varför människor som utför aktiviteter på en marknad “väljer” att karva ut en bit av denna ekonomiska aktivitet och där slopa marknadsmekanismerna.

Huruvida skälet till detta är att det minskar transaktionskostnaderna, eller att det löser problem med så kallade externa effekter (marknadsmisslyckanden), eller för att det ökar effektiviteten i hantering av olika egendomar, eller för att det ger makt att hantera ekonomiskt överskott, eller att det helt enkelt ligger i den mänskliga naturen att dominera andra, spelat för vårt resonemang här ingen roll.

Poängen är att kärnan i företag är att någon (företagaren) skriver långsiktiga kontrakt med en eller flera (anställda) som avsäger sig vissa av sina friheter för att i stället bli företagarens agenter. Som en av pristagarna till Sveriges Riksbanks pris i ekonomi till Alfred Nobels minne sammanfattar: Företagaren “försöker utforma avtal med agenterna som ska stimulera dem att öka hans vinst, och han kontrollerar deras prestationer”.

Eller som Henry Ford uttryckte det i lite mer klartext: “Jag tänker betala er tillräckligt mycket för att ni ska finna det värt att acceptera mina diktat i jobbet”.

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

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

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

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

Here’s a new article for you: Cause-effect diagrams: a pragmatic way of doing root-cause analysis Cause-effect diagrams are a simple and pragmatic way of doing root cause analysis. I’ve been using these diagrams for years to help organizations understand and solve all kinds of problems – technical as well as organizational. The purpose of the