Learning Games

June 22, 2009

What’s up with the cupcakes? So there was this wacky little session at Agile Roots 2009 that I really enjoyed that was put on by Chris Sims. It was called “Agile Learning Games”. It was one of those sessions where everyone gets to try out the games as a participant and get a feel for the kind of learning that takes place. I loved the games that he chose to demonstrate, and he was kind enough to provide some references for places that you could look for more learning games – one of which was called, “TastyCupcakes.com”.

I think these learning games are very useful because they allow teams/groups to experience or play with an idea rather than having it preached to them by some sort of expert. I find that I learn things much better when I can participate in a hands on fashion. So as a facilitator and coach, I find these kinds of exercises to be especially powerful when working with teams.

These games can form an important part of any facilitator’s toolkit. I’ve been collecting a list of sites that catalog these learning games for a little while. Here are some references that you might find useful:

http://blog.tastycupcakes.com/

http://uoleadership.uoregon.edu/exercises/energizers

http://www.businessballs.com/teambuildinggames.htm#leadership%20management%20exercise%20for%20teams

http://www.squarewheels.com/scottswriting/mission.html

http://www.nasaga.org/

http://industriallogic.com/games/

http://www.funandgames.org/Games_icebreakers.html#2TruthsAndLie

http://www.isnare.com/?aid=193973&ca=Business+Management

The tastycupcakes site has games that are most relevant to Agile Development, so I would start there first. This list is by no means comprehensive, but if you are looking for some games that might help you get an idea across, this list should get you started.

Advertisements

Understanding “There Is Only Us”

June 19, 2009
This was a panel discussion with some remarkable names in the agile community including Alastair Cockburn, Brian Marick, Diana Larson, Israel Gat, Polyanna Pixton, and a few others. Much of the discussion was about the role of trust on Agile teams. This topic resonates for me because I have recently started to look for trust issues on teams *before* I look for whether or not they have adopted agile practices. Without trust, the rest is hard to do. When there is an issue with trust on a team everything slows down. It creates a kind of social friction that makes even the simplest tasks more difficult. Team members who don’t trust each other will argue more, revisit old disputes, avoid supporting each other, and even go out of their way to undermine each other. Simple issues that should be resolved by the team end up getting blown out of proportion and escalated to management on a regular basis.
The amount of distraction and friction that is created can be really quite stunning. I don’t profess to have any superior insight into trust and team dynamics – I suffer the same disfunctions here as anyone else. But when I find a team that at a fundamental level is having obvious trust issues, then I know that as a Scrum Master or Coach, I’m in for a rough ride. Nor do I have any particular insight into how to solve the problem. I know that making the team do trust falls probably isn’t going to resolve anything. If I’m honest, I’ve failed as often as I’ve succeeded when it comes to dealing with trust issues on teams.
There are few things that I need to remind myself of when in a situation where there is a paucity of trust:
1) This is going to take a long time. Short of firing people, trust issues don’t go away overnight. While sometimes there is merit in removing someone from the team, for the sake of this discussion I will focus on the more constructive aspects of working with a team to build trust.
2) If you are just starting with the team, you have to become just another member of the team. Often when I start with a team, I often find myself using terminology that separates us. “They” have problems. “I” will fix “them”. Now you might fault my language, but to me language like that simply tells me that I haven’t yet fully integrated with the team. I have to move from refering to “them” to talking about “us”. That takes me a while. I have to live with the team, work with them for a while and basically become part of the team ecosystem. I need to “go native” and stop looking at them like an outsider.
3) You have to be willing to make and admit mistakes – a lot of them. Things will get messy when you are dealing with trust issues. I want the team to see that I’m just as committed, dedicated, messed-up and neurotic as they are. It’s a hell of a lot of work. But if you can open up and be vulnerable in front of the team in some small way, I think you win the trust of the team that much faster.
4) In a very real way, what I’m trying to do is get them to trust me, even if they don’t necessarily trust each other. Part of the game of being a coach is becoming a connector for people. Helping them to find other people who can help them out. If they can come to trust me a little, then I can begin to connect the dots and point them to others on the team who also trust me – a little.
These are the kinds of things that are going through my mind when I’m working with a team that appears to have significant trust issues. I’m looking for connections, seeking ways to hilight my own mistakes, watching my language for symptoms of “me” and “them” and most of all, being very patient. I make no claim to to any sort of stunning insight into these issues. However, I’m a little surprised to see how much I have to say on the topic!
These were the thoughts that were rebounding about my skull as I was listening to the panel talk about the myriad issues surrounding trust on Agile teams. It was a good discussion and I almost wish I could have joined in the conversation they were having. At first I didn’t really understand the title of the discussion, “There Is Only Us” (how weird!), but perhaps now I understand it better. For me, working with a team is best when it is not “me” and “them”, but rather when “There Is Only Us”.

There was an interesting panel discussion on the first day at Agile Roots 2009 that included some remarkable people in the agile community including: Alastair Cockburn, Brian Marick, Diana Larson, Israel Gat, Polyanna Pixton, and a few others who deserve mention but their names escape me. The title of the session was “There Is Only Us”. I thought it was rather peculiar title. Much of the discussion was about the role of trust on Agile teams.

