Team Emotional Flow

February 12, 2019

The morning begins with everyone arriving at the office and gathering in the kitchen. The whole team is works together, there are no remote workers. As folks grab coffee and maybe toast a bagel, there is casual banter about the game the night before, the kids performance at a school play, and plans for an upcoming barbecue.

When the last member of the team arrives, they all gather round into a circle looking at one another. There are a few mumbled “good mornings” and one member starts off with, “I’m feeling excited, we are going to get to integration test the system for the first time today. I think the plan is to start around 10:00.”

There are a few raised eyebrows and then a question or two as folks sync up. The next person in the circle says, “I’m feeling frustrated this morning. The work on the UI hit a stumbling block last night, and I hate leaving work with an unresolved problem.” Someone else chimes in with, “Me too! Let’s pull the mob together and see if more brains can help us nail this problem this morning.” There are general mumbles of assent from the group and the process continues with the next person, “I’m feeling glad that we’re making progress. I think I know what is causing that problem, so I’m looking forward to sharing a potential solution.”

And so it goes, each after the other. The format is relatively loose: You always start with sharing a feeling, then follow up with any resistance you may be encountering. The emphasis is on keeping the interaction casual and not forcing anything. There is no pre-defined leader. Everyone has agreed that this kind of sharing is important and they support it as needed.
At the end of the meeting, everyone updates their feeling status on a whiteboard. They track their feelings on a daily basis so that they can see trends in their overall team mood. They work together as closely as possible. They use mob programming to do their work together whenever possible. The focus is on sharing their experience together.

One tool they use to keep themselves aware of the emotional flow of the team is frequent use of the “check in”. The check in is taken from Jim McCarthy’s core protocols. The idea is to declare your emotional state at the beginning of significant meetings and interactions. This helps to make emotion visible to everyone and gives important needed context for others who you work with. You simply state your current emotion: I feel Mad, Sad, Glad, etc. It lets everyone know where you are at and helps the group to synchronize emotionally. It doesn’t have to be rigid and highly formalized. I think that depends on the character of the team. I personally prefer a casual but disciplined approach (always do it, but let the language be natural and informal rather than highly structured and rigid).

I offer this as an alternative to the traditional standup. We don’t track work, we track feeling. We focus on achieving emotional flow. We don’t use a rigid system of pre-defined questions that must be answered. We flow.

Those are Not MY Impediments!

September 5, 2014

Army Boots Stand Out in a Crowd









When trying to find impediments there is a trap that awaits those of us who are outside of or observing the team. Often, when you are observing a team as an outsider, you may think you see patterns of behavior and obvious disfunction. Naturally enough, not being part of the system often gives us a fresh perspective from which to see problems within a team. Often I have found myself able to rattle off a list of issues that I see a team dealing with after observing them for only a few minutes. Some patterns of team disfunction are suspiciously easy to detect. But wait, here comes the trap. So you make a list, maybe write up a few recommendations and share your “gift” with the team. What team wouldn’t appreciate someone kind enough to share a list of all the ways they suck?


It doesn’t matter if you are right (and you probably are at least 50% of the time). Best case, the team thanks you for your honesty. Worst case, they kick you out of their standup and tell you never to come back. In any case, they aren’t very likely to take your suggestions seriously. The thing about impediments is, in order to really own them and take them seriously, they need to be something the team genuinely care about – and most likely they should be the team’s idea. Ownership is important, because often impediments are pretty tough to deal with, so you need to be really committed if you expect to resolve them.

Often, what I think I see are two different lists of impediments: the scrum master, coach or manager’s list, and the team’s list. The scrum master is scratching their head wondering, “How can I get these guys to engage with these impediments?” Meanwhile, the team is thinking, “Do you really want to eliminate an impediment? Fire a scrum master!”

So I guess the lesson here is that often nobody is all that interested in what you think the impediments are. They already know what the impediments are. They’re just waiting for someone to really listen.

Finding Your Voice

May 3, 2011

When some people transition from traditional project management to Agile, they seem to lose their voices. These are people who had great, strong, passionate voices. People who felt they were engaged and empowered to lead their teams to success. And then some consultant comes along and tells them that they got it all wrong. The wise consultant tells them that they are part of the problem and need to change their evil command-and-control ways. They need to be a servant leader – one of the most poorly defined roles ever conceived. Guess what happens to these poor bastards?

