Using Containers for motivating team values

This post describes a retrospective exercise we did, where we looked at Containers in the team in order to motivate the work with team values.

Exploring Containers in the team

The facilitator (that would be me) prepared the exercise by drawing all team members on a whiteboard with a face and name for each team member. Meeting started with a briefing about the concept of Containers and CDE. Then we collaboratively searched for containers in the team. As example, we thought that all developers in the team made a container, so we drew a circle around all developers, and so on. After some hesitations and confusions, small things started to happen. We got a few good talks about the effects of containers within the group, preventing cooperation and more.

Finding values needed for a team

After containers got on board, we put a circle up in red around whole team. The follow-up question to this was “What kind of values are in common for the whole?” Results for this was not very easy to produce, but with some supportive suggestions from facilitator we came up with a handful.

Containers team values

You might recognize the team values from Jutta Eckstein and her book Agile software development in distributive teams. The resulting values was like a mix of general values, like “Core Values” (yes we are going meta-meta here) and more concrete objectives, like “money”. Some were removed and some were clarified. We validated the values by talking about what could happen when the value is not present. As example: without a common goal we will have a really hard time in making successful changes. A metaphor used to illustrate this was the drug dealer story from Deana Meadows’ “Resistance to change”. The visualization of containers started to make more sense at this point.

Evaluating team values in our team

Next exercise was a team radar on the team values. We had to put in a 5 minutes break for facilitator to prepare the spider. So, after the short coffee break everyone got up on their feet to put a dot in the radar. 


Containers spider edited


Remaining time of exercise was spent on talking about the graph outcome. These open talks took 45 minutes and was really focused. Really good stuff happened here. I sensed a state of mindfulness in the room and… well… I felt like the people in the room committed to the task in a joint focus, as a single entity. 
You can see the resulting action points in the team radar. However, I believe that most of all we gained insights in how we functioned as a team, and we gained an understanding on why we need to get better!




If you want to read more about CDE model, you can look here. I can also highly recommend the workshop Coaching beyond the team where you get to learn and practice using the CDE model (and lots of other stuff as well).

The Constellations exercise in a distributed setup

A few retros back I asked the team for input on the retrospective; Should we continue doing them? In same manner? Are meetings as rewarding as we could expect?

The response was a bit worrying. At first I only heard silence, though after a some time one or two persons replied that “It works fine” and “We should continue doing them”. Feedback is always good. It’s lack of feedback that is worrying.

The other day, just before it was time for another retro, I read a blogpost from Luis Gonçalves about Constellations as a Set-the-stage exercise. In this exercise the group stands in a circle with some object in the center. Each person moves closer to the center if he/she see value in a specified topic. The more value, the closer you move inwards to the center.

I thought it sounded simple enough for us to try. Since our team is distributed, we had to modify it by letting biggest value be closest to the webcam. If you see a super low value you would be… right, super far away from the webcam.

The thing to measure was formulated as: “How big value do you experience from our recurring retrospective meetings?”

The outcome was very spread out. Some people found the retrospectives very rewarding, saying they learnt a lot and enjoyed trying new exercises. Other people stayed really long way back in the room. One person felt that he had so much other important things right now, so trying out exercises in an experimental way was not working very well for him. Several people argued that the 1 1/2 hours for retrospectives was too long. They argued that it should be possible to manage retro in one hour.


I saw lots of smiles and happy people. But I also saw people showing distress. This was reflected in the outcome as well, since the task was to visualize experienced value of the exercise itself.

Because everyone took a position in the room, each and everyone helped in contributing to the feedback. As you might recall, asking the team and waiting for a reply from someone had not worked.

For myself it got very clear how much it varies in the team about value gained from retrospectives. It was quite a surprise for me to see and the message got really strong in this way of visualizing stuff. It hits you in the gut! (in a good way)

The exercise and the experience from it reminds me of a “human sculpture” workshop that I attended at the AYE 2010 Conference, Steve Smith facilitated. The group took on positions to visualize a difficult situation that one of the team members told us about. One person took on a pose to visualize an angry user, another person visualized an angry co-worker, and so on. Very powerful stuff! Not least for the person getting the situation visualized for him.

Be careful with that Burn-up chart!

This blog series will explain how choice of metrics can help a team in mind shifting from resource utilization towards flow orientation.

The first part is a “lessons learned” story, illustrating why it is a bad idea to focus too much on the burn-up chart.

What we did

The story is that we gathered the team for a Root Cause Analysis. We had opportunity to talk about how to improve our low throughput. From looking at the burn-up chart, showing delivered stories each week, we could see that in the latest three weeks there were not very much delivered.

Burn up, showing weekly throughput of user stories