The topic of trust resonates strongly for me because I have recently started to actively look for trust issues on teams *before* I look for whether or not they have adopted agile practices. Without trust, the rest is hard to do. When there is an issue with trust on a team everything slows down. It creates a kind of social friction that makes even the simplest tasks more difficult. Team members who don’t trust each other will argue more, revisit old disputes, avoid supporting each other, and even go out of their way to undermine each other. Simple issues that should be resolved by the team end up getting blown out of proportion and escalated to management on a regular basis.

The amount of distraction and friction that is created can be really quite stunning. I don’t profess to have any superior insight into trust and team dynamics – I suffer the same disfunctions here as anyone else. But when I find a team that at a fundamental level is having obvious trust issues, then I know that as a scrum master or coach I’m in for a rough ride. Nor do I have any particular insight into how to solve the problem. I know that making the team do trust falls probably isn’t going to resolve anything. If I’m honest, I’ve probably failed as often as I’ve succeeded when it comes to dealing with trust issues on teams.

There are few things that I try to remind myself of when in a situation where there is a paucity of trust:

  1. This is going to take a long time. Short of firing people, trust issues don’t go away overnight. While sometimes there is merit in removing someone from the team, for the sake of this discussion I will focus on the more constructive aspects of working with a team to build trust.
  2. If you are just starting with the team, you have to become just another member of the team. Often when I start with a team, I often find myself using terminology that separates us. “They” have problems. “I” will fix “them”. Now you might fault my language, but to me language like that simply tells me that I haven’t yet fully integrated with the team. I have to move from refering to “them” to talking about “us”. That takes me a while. I have to live with the team, work with them for a while and basically become part of the team ecosystem. I need to “go native” and stop looking at them like an outsider.
  3. You have to be willing to make and admit mistakes – a lot of them. Things will get messy when you are dealing with trust issues. I want the team to see that I’m just as committed, dedicated, messed-up and neurotic as they are. It’s a hell of a lot of work. But if you can open up and be vulnerable in front of the team in some small way, I think you win the trust of the team that much faster.
  4. In a very real way, what I’m trying to do is get them to trust me, even if they don’t necessarily trust each other. Part of the game of being a coach is becoming a connector for people. Helping them to find other people who can help them out. If they can come to trust me a little, then I can begin to connect the dots and point them to others on the team who also trust me – a little.

These are the kinds of things that are going through my mind when I’m working with a team that appears to have significant trust issues. I’m looking for connections, seeking ways to hilight my own mistakes, watching my language for symptoms of “me” and “them” and most of all, being very patient. While I have no claim to expertise, I’m a little surprised to see how much I have to say on the topic! Funny how that happens.

These were the thoughts that were rebounding about my skull as I was listening to the panel talk about the myriad issues surrounding trust on Agile teams. It was a good discussion and I almost wish I could have joined in the conversation they were having. At first I didn’t really understand the title of the discussion, “There Is Only Us” (how weird!), but perhaps now I understand it better. For me, working with a team is best when it is not “me” and “them”, but rather when “There Is Only Us”.


How I Discovered “Gordon The Guided Missile”

June 18, 2009
Alastair Cockburn gave the opening keynote speech for the conference. He mentioned that the conference was a product of a local user group called the Salt Lake Agile Round Table. I looked it up and here is where you can find more information if you are interested:
If you live in Utah, you are very lucky to have a high powered group like this around. You can also find likes to other agile groups in the area as well as their mailing list. There are a whole bunch of them in the Salt Lake area. I’m thinking I may have to create another one here in Seattle just for the fun of it!
Alastair started off with a story called “Gordon The Guided Missile” that was originally told by John Cleese. It is a marvelous tale and you can find it here: http://www.contextmag.com/archives/199806/innerGame.asp?process=print
The point of this funny little yarn is that making many little mistakes is OK. In fact it is necessary in order to make the adjustments necessary to succeed. As Cleese points out, you can’t say, “Well, I got that right, so now I’d better fix it.” It’s ridiculous. Cleese urges us to rediscover a sense of playfulness with our ideas that will allow us to be creative.
Now I don’t consider myself a particularly playful person. I can be downright stodgy at times. But I love creativity. Maybe that’s why I like software development so much. Writing code, what I like to think of as creating “castles in the mind”, requires us to create dazzlingly complex logical structures using only 1’s and 0’s.
So for me it comes down to this: If these ethereal software structures are a product of creativity, and if creativity is a product of playfulness, then we software developers need to get out and play more! And John Cleese, in his own wonderfully silly fashion provides some tips on how we might do this:
1) Admit mistakes freely. In our particular community of development process fanatics, this means that we need to create a safe environment where this can be accomplished. Scrum, XP and other Agile methods have “built in” this support for discovering and admitting mistakes.
2) Fight the tendency to identify with ideas. This is essential for fostering collaboration on a team. When we identify too closely with an idea it becomes harder to share it with others.
3) Create an atmosphere of tolerance of mistakes by becoming a model. Discuss your mistakes. Share them with others. Who knows? Your mistake could be the genesis of the next great idea.
The rest of the keynote was quite good, but  “Gordon The Guided Missile” was definitely my favorite part!

