Tag Archives: team

Transforming the pyramid to an agile org

Posted on by

I recently published a video exploring how an agile team based organization could look like. How does it function under the hood? In the video I also discussed how you get there.

I got tons of great feedback so I decided to provide the contents of the video in the format of a blog. If you prefer to read instead of watching a 11-minute-long video, then this is for you 🙂

AgileOrg

read more »

X-team Silos Game – getting in T-shape

Posted on by and

Cross functional teams are complete in expertise but not necessarily collaborative. Sometimes team members hold on to their expertise too much and the team does not perform to its potential. This Lego game illuminates the difference when members allow themselves to take on tasks outside their expertise, being so called T-shaped. Play the game to kick-start your change and create collaboration.

Playing the game.

read more »

Better meetings with the Core Protocols

Posted on by
Core Protocols Stack helps shaping better meetings

Core Protocols Stack helps shaping better meetings

Good meetings is very much about achieving deep collaboration. But collaboration is often hard. We go into meetings with different modes, intentions, and expectations. How can we make meetings both more fun and energetic? Surprisingly enough: maybe by being more formalized.
read more »

Fluent@agile – visualizing your way of working

Posted on by

Help your team improve by visualizing their way working with the fluent@agile game. With the game you can help a team find out where it is on its agile journey and help it find new ways of both fine tuning and make leaps in their daily agile practices.

Fluent@agile board

A teams fluent@agile board.

Me and Christian Vikström made the game together at Spotify during the spring 2014 when we were coaching and helping team to improve their agile skill sets and processes.

At Spotify the teams owns their own way of working. A team is basically only accountable to itself. We therefore needed an coaching tool that could help team take ownership of their self image and improvement strategy.

We also wanted the tool to be opinionated. It should be normative, tell what’s good and not, what kind of practices and behaviour that’s expected and not. But at the same time it should be open to new ideas, new practices and the teams local conditions.

read more »

Agile Topics card deck

Posted on by

The other week I got the idea to create simple conversation cards. Each card represents an agile practice, a conversation topic or an abstract theory. Now I’ve drawn 96 cards. I simply couldn’t stop 🙂

Cards

read more »

Tillsammans – så river programmerarna företagspyramiderna

Posted on by

I år hade jag äran att i anslutning till Agila Sverige (2015) släppa Riv pyramiderna igen som riktig bok med den mycket bättre titeln Tillsammans – så skapar du flyt och egenmakt med agile och lean (tack till Joakim Holm för att du övertalade mig att negativa titlar är dåliga).  Den hemliga undertiteln tycker jag dock är “så river programmerarna företagspyramiderna”.Tillsammans

För det är ju just det det handlar om. Först vände programmerarna upp och ner på mjukvarubranschen genom att börja ge bort sitt arbete som fri källkod. Nu vänder de upp och ner på företagen genom att göra den gamla sortens chefer överflödiga.

Programmering handlar om att generera kunskap. Och det sker bäst när man får arbeta direkt mot användarna och när man själv får styra sitt arbete. När man får makt över sitt liv på jobbet, kort sagt. Och eftersom allt mer i samhället kräver programmerare får programmerarna makt. De kan forma sina arbetsliv så bra som det är möjligt.

Denna förändring är så spännande att följa och i Tillsammans skildrar jag mitt arbete som chef i en produktorganisation och hur vi förvandlade den till en utvecklingsorganisation i världsklass, med hjälp av agile och lean och en hel del gnutta sunt förnuft, och framförallt: extremt experimenterande.

Jag påbörjade och en märklig resa där min roll som chef drastiskt förändrades: den som behöver praktiska tips om hur man gör med utvecklingssamtal, karriärvägar, lönesättning, kompetensutveckling och rekrytering i en organisation som domineras av självorganiserande team hittar gott om tips i Tillsammans hoppas jag.

Läs mer om Tillsammans här eller köp direkt från:
adlibris och bokus.

My Spotify tools

Posted on by