Burn up, showing weekly throughput of user stories

In addition we looked at a column diagram of fixed bugs. These columns hits the roof over the same iterations. This pattern occurs each time when the company enters the big integration test phase.

Visualisation of correlation between nbr of closed defects and closed user stories

Visualisation of correlation between nbr of closed defects and closed user stories

Starting it wrong with bad formulation of the problem

Me, the team coach, formulated the problem from topmost perspective. I said:

– As we see, throughput of stories has gone down. Let’s talk about this. To start with, is it a problem really?

The reply from team was

– No, I do not think there is a problem. There were some really big bugs and there were some people away these weeks. It is not strange that throughput goes down.

Then there were discussions about the graphs (that the team had not chosen themselves). The team was uncomfortable with that graphs were not showing how much effort was actually put down, and that the graphs did not show the sizes of defects. In addition, the burn up did not say anything about how many people were at work.

I had assumed that it would be clear from the column diagram that we did lots of work but with wrong things. The reason for low throughput was very clear for me, that we had almost completely worked with incidents and bugs. However, I did not hear any comment about that. Not even when I directly asked about it I got any reactions. Focus was instead on the throughput, and what was not shown in the burn-up graph. Now, given how the problem was formulated this is not very surprising, right?

What the problem formulation led us into

It was suggested that we should improve estimates on defects, so that we could visualize clearer what was done in the iteration. To manage this, we introduced shirt-sizes S, M and L. We could use the three clusters on the histogram as reference; S corresponds to cluster around 1 day, M is cluster around 6 days and L is cluster around 10.5 days.


Distribution of cycle times for defects

But wait a second here… Defects are re-work! We would be better off if they were not occuring in the first place. Instead of aiming at reducing waste (defects), we ended up with doing more wasteful work with estimates for the defects.

Let me say that again: Because we focused on throughput from the team (resource utilization), we ended up with adding non-value-adding time to our waste of re-work. #fail 🙂

Summarizing the meeting

We did not manage the RCA exercise, we lost track of the flow principles and we added more waste to our process. I closed the meeting, summarized the results and said “We need to meet again”.

Lesson learnt

I think we got on wrong track already from start, because of the visualization of the burn-up chart. Maybe, if I had instead visualized delivered stories vs incidents and bugs, the discussion could have been more driven towards removing waste.

Next meeting (and blog)

On next meeting we will bring some value-added-time graphs and put up a question formulated in a bit more guiding way:

– How can we improve value-added-time ratio?

Who lives will see…

Laughter Yoga on retrospective

This writing is to share a super simple exercise that could give your team a big boost.

Laughter at the office

Some seasons ago I worked in a big open-space office, with lots of Scrum-boards and teams. There was one stand-up with around 20 people occuring each morning that really fascinated me. What they did was that they ended meeting by raising their arms up in the air and then laughing out loud! Wow… What a great way to start the day! There was a guy with a turban who facilitated this.

Adopting to our team

Today I am in another office, Kanban coach for a team of 7-10 people, including requirement people, testers and developers. We work distributed, half team in Stockholm, Sweden and one half in Delhi, India. We have recurring retrospecitves every second week. We practice the five-stage retrospective from Esther Derby and Diana Larsen’s book “Agile Retrospectives”.

The other day I asked a team colleague Ashish (from India) about this thing I had seen with the laughing team. Ashish explained that it sounded like Dr. Madan Kataria’s Laughter Yoga and that it is a well-known thing in India.

This reminded me of something Andy Hunt predicted on a seminar 2006 (almost ten years ago!!): “In the future, each office will have 15 minutes of yoga at work”.


Dr Kataria in action

(photo: UP)

So, on the next retrospective I suggested to the team that we could try to do some laughter. I explained what I had witnessed, and said I would like us to try it. “So please follow the facilitator’s instructions” I said (giggles and scared looks), I raised arms and did some laughing. Kamal, one of the developers that is also from Delhi, commented that you are supposed to inhale before exhaling and laughing out. He said that it is a Yoga exercise and that it should be repeated five times. We settled with two and went on with it. We did this in the “Set the stage” phase.

Why do something like this?

There are lots of studies out there about the good effects of laughter. Even a smile does lots of things, to yourself and your environment. In addition, when laughing out loud together with the people you work with everyday you will (likely) get a great feeling in the team. It’s fun in the moment, you have enough value right there! But then something also happens to you when doing this. I cannot put the finger on it, but it is like you get a good will, a peaceful intention, from the people involved.


If you are, like me, not very familiar with Laughter Yoga, you might want to check some of these links:

Here’s the retrospective all together:

Set the stage
Dr Madan Kataria’s Laughter Yoga (5 mins)
– stand up
– inhale and raise arms up in the air
– exhale and laugh out loud
– repeat 1-4 times

