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

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

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

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

In April this year we had Christopher Avery at Crisp giving his two days workshop Creating Result Based Teams. I read Christopher’s book about creating effective teams a few years ago which I found very inspiring and it was loaded with a lot of wisdom about working with teams. I was therefore very excited to

I had recently a conversation with a business partner of mine, Erik Andrén at Macmann Berg. We were working on the material for the next workshop in a leadership program we have at a client. This time the workshop was about coaching, both in general terms but also from an agile perspective. Erik has a background as a therapist but is nowadays working as an organization and management consultant. At our meeting he described his view about coaching based on a therapy model he had used as a therapist, and we then had  a very interesting discussion about the model and the connection to continuous improvement of teams and organizations. This post discuss this connection since I believe we have a lot to learn from how therapists approaches patients when trying to help them create a better life for themselves.

Continue reading