Last week i quit my assignment at Spotify. I was there to help and act as a stand-in for Joakim Sundén while he was on paternity leave. He’s now back in the saddle as Agile Coach in the More Than Music Tribe.  I had the pleasure to work closely with the Agile Coach Christian Vikström on Spotify and together we have been coaching the Browse, Growth and Customer Support squads. A was also a member of the tribe management team, and together we did some new interesting stuff.
Facilitating from the Back of the Room
It’s has been fascinating and fantastic to work with such dedicated people and a product that has such a traction. Spotify is also really trying to build an awesome and agile organization and culture that can win and sustain in the long run. What is there to do at such a fantastic company? That’s a reasonable question. A lot I discovered. Spotify is shock full of super smart people, but many of them has not worked there for long, many of them has not worked long at all, teams have been newly formed and are under constant change. Simply put: even Spotify needs a lot of basic agile coaching.

When I now look back at what we did during these last 8 month I see a lot of tools and experiences that I think others also can find useful. During the next couple of month I will share them through this blog. Hope you will find them useful. Here’s the planned list:

read more »

Consensus slides and speech from Agila Sverige 2014

Posted on by

At Agila Sverige 2014 I talked about consensus, what it is, why it is the basis for creating good and strong decisions that is often already implemented when the decision is finally made. I also talked about the hand signals we use at Crisp to manage our consensus decision process (read more about it here).

Here’s my slides, that contains more on howto facilitate consensus decision making:

read more »

Role Expectation Mapping

Posted on by

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.

Questions

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.

read more »

Team barometer (self-evaluation tool)

Posted on by

Sometimes it’s hard for a team to know if they get tighter and better as a team over time. This is a tool that allows a team to learn just that.

Team barometer (self-evaluation tool) in a nutshell

The barometer is executed as a survey in a workshop. The survey consists of 16 team characteristics, packaged as a deck of cards. Team members vote green, yellow or red for each card in the meeting (or before the meeting as an anonymous survey). Once all cards have been run through, the team reflects and discusses the results. You can, if you want to, run through the exercise in thirty minutes, but I recommend to set aside an hour.

Click here to download the cards.
read more »

Det är inte bara din ScrumMaster som behöver förstå vad “agile” är!

Posted on by

Återigen har ni diskussionen om “working software over comprehensive documentation” verkligen betyder att man inte behöver dokumentera någonting alls. Eller diskussionen om det är ok att förlänga sprinten med några dagar för att hinna klart den sista fixen på den där storyn. Eller diskussionen om vad det egentligen innebär att vara “lean”. Känner du igen dig? Kan det vara så att alla har nytta av att ha samma grundförståelse av centrala begrepp i och runt “agile”? Läs vidare för ett enkelt sätt att skaffa den kunskapen! read more »

Kompetens i det dagliga arbetet

Posted on by

Finns nu i bokform på Leanpub

Kompetens i det dagliga arbetet

Detta är avsnitt två i delen om Ny kunskap - ett gemensamt ansvar i serien Agil HR from the trenches

Kompetensspridning via team

Låt oss börja med att ställa några ledande frågor:

  1. Arbetar ni i team som innehåller alla kompetenser som krävs för att leverera slutprodukten?
  2. Är det tillåtet (och helst uppmuntrat) att jobba tillsammans med en uppgift (till exempel parprogrammera)?
  3. Får team arbeta med saker då och då som de inte kan innan (ny domän, ny teknologi)?
  4. Kan man (kanske inom rimliga gränser) själv välja vilket team (och därmed område) man vill arbeta i?

Om du svarar ja på alla dess frågor kan du antagligen gå vidare till nästa avsnitt direkt. Om du svarar nej på samtliga, då skulle jag gissa att du både har stora utmaningar att alls leverera saker och att få till utveckling av yrkeskunskap på jobbet. Det kommer också vara ytterst svårt, eller omöjligt, att kompensera den sorts evigt pågående kompetensutveckling som uppstår ur att organisera arbetet på ovanstående sätt med andra former av åtgärder.
read more »

Evil Coach LIVE! “Maximize the Teams Performance”

Posted on by

During the conference Agila Sverige 2013, I – the Evil Coach – made my first public appearance. I gave a lightning talk on how to maximize the team’s performance. The room was filled to the brim. The talk ended with standing ovations which were immediately followed by an early termination of the conference since no one could possibly top my performance.

I gave the following short statement to someone before leaving through the back door: “I feel new energy surging through me. It feels nice to enlighten people on the true power of agile.”