They get confused! They don’t know what their job is supposed to be. Everything they used to do is suspect, part of that horrible “waterfall” thing. And now they have a team of people who have been told just how evil they are. Nobody trusts you. Why don’t you just remove impediments and stay out of the way? Don’t call us, we’ll call you. If we need you. You don’t code, so you’re not really that relevant anyway.

Soon people are asking questions: where is the leadership? Why won’t these weak Scrum Master creatures take responsibility for the project? It’s the team’s job? That’s funny, I don’t see the team stepping up…and so it goes. Now everyone is confused. What has happened to that rich voice that guided the team? Now it’s a timid peep. It’s a pale, skinny shadow of what it once was.

And so the journey begins. We sit back, watch the chaos ensue and ask ourselves, is this really my job anymore? I’d do it differently, but apparently I have to say it differently too. What should I say? Meanwhile Rome doesn’t exactly burn to the ground. Not exactly. In fact, people make approving noises. Things are better now…aren’t they? After all, we spent 100 grand to get here. Look at our metrics!

At some point, things start to go wrong for the team. Nobody steps in. The pressure builds. The Scrum Master looks around and thinks to himself, isn’t somebody going to do something? The pressure builds some more. Still no action is taken. And then the levy breaks and there is the voice! The voice that demands resolution. The voice that won’t accept mediocrity. A voice that communicates a clear and compelling vision.

Why do we do this to ourselves? Maybe it’s a journey that we all need to make. Perhaps there are no shortcuts. Maybe it was just me hearing voices again.

Moving People Between Teams

December 23, 2010

So, let’s pretend that you are working someplace where you have two or more teams working on development projects. Furthermore, let’s say that those teams have been in the same configuration (same folks doing the same thing) for 3 or more years. Things might start to get a little stale right? Teams might start to get a bit isolated, each focusing on their own areas of domain expertise. You might find it very difficult to introduce change in this kind of environment – in fact, I can almost guarantee that people will tend to resist change in a scenario like this.

So then I wake up screaming in the middle of the night.

Wait…we’re not talking about me. Really. So this “friend” of mine thinks he has a problem and he wants to stir things up a bit. The idea is to start moving people between the teams. People get experience with different domains, different teams, different technologies, etc. So what strategy should you use that will provide some structure for this type of team swapping that won’t seem totally arbitrary and capricious and will be respectful of the people involved? So I had a few ideas that I shared with my “friend”:

  • Musical Chairs: everyone swaps one seat on the team, if you don’t have a seat you go to another team


  • Playground Picking: just like picking teams for kickball, every once in a while you get everybody together, pick captains, and let them select their own teams

  • Core + Float: keep “essential” people on the team together, and give journeymen on the team the opportunity to work with whichever team they like

  • Sprint Rotations: each sprint, rotate a different person on the team to another team.

How would you stir things up on your teams?


Bad Programmers

May 23, 2010

There was an article in the CACM recently that caught my attention entitled, “In Praise of Bad Programmers”

Still here?

Apparently the provocative  title really sets off some fire alarms for people. I shared the article, which I personally thought was great, with a team and we discussed it together. I thought the whole conversation went really well and I thought it felt very productive. Afterward, I discovered that everyone in the room had apparently been thinking one thing: “He thinks I’m a bad programmer”. I’m not sure they recalled any of the conversation after reading the article. In fact, I’m quite sure they didn’t.

That reaction probably says a few things about us:

  1. We don’t feel safe talking about our skills with each other
  2. The team felt some sort of judgement was being made by me
  3. How you frame the conversation really does make a difference

Having done this sort of thing for a while, none of the above particularly shocks or surprises me. It’s just a reminder that some conversations with teams are harder than others. You don’t avoid them, but you need to be prepared to set the stage well before the conversation, make sure the team feels safe enough to deal with the conversation, and have a way to check in with them afterward to make sure your read on the conversation isn’t incorrect.

Oh, and if they’re still angry after all that, then it’s really their problem. I’m a coach not a therapist.

Exploring The Project Jungle

