Tag Archives: teamwork

Team Shapes – Simulating the challenges with component teams

Posted on by

A common pitfall for large and medium size organizations who are adopting Agile is to organize teams based on software component boundaries instead of feature teams. Some of the aspects of long term code ownership are more straightforward this way, but the negative consequences in terms of business agility and costs of coordination are huge. A few years back I designed a simulation exercise that I call Team Shapes which illustrates some of the issues and now I would like to share this simulation with the community. 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 »

New book: Toolbox for the Agile Coach – Visualization Examples, now available on LeanPub!

Posted on by

Book Cover 2I’m happy to announce that Toolbox for the Agile Coach – Visualization Examples is now available on LeanPub! It’s a 124 page book cramped with visualization examples for teams on how to improve collaboration and communication, as well as shaping behaviours.

It’s been great fun to write. It’s been great fun to get feedback from early readers. It’s been great fun to show it to colleagues and friends. And now, finally, it feels awesome to be able to share it with you!

LeanPub LaunchI planned to release the book in physical and digital form at the same time… but getting it printed have sadly taken forever, and I still don’t know when it will be available on Amazon.

So, I’ve decided to go ahead and release the digital version first. Might be a stupid thing to do from a marketing perspective, but I don’t care about that. I want the book out and available 🙂

read more »

New book in the writing: Toolbox for the Agile Coach – Visualization Examples

Posted on by

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

Cover

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.

Examples

read more »

A Scrum Product Owner Checklist as a mind map

Posted on by

If you wonder what a Scrum Product Owner need to do, here’s the checklist (in form of a mind map) for you!

read more »

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 »

Why I prefer ToDo over Trello for agile teams

Posted on by

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.
Swimlanes on a ToDo board

Swimlanes on a ToDo board

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

read more »

Delagardrivet och upplevelsebaserat lärande

Posted on by

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.

Kort med verktyg och upplägg från Training from the Back of the Room

Kort med verktyg och upplägg från Training from the Back of the Room

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.

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 »

Guest post by Christopher Avery: How to Get Smart People With Big Egos to Work Together

Posted on by

Christoper Avery, a leading authority on applying personal and shared responsibility for agility and performance, returns to Crisp in Stockholm April 29-30, 2013 to teach his public workshop Creating Results-Based Teams. Space is limited. Register now.

This classic blog post was originally posted on Christopher Avery’s popular Leadership Gift blog on February 9, 2011 — you can find it here.

Why is it so hard to build a well-functioning team?

Often it is because we’re looking in the wrong place for answers.

The most important game may be the one you aren’t even seeing.

I’ll share a critical secret for success. The primary problem lies in what you are (or are not) paying attention to. When it comes to working with smart people in shared-responsibility situations, all too often I catch myself getting caught up in the wrong game — a pointless game. I bet you do, too.

When I start paying attention to the truly important game, my ability skyrockets. And yes, you can solve this problem for yourself as well.

read more »

Guest Post by Christopher Avery: The Difference Between Accountable and Responsible Leadership

Posted on by

Christoper Avery, a leading authority on applying personal and shared responsibility for agility and performance returns to Crisp in Stockholm April 29-30, 2013 to teach his public workshop Creating Results-Based Teams. Space is limited. Register now.

This classic blog post was originally posted on Christopher Avery’s popular blog on January 20, 2011 — you can find it here

There is a big difference between being an accountable leader and being a responsible leader. I have been working with business leaders for the last 20+ years as a consultant and speaker, and I am committed to showing real leaders the powerful difference.

The following may sound a bit harsh or pedantic at first, but stay with it and you will be rewarded with important distinctions:

An accountable leader focuses on being able to account for his or her actions and results. As a communication scholar years ago I researched “account-giving.” That is simply the narratives (i.e., stories) we make up to explain what is going on — we give accounts.

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 »

Lägg ner utvecklingssamtalen – Agil HR i praktiken

Posted on by

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.

read more »

Continuous investment – Agil HR i praktiken

Posted on by

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

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 »

Team LiftOff with Market of Skills and Competence Matrix

Posted on by

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.

read more »

Commitment

Posted on by

There are many theories on how we can get a team to become hyper productive. Everyone in the industry is looking for the answer. I can hereby promise that if anyone comes up with the silver bullet it will include “how to get commitment” as one of the most important ingredients.


There are teams with very talented team members and managers and challenging tasks but they fail to deliver and on the other hand there are teams with not as skilled team members or managers and boring tasks and they deliver. Why do we see this again and again?

My answer is Commitment.

 

Agile methodologies are a very good start to get the right prerequisites for a project to succeed. So why agile might work!

To start with, in Agile projects everyone involved should be in the planning meeting to make sure that they understand and can contribute to how the team should solve the problem. The team discusses the tasks together, breaks down the task to minor tasks so everyone understand the big picture, then they will estimate the tasks by playing planning poker and at last they decide how much they can commit to, using the pull scheduling.

Product owner (Customer) agrees to the planning and has thereby committed to the team.