If you know Swedish you can now experience the talk in video below.  The talk starts at 00:14:00.

PS. Picture above from Matti Karlsson Twitter feed. DS.

Släng titlarna

Posted on by

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”.

read more »

A team experiment with and without offshoring

Posted on by

A cross-functional team I was working with last year had three testers offshore in India. The rest of the team (about 15 people) was co-located here in Stockholm.

Some team members had a nagging feeling that they could go so much faster if the testers also moved to Stockholm so they went to their boss and asked. The reply was that testers are so much less expensive, by a factor 2.3, so it was not possible, unless they could settle with fewer testers.

So they decided to do an experiment for a few months. They moved one of the testers from India to Stockholm and dropped the other two testers (re-allocating the other two to other teams) to see how that would work.

read more »

Lön är rättvis ersättning – Agil HR i praktiken

Posted on by

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å.

read more »

T-shaped people and U-shaped teams

Posted on by

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. *

read more »

What questions does your Working Agreement answer?

Posted on by

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.

read more »

Five team principles

Posted on by

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.

read more »

Case Study of Mobile Team at Projectplace

Posted on by
Projectplace

Projectplace

I am currently working as a Scrum Master for multiple teams at Projectplace in Stockholm, Sweden. One of those teams is the Mobile Team. They are developing Action Boards for both iOS (iPad) and Android platforms. These Action Boards are also available in the Customer Preview of the Projectplace web service. Both Web Team and Mobile Team share the same API’s. The iPad app is planned to be released in 2-3 Sprints from now.
This case study can be written from many perspectives, but in this article I am going to focus on how we are working with the challenges of having a distributed Scrum team.

read more »

A professional mindset

Posted on by

Is this years final series in the Swedish hockey league, there is one team that standing out from the crowd. They are more stable, persistent and thorough in every part of their game than the other teams.

Today I stumbled over this comment from one of the players. It highlights a mindset I have seen in both software and sports team that basically felt unstoppable.

"If I am going to think about this victory on the way home? No. I am only going to think about the details that is going to make us better in the next game" 

           – Jimmie Ölvestad

Emo-lines

Posted on by

If you coach a scrum team but you’re not around to observe them during the sprint, how do you know how they felt about it?

Ask them.

You can interview them individually or as a group. Both approaches have their problems and limitations. Individual interviews take a lot of time, and sometimes you can’t share the results without breaking confidence. If you ask them as a group you usually only get answers from the most outspoken people because:

It’s hard to talk about your feelings among strangers.

One of the teams I coach had mixed feelings about Scrum. Some were healthily skeptical, and some positive. The first sprint went very well, with a good sprint planning, a lot of initial energy and a demo that actually showed customer value. But I felt that some of the team members were not too sure how the others felt about the whole thing. I wanted to help them with that and also get some feedback myself (I admit I was a bit nervous about not being around).

I used Emo-lines.*

Here’s how you do it. First draw a time-line representing the whole sprint and ask everyone to put up notes, marking memorable or unusual events. The team’s looked something like this:

Then you prepare for the Emo-lines, start by drawing a line directly underneath the time-line. The line represents neutral feelings, with feeling good above, and feeling bad below:

Next, have each person draw how they felt during the spring using different colored markers, starting at the sprint planning and ending with the sprint demo. Here’s a simplified version of the team’s chart:

The team members’ feelings varied greatly, you can see from the chart that the sprint demo went well though because everyone felt pretty good at the end.

The next step is to ask each person to comment on his/her line. Here’s what the team said:

Mr Green – a skeptic at first.

Mr Green is a very influential person in the group and the architect, he was the first to go. He said that he was a bit skeptical at first (as everyone had noticed during the scrum training right before the sprint started). He was worried that sitting and working in a team room would interfere too much with his flow and his privacy. As the sprint went on, he came to appreciate how quick and easy communication was with the new setup and realized that it was rather fun working that way. And when the first demo went well, well…

Mr Blue – a scrum advocate who got lonely.

Mr Blue was one of the driving forces in introducing Scrum to the company and the only one who was a certified scrum master. So I was a bit surprised and worried that he had such a dip after the first week. As it turns out, during the second week he had to work from home because his kids were sick, so he felt isolated and unproductive.