January 14, 2010

Grab your pith helmet and join me for a little journey. Shhhh! Be vawy, vawy quiiiet, we’re hunting for projects! We move through the jungle with exaggerated stealth, placing each booted foot with care. We stop before a bank of thick fronds and I gently part them. On the other side lurks a horrifying creature: a man sitting alone at his desk staring intently at a monitor. I stifle a scream.

Our programmer (Mr. Livingstone I presume?) is obviously engrossed in something interesting. Every once in a while he starts typing furiously, keys clattering at an astounding rate – and then he stops. This pattern repeats itself over and over. You look around at his environment: his desk is clean, his walls have a few quick reference cards taped to them. Maybe a picture of the kids. Just your standard programmer – usually found in isolation, seldom socializing, and rarely breeding.

But wait! If we look a little closer some interesting details are revealed: it turns out that he has an IM client open on the monitor. He’s actually collaborating with someone! Furthermore there is a row of telltale lights in his task bar that keep him informed of the status of all of his continuous integration builds. Wow! This guy has a lot more going on than is revealed at first blush. I wonder what else is going on here…This is obviously a workspace that is oriented around the electronic screen. That’s natural enough in the software business. What about the wall space, why isn’t that space being used more?

I love sneaking about the office and looking at what other teams are doing.  You can find the most amazing things. Teams using different techniques, alternate presentation of the same material, etc. There is a rich supply of ideas lurking in those other teams. Go ahead, steal one of their trash cans and rifle through it. What are they doing that you might benefit from trying out? I’m not talking about espionage here…OK, maybe I am. The point is, there are a lot of things we can learn from the other teams that we work with.

What can be a lot of fun is to take others along on the hunt with you. Get the team together as a group and act as their guide. Don’t forget to get them hats too.  Sneak up on other teams and observe where they live and how they behave. When I do this, we debrief together after observing each group. The debrief is an opportunity to ask some great questions:

  1. What did you see?
  2. What did you hear?
  3. How is it different from where we work?
  4. What do you like/dislike?
  5. What can we steal?

Each of these questions can serve to bring up some great conversations about how you work together as a team. Then you can follow up by returning to your own work area at the end. Don’t just pile back into the office though – take a moment to observe your own work area. What does it say about you as a team? Usually at this point the team is primed to re-evaluate the way they work, the way their area is organized, etc.

So have a little fun and try out becoming a Project Anthropologist. It’s a fun and gentle way to open up the conversation regarding how the team works and how it is organized. And you get to spy on your co-workers. What could be better?

What I Learned From My Daughter’s First Grade Classroom

September 10, 2009

The new school year is beginning and my daughter is starting first grade. I had an opportunity to go to her elementary school open house the other day. A word to the wise: never let an Agile development geek into a first grade classroom. I thought I had died and gone to information heaven. I took a camera with me and took some pictures of the kinds of information that they put on the walls in a children’s classroom. It was amazing! In the meantime, my wife fervently denied that she was with the dork taking all the pictures of the walls. Here’s what I discovered before I was escorted from the building:


The first grade classroom is the prototype for a learning environment. These folks are the undisputed masters of the information radiator.  Everywhere you look there is information being displayed. The variety of different kinds of information displayed is amazing! The density of information here is incredible! In one corner of the room I see the following information:

  • Monthly calendar
  • Weather graph
  • Password(???)
  • The alphabet
  • A tally of how many days they’ve been in school
  • Numbers from 1-10
  • Days of the week
  • A chart of all numbers from 1-200
  • A list of who has lost a tooth (Try that on your team! If the number is greater than five, you may be working in a biker bar)
  • And a few other things I can’t quite interpret

What else can we see going on here? Well for one thing, there is LOTS of color. It catches the eye, calls attention to certain details, and livens things up quite a bit. It’s like an interior decorator went nuts in the place. Next, you may observe that much of the information is presented using multiple modalities. Multiple modalities? OK, they use pictures AND words AND color AND shapes. A lot of effort is being made to transmit information in a variety of different ways. Now, just for giggles, what if you were going to put together this exact same board for your team at the office? What would it contain? Here’s how I might do it:

  • Monthly calendar – team vacations, releases, events, barbecues
  • Release graph – How many releases per week are we doing?
  • Word of the day (“Spurtle” – yeah, it’s a word)
  • A quick reference containing all of the major Ruby commands (pick your API/Language, etc)
  • A tally of how many days they’ve been working on a project/sprint/release
  • Numbers from 1, 0 (hey, it’s computer science, you only need two numbers!)
  • List of major business holidays (they always sneak up on me)
  • A chart of all error codes used in our project
  • A ladder of World of Warcraft names/rankings