Gather Data 
divide up in teams of 3 in each. Have smaller group discussions on things that went well and can be improved. Write ideas down on post-its (20 mins)

Generate Insights
Present for the team the two most urgent issues from the group talk (20 mins)

Decide what to do
(20 mins)

Summarize results
(10 mins)

Do not forget not to tell the “what”

Frida (daughter) and I did some Wii gaming last night. I felt we had done some great progress so we should save the game. Therefore I said:

“I think it’s time to save.”

And she did. Then the screen went black.

“Nooo! What happened?”, I said angstly.

Frida had interpreted me as if it was time to take a break; to save and then turn the game off.

Aha! Since I was too lazy to tell the “why”, but instead only told the “what”, she was led to misinterpret my intentions. Which she did, and consequently acted there on. Lack of communication led to wrong implementation!

An alternative way of saying same thing, but instead sticking to a “why” for the situation:

“If the game crashes now we would need to do all the stuff we just did again.”

I guess it wasn’t such a bad idea to shut the game off, since we had been doing this gaming for quite some time. But what if turning the game off had been a silly idea? We might have ended up with a somewhat bad team spirit :´-(

Communication is king!

PDM in Scrum, part 3: The tree metaphor, revisited

continued from part 2: PDM core values

Once at a seminar I asked if anyone knew what empowerment meant. No one knew! Why is empowerment fundamental to agile? One way to show this is to look at the opposite: 


Inspired by Esther Derby’s drawing here, this is what I came up with. With visualization like this you can ask if empowerment would make a difference to your efficiency.

High Performance Tree

Lyssa Adkins showed us how to communicate core values using the High Performance Tree metaphor. Read about it in the excellent and very useful book Coaching Agile Teams, or watch it live on youtube. Nail up a High Performance Tree on the wall, explain how endeavouring the PDM values (tree roots) yield effects of stronger people, stronger group and stronger agreements (tree branches). These effects will in turn give us more ideas, better ideas and so on (fruits). To see all the fruits in full bloom, so to say, you might want to revisit the tree in part 1.

Team Radar

Team Radar, from zero in centre out to ten. Lines connectiong points.

The Team Radar is a simple procedure that helps tracking team progress toward values. You can visualize where the team feels it stands today, and you can reason on how to improve towards your values.

– What could be improved the most?

– Is our understanding of where we are different? Why?

– How can we improve?

The illustration shows a radar where each team member has marked four dots on the axes, for where he/she thinks the group is living up to the values. The low score on shared responsibility suggests there could be an issue with specialized roles.


With this setup you now have the tools to review and measure progress. Do a new radar in next iteration and see how progress is going, or even better,  try other new innovating excercises! Refer to the tree metaphor, and don’t forget to enjoy the fruits from it!

PDM in Scrum, part 2: PDM core values

continued from part 1: Elevating empowerment

Why all this Core Values talk?

Why talk about values? Why not just say what people should do? It would be much easier! In Scrum that would perhaps sound something like this:

– We have four meetings, three artifacts, three roles, and some rules to tie this together! 

When you head on like this without any motives you are very close to a stick-and-carrot leadership style. It’s not that you don’t need to teach rules and methods (like above), but it will not be enough if you want your teams to get empowered.

Shared goals

So, in addition to the above we need to raise questions about how we do our work. Consult the people involved. Question the tools used!

The steps to reach a shared vision (Senge, et al. 1994)

– Why are we doing Scrum?

When you reason around the values and possible benefits from those, the methods gets justified. Also, people might see ways to modify the tools and methods, to something more suited for their context. This will make people feel more engaged, motivated and hence become more empowered.

This will help you to gain some steps on Senge’s ladder to a shared vision (even though we’re not working with shared visions explicitly in this topic).

PDM Core values

Ok then, enough of all this meta-talk. We want team to get more empowered, and we want to know how to apply PDM to do this.

In Sam Kaner’s book Facilitator’s Guide to Particitatory Decision-Making you’ll find four PDM core values.

  • Full participation: all members in the group are encouraged to participate
  • Shared responsibility: all people in the group feel responsibility for the decisions being made
  • Inclusive solutions: everybody’s perspective are taken into account to get wiser solutions
  • Mutual understanding: people needs to understand each others needs and goals to get stronger agreements

Great! This allows us to get started the right way! The PDM core values helps us to get motives for working with PDM, and in turn PDM will get us more empowered with the rest of the stuff we do.

(We obviously did not quite get out of the Nine Circles of Meta, did we? Just bare with me, we will soon get to the fruits of this.)

Next: PDM in Scrum, part 3: The tree metaphor, revisited