Mr Orange – an enthusiast both when skeptical and when not.

Mr Orange was also one of the skeptical-at-first but enthusiastically so. At the beginning of the sprint he felt that it was fun and that it worked for him. The problem was that they actually completed the whole sprint backlog mid-sprint and he thought that was boring and unproductive. As soon that they got some extra work from the product owner he was happy again.

Are Emo-lines useful?

The team thinks so, and they decided to use them at the next retrospective. The second time they got even more out of the chart, each line showed more variation and the explanations were more detailed.

They are also valuable to me as a coach. Even when I am not with the team during the sprint I get detailed feedback about how the team feels at the end of each sprint.

I also noticed more than one surprised look on the other team members’ faces when Mr Green talked about his line, and I think some team building took place.

Here’s a picture of the whiteboard:

*If someone has another name for these, please let me know, I heard about them from my colleague David Barnholdt, and he didn’t have a name either.

Emo, see http://en.wikipedia.org/wiki/Emo

The responsibility model

Posted on by

At the Lean Software conference in London Portia Tung tipped me off about Christopher Avery’s responsibility model. I need to show it to you.

  1. Denial – ‘Problem? What problem? There’s no problem.
  2. Blame – ‘I don’t have a problem working with you. You seem to have a problem with me. That makes it your problem. ‘
  3. Justify – ‘I guess it’s possible that I’ve become insensitive to other people’s feelings and needs. I can’t help it though. After all, I’ve been doing this job for a long time. It’s who I am.’
  4. Shame – ‘What have I done? I’m going to look such an idiot in front of the people at work. How am I going to live it down? Why should they help me after the way I’ve behaved?’
  5. Obligation – ‘Tell me what you think I should do. I have no choice but to do it (even though I don’t want to). I’ll do whatever you say. It’s only a job after all (no one can expect to do a job they love).’
  6. Responsibility – ‘I can wait for them to change but that could take forever. No, it’s up to me. I want to fix the problem. So how am I going to be a better colleague? I know! I’ll listen more. And be more considerate towards others. It’s a start.’

Now test yourself –  just how professional are you?

Kanban checklists

Posted on by

Anytime
(Shall be visible with the glance of an eye)

  • Do we have a bottleneck? (look for congestion/queues)
  • Do we have an impediment not dealt with?
  • Are we keeping our work in progress limit (WiP)?
  • Are priorities clear?

Iteration planning (1/week or on need basis)

Expected outcome:

  • Prognosed delivery date given to PO if needed.
    (Use size/velocity or tasks * cycle time)
  • Stories is broken down and estimated

Schedule

  1. Update charts (velocity and cycle time)
  2. Remove done stories/tasks off kanban board
  3. Lookback last week [max 5 min]
    (What happened? Are we satisfied? Should we adjust WiP limit?)
  4. Team picks one thing to improve on for upcoming week [max 2 min]
  5. Write this down on top of Kanbanboard
  6. PO reads new stories to team
  7. Team breaks down and estimates stories [30 min]
  8. PO revises priorities and makes them visible

Checklist

  • Can all team members do the broken down tasks?
  • Is WiP limit visible on board?
  • Can we see if we exceed WiP limit at any time?

Daily standup

Expected outcome

  • Impediments are surfaced so we deal with them
  • Team members can share experience of problems earlier encountered
  • NEVER takes more than 5 min (takes some training but is doable)

Schedule

  1. What did I do yesterday
  2. What will I do today
  3. Do I have an impediment?
  4. As a team, do we need to act?

Rule:

  • "60sek rule", you have 60s to offer advice to other team members if you can help them
  • All other matter : face2face after daily standup

My favourite top 5 Agile team rules

Posted on by

Building something common out of high performing individuals is not always easy. Here are my favourite five Agile team rules:

  • Best idea prevales!  "No" – is allowed, if you can come up with something better
  • Steady progress beats tripping and falling over
  • Bad news first
  • In order to lead an army, you have to be able to lead a group. In order to lead a group, you have to be able to lead yourself
  • Is it better to be right or to be helpful?

The day I know I have succeeded with Agile? -The day I am out surfing 🙂