Hmmm. That’s actually not a bad list. Give it a little color, play with the “modalities” and I just might have some pretty compelling information there. I wonder what else the first graders have to teach us? How about this:


I see at least three things here that I could try out with my team back at the office. First, there is information about today: we have the date, and then  below it is the day’s schedule. Now, I don’t know about you, but back at the office, I don’t have anything like a daily schedule posted on the wall with my team. We all have outlook, and perhaps some would say that’s enough, but for me it’s not quite the same. Outlook reflects MY schedule, not the team’s schedule. And there are significant team events that could use some advertising: Planning meetings, releases, retrospectives, reviews, scrum of scrums, and so on. I know that where I work, everyone is left to their own devices to manage these things and show up or not. Nothing wrong with that, but what if we had a daily schedule, a reminder if you will, that sat next to our task board at our standup meeting? Frankly, I think it might be useful. As a scrum master, it might be a way for me to rather subtly remind the team of the big commitments for the day. Or not.

Let’s move on from the schedule stuff. What’s up with the bottles of ketchup, mayo, and mustard? OK, it may be a little cheesy, but if you look at the image closely you will see that these are clever little symbols for “Catch-Up”, “May Do”, and “Must Do’s”. Do you track Catch-Up work on your team? No? Me either…wait a second…we do keep a list of technical debt. Isn’t technical debt a kind of  Catch up work? So keeping that list of catch up items makes a lot of sense to me. Also, the “May Do’s” and “Must Do’s” make a lot of sense to me as well. I think that defining work as “Must Do” will help the team prioritize the work that is most important (assuming you don’t abuse it) and the “May Do’s” gives the team the ability to identify the things that are available to be pulled on their own initiative. Adding may do and must do to a team’s daily activities would certainly be interesting to try out. I can see pros and cons to doing it. Maybe we could even use these criteria to categorize our backlogs? It’s a possibility…

How about the noise level trumpet off in the corner there? In the wonderful Agile Open Space that you work in, do you ever have issues with noise? Here is your answer! I wonder how well that actually works in a room full of first graders? OK, I’m not going to give them grief for this – it’s probably an experiment.

Here’s another gem that I captured before being chased out of the room by a rather menacing looking old battle axe with a broom (where DO they get these people?):


Would you look at that! They use the “Fist of Five” in first grade too! I was wondering where that technique came from! I need a copy of this poster for my team!


Ooh! Look here! They are graphing their moods over time! Cool! I’ve seen other teams do this, but I’ve never tried it myself. It seems like an idea with some real merit. It certainly makes sense to track the teams mood. It would be very interesting to review information like this at team retrospectives. It would certainly provide an interesting metric to compare against recent “improvements” or other team experiments. One other thing I want to point out here: these teachers seem to think that these information radiators are so important that they will try and cram them just about anywhere! Anyplace is game: the backside of a bookshelf, the side of a locker, the face of a cabinet – any place they will fit. Look around your office. Are you using all the space you have available?

Here’s a quick challenge: So what do you think this is?


Well, as my daughter ever-so-patiently explained to me, this is their “Job Wall”. I like the beehive image – after all we Agilista’s like to “swarm” don’t we? It seems that everyone has regular tasks that they are responsible for. These are tracked here. I like the way it makes responsibilities explicit for everyone involved. It makes me wonder where the teachers get all this stuff? Of course if I were to show up with this silly little beehive, I’m pretty sure that the team would laugh me out of the room. Of course that never stopped me in the past…

You know, if they ever  lift the restraining order and let me back on school property again, I’m definitely going to take some more pictures of the classroom walls. How come more offices don’t look like this? Why aren’t the environments we work in as information rich as the ones that children work and play in? I presume that in the office we are learning too, right?