Fireworks_Rocket

Alastair Cockburn gave the opening keynote speech for the Agile Roots 2009 conference. He mentioned that the conference was a product of a local user group called the Salt Lake Agile Round Table. I looked it up and here is where you can find more information if you are interested:

http://alistair.cockburn.us/Salt+lake+city

If you live in Utah, you are very lucky to have a high powered group like this around. You can also find links to other agile groups in the area as well as their mailing list. There are a whole bunch of them in the Salt Lake area. I’m thinking I may have to create another one here in Seattle just for the fun of it!

Alastair started off with a story called “Gordon The Guided Missile” that was originally told by John Cleese. It is a marvelous tale and you can find it here:

http://www.contextmag.com/archives/199806/innerGame.asp?process=print

The point of this funny little yarn is that making many little mistakes is OK. In fact it is necessary in order to make the adjustments necessary to succeed. As Cleese points out, you can’t say, “Well, I got that right, so now I’d better fix it.” It’s ridiculous. Cleese urges us to rediscover a sense of playfulness with our ideas that will allow us to be creative.

Now I don’t consider myself a particularly playful person. I can be downright stodgy at times. But I absolutely love creativity. Maybe that’s why I like software development so much. Writing code – what I like to think of as creating “castles in the mind”, requires us to create dazzlingly complex logical structures using only 1’s and 0’s.

So for me it comes down to this: If these ethereal software structures are a product of creativity, and if creativity is a product of playfulness, then we software developers need to get out and play more! And John Cleese, in his own wonderfully silly fashion provides some tips on how we might do this:

1) Admit mistakes freely. In our particular community of development process fanatics, this means that we need to create a safe environment where this can be accomplished. Scrum, XP and other Agile methods have “built in” this support for discovering and admitting mistakes.

2) Fight the tendency to identify with ideas. This is essential for fostering collaboration on a team. When we identify too closely with an idea it becomes harder to share it with others.

3) Create an atmosphere of tolerance of mistakes by becoming a model. Discuss your mistakes. Share them with others. Who knows? Your mistake could be the genesis of the next great idea.

The rest of the keynote was quite good, but  “Gordon The Guided Missile” was definitely my favorite part!


Day 2 of Agile Roots Conference

June 17, 2009

I did my “Impediment Hunting” presentation yesterday and had a blast! I’ve put a copy of the presentation up on the Papers/Presentations tab if you want to take a look at it. It’s a big download. I have to say that this conference exceeded my expectations in every way! I’m still digesting it all. A huge “THANK YOU!” to the entire team that put the conference together!


Day 1 of Agile Roots Conference

June 15, 2009

This conference has an awesome speaker lineup for its relatively small size (~200). It’s really great! Great first day. Lots of notes. I’ll have to take some time to try and synthesize some of it and share. My presentation is tomorrow, so I’d better get my beauty sleep!


Technical Product Owner

June 2, 2009

So here’s the problem: Some teams have stories that are very “technical” in nature. By technical I mean that these stories are usually development oriented (in language, and in subject matter) and they are hard to relate to direct customer value. Often these stories are related to maintenance activities that have a strong perceived need to be done by various stakeholders, but are not explicitly requested by our external customers. Some examples include:

  1. Stories requested by operations
  2. Stories that have to do with infrastructure improvements
  3. Stories related to technical debt

In some cases product owners have a real problem working with these stories. They complain that the stories refer to technologies or acronyms that they don’t understand. They maintain that they are a customer advocate and don’t care what the details are – just fix it. They don’t know how to judge when these stories are done.

To address this problem we have created a sub-category of product owner that we call a “technical” product owner. If you are starting to feel a bit squeamish at this point, I don’t blame you one bit. So who is a technical product owner? In this case it is usually the development lead for the team – or perhaps a director of development.

The solution is a well intentioned one, but there are consequences. The problems with using a “technical product owner” that I see in practice:

  1. The technical PO has no connection with the rest of the Product Management/Business/Customer organization. This basically sets the team up to operate without having to deliver value that the rest of the organization recognizes. It seems to aggravate silos within an organization.
  2. The Product Management (PO) team gets to ignore important decisions regarding the maintenance and upkeep of business systems. When you buy the car, you need to be responsible for it’s upkeep. All too often I know PO’s who refuse to address technical debt when it is brought to them. Instead they prioritize new features higher – sooner or later it comes back to haunt them.
  3. Teams get out of the habit of working with user stories that customers can relate too. Or they take perfectly good user stories and break them down into “technical stories”. There are all sorts of reasons this happens to teams – but we don’t want to codify the practice by creating a special “technical PO”.
  4. It can reflect an organization’s unwillingness to organize projects that are aligned across the organization rather than within technical silos.

Personally, I think that we should be able to put all stories – regardless of where they originate into terms that anyone can understand. Failure to do that may lead you down a path that leads to the “Technical Product Owner”. Watch out.