When the iteration is over the team has a demo and retrospective on what they have done and how they can improve. Don’t forget that the team should be hold responsible to their tasks and improvement they have committed to do.

 

This sounds good and easy but sometimes this is not enough. So I have created a list of how to improve the commitment of the team.

  1. Building trust form all levels, team members to team members, team members to product owner and product owner to team members, maybe using the five dysfunction of a team
  2. Never start a new agile team if not everyone involved has at least a basic level of agile knowledge.
  3. Never start a new agile team without everyone being present at the first planning game.
  4. Make sure that there is at least a product owner or a proxy product owner on every planning game and that he or she is committed.
  5. As a ScrumMaster before finishing the planning game, ask every team member if they believe in the plan and if they are committed.
  6. The team must break down the stories and understand all tasks during the planning game.
  7. Only the team decides on how much they can commit to, think pull and not push scheduling
  8. Don’t let any new person into the team in the middle of iteration, if they have not been working with at least one Agile project previously.
  9. A good and active ScrumMaster that drives the team, helps team members with solving their impediments. Asking the team at the end of every daily meeting if they still think that the sprint will succeed and if not what can we do to get a better plan
  10. Make sure that the improvement discussed during the retrospective is applied

In the end I would like to address the importance of an open and interactive planning session (Sprint planning) as one of the keys to success with team commitment. Don’t be afraid of changing the plan and keeping the commitment of the team if the team does not believe in the plan anymore.

Is your team cross-functional enough?

Posted on by

Cross-functional team doesn’t mean everybody has to know everything – this seems to be a common misinterpretation though. Cross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing.

Are you unsure if your team is cross-functional enough for the product they are building, or are you sensing a lack of teamwork? Here’s a useful workshop technique (with a  slight teambuilding effect as well):

Get the team together and bring the product backlog. Ask the team “what are the main skill areas needed to build this product?” and list the skill areas on a whiteboard or flip chart. Then give each person a pen and ask them to rate themselves within each skill area.

  • Star = I’m good at this, or this is my main skill area.
  • Dot = I know a bit of this, enough to contribute. Or I can learn and am willing to do so.
  • Empty = I can’t or won’t do this at all.

Cross functional team
This usually triggers valuable discussions and insights such as:

  • Joe: “Looks like we don’t have as much of a specialist problem as we thought!”
  • Lisa: “Yeah, I didn’t even know Jenny could code Java!”
  • Jenny: “Well, I’m not too good at it but I have some personal hobby projects and I really would like to learn more! I’m sure I can contribute as long as I don’t have to do the hard parts.”
  • Joe: “I thought I would be a real bottleneck as DB expert, but now I see that Lisa could help me with some DB stuff!”
  • Lisa: “Yeah. Java is my main skill but it seems I’m the only person other than you that could do DB stuff, so I should probably spend more time helping you with DB work instead of just coding Java.”
  • Joe: “DB knowledge is still a potential weak spot for us as a team though, so I’ll talk to the product owner and look ahead in the product backlog a bit. If we see DB intensive stuff coming up it may be worth getting another DB-skilled person on the team, or at least giving us access to a contractor for a sprint or two.”
  • Erik: “I really hate testing, really suck at it, and am not interested in learning more about it. So I’m really happy to see that the rest of you guys are willing to test, now I don’t feel as bad focusing on my other skill areas instead.”

It may even trigger the insight that this team is incorrectly staffed for the product being built. That’s extremely useful to find out early!

A good rule of thumb is that each column should have at least one star and one dot (or two stars). That means we have at least one guy who is good at that job, and at least one additional person who can help out when needed. And the team won’t be completely helpless if the star person gets sick or hit by a bus.

I like this exercise because:

  • It’s quick & easy.
  • It triggers valuable discussions.
  • It helps visualize the team’s strengths and weaknesses.
  • It encourages teamwork (“how can we help each other succeed”)
  • It counteracts pidgeon-holing (attitudes such as “I’m the Java guy and you’re the DB guy, so the DB stuff is your job!”).
  • It helps people get to know each other better.
  • It takes into account the fact that people can (and often like to) broaden their skills.

Agile game – Pass the Cup!

Posted on by

Timing: 10 mins

Ingredients:

  • A fair amount of cups ( x2 > no of team members)
  • A bag  (holding cups)
  • A referree counting cups and checking time

Directions:

Split into two teams "planners" and "doers". Introduce both teams into winning rules: Any team passning the highest number of cups around in 60s will win. Any cup dropped is considered faulty and has to start over from the beginning. 

Limitation: A cup cannot be passed on to the person standing next to you but cup must pass all persons in the team before counting as a score.

Planners: now has 5 min for planning their way of action (but are not allowed to practice!)

Doers: can practice for 5 minutes

Bring teams out and run the game. 

Note: game can also be run in a single team setup with two rounds. Give team 1 minute to plan before each round and note the number of cups passed in each round.

Learning Points:

  • By doing, you uncover things you could not forsee
  • By doing, team has already passed a number of cups! (aka made a prototype 🙂
  • How did productivity go up per iteration?
  • Who stepped up and offered solutions? Was problem solved through member interaction or command/control?