What I Learned From My Daughter’s First Grade Classroom

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?

Using Lean Techniques to Improve Your Presentations

I’ve found myself applying lean techniques to some of my writing and presentations. Here are a few of the techniques I’ve used:

1. Splitting large things up into small batches: This one is a beauty. Queue theory tells us that when processing work, lots of small batches are easier to process than a smaller number of large batches. All too often in my writing and in my presentations I tend to unconsciously go into “Large Batch” mode – the document gets larger and larger and I start to lose the tight cohesiveness that you would find in a smaller document. As the presentation or the paper gets larger and larger, I find it increasingly difficult to keep my focus, and it is harder to keep the quality high. So I break my presentations down into separate “modules” – groups of slides with a common theme and work on them in relative isolation (I break out each one as a separate slide deck, then merge them later). The same principle applies to writing. I break the document down into individual paragraphs and treat each one as an independent deliverable.
2. Applying the “5 Whys”. If you know me, then you know I tend to be the kind of person who is most comfortable talking about the big picture. Often I find it difficult or tiresome to dig down into the myriad supporting details needed to support the argument that I’m trying to make. This is where the “5 whys” come in. I look at the problem I’m trying to solve and ask myself, “Why is that a problem?” Usually one or more underlying issues are at play and they are often revealed by asking this question. But I’m not done, so I repeat the process, you guessed it – 5 times. The idea is to drive down to the root cause of the problem. Using the “5 whys” technique helps me to constructively drill down to the important details that I need to bring to the attention of my audience. It’s also useful for irritating the crap out of people.
3. Applying 5S. 5S stands for:
   1. Shine – go through your document or your presentation and make sure that it is clean. By clean I mean that not a single excess word is present, every concept is clear, every image is well presented, every paragraph aligned – you get the idea.
   2. Sort – make sure that all of your slides are in the right order. Insure that the concepts flow smoothly from one to another. Everything needs to be in its place.
   3. Standardize – Use a common theme or style that ties the whole thing together. It may be the corporate logo on every page, it may be some document standard (IEEE).
   4. Systematize – Make building this document into a process. It may be something that you iterate over time and time again. Even a simple process will allow you to see opportunities for improvement.
   5. Sustain – Schedule your time for working on the document. Make sure that you regularly take time to improve the process you are using and check your work

So there you have it – a complete system for lean document development!

Standard Work for Personal Improvement

Standard work is a notion from the lean manufacturing world that refers to having some sort of pre-defined standard way of doing things for a given activity or process. Actually, in the lean lexicon there is an awful lot related to standard work. Perhaps the most concise definition I’ve seen is this:

“Standardized Work is an agreed upon set of work procedures that establish the best method and sequences for each process. It defines the interaction of people using processes to produce a product. It is centered around human movements, it outlines efficient, safe work methods and helps eliminatemuda/waste.”

- cited from The no-nonsense guide to Standard Work

It can be as simple as simply documenting the work that is already done. It can also be used as part of a continuous improvement effort (you have to have a standard process so that you can measure the impact of changes). In much of the literature that I have read, the typical examples of standard work are taken from processes from the floor of a manufacturing plant. It seems pretty easy to define all the steps in a process when all you are doing is processing widgets. Compare that sort of work to the kind of work that is typically done by your average knowledge worker. Naively, they seem as though the two contexts are worlds apart.

For example a worker in a factory may do the same thing over and over again all day long. On the other hand, a knowledge worker never does the same thing twice – and certainly never the same way. Consider also that a typical factory worker works on a fairly rigid schedule that does not admit to many interruptions. The knowledge worker by comparison is sometimes referred to as “interrupt driven”, often suffering a non-stop stream of interruptions and changes in focus (depending on your situation of course). So how is it that we can apply the same sort of techniques for standard work to the knowledge worker that we would apply to the factory worker?

There was an interesting article over on InfoQ, Lean ‘Standard Work’ Applied to Software Development, that outlined some of the issues in trying to understand what it really means to apply the concept of standard work to knowledge work (or more specifically to software development). A few things become clear from this discussion:

1. There are different ways or levels of understanding how standard work can be applied to knowledge work. For example: scheduling, task completion, process performance, coding standards, etc.
2. Some would even assert (I believe incorrectly) that standard work does not exist in Agile software development.

I might even argue that in order to really understand how standard work can be applied to software development we have to take it down to the individual level. The question becomes: Where can each of us find standard work in our everyday lives? Here are some ideas:

1. The daily schedule – imagine standardizing your daily calendar in outlook. I saw an amazing version of this in a presentation done at the LEI lean conference by the folks at Group Health.
2. Meeting management – a well run meeting can be run according to a standardized structure. In fact that’s what a lot of management books are all about.
3. Quality checklists/templates – what are the criteria that we use to assess the quality of the work we have done?
4. To do lists/chores – what are the things I need to accomplish each day?

As you can see there are an awful lot of opportunities for standardization in a person’s day. Right now I’m playing with these ideas. This standard work stuff seems to border on time management (Stephen Covey, David Allen) as well as with Lean, and other process management methodologies. Exploring this sort of thing, especially at the individual level is a form of self-experimentation that can be very valuable. It can help reveal the principles behind these concepts in ways that our deeply meaningful to us in personal ways. It is through discovering that deeper meaning behind many of these principles that makes each of us better at bringing these concepts to bear in a work context. So I’m going to continue to play with this stuff, and if it interests you I would encourage you to do the same thing. You might find a lot of standard work lurking in your life.

Using Mistakes to Build Team Cohesion

So I’m working with this team and it’s a really daunting situation. There is every reason for things to fail big time. So I play it safe. I work really hard to make sure that I don’t make any mistakes (social, political, you name it). And I feel like I can’t build up any relationship with the team. Nothing. Nada.

So I scratch my head and wonder, “What’s wrong with these people?”

There seems to be this invisible barrier – they accept me because they have to, but they really don’t want me around. Me? I’m going nuts. Every day feels a little bit more aggravating than the next. Nothing seems to get through to them. Finally, there comes a meeting where I totally screw the proverbial pooch. Nothing major, no fights, no cursing, but something I say really pisses off the whole team. And they are mad, really mad.

So I get the team together, I apologize to everyone involved – take full responsibility for being a jerk (pick myself up off the floor, dust myself off) and we move on. Funny thing happens though…the barrier is gone. That’s right, the quality and tenor of the conversation immediately takes a jump toward the positive.

It wasn’t until I tripped and fell that the team started to show some signs of accepting me. It took me three months. Note to self: I’ve got to remember to fall flat on my face faster next time. I think they were waiting for me to show some signs of being human (and not some sort of Agile Superman) before they were willing to accept me on the team.

Or I could be over analyzing the whole thing. Who knows? All I know is that I feel a whole lot better working with that team since then.

How to Fail Without Really Trying

Having been working on software projects now for more than a few years I feel as though I have explored many of the most common (and a few of the not-so-common) ways of failing on a project. The good news is that you can do it with any project. It really doesn’t matter which methodology you choose to use: waterfall, scrum, XP, Kanban – you can fail spectacularly with them all. It’s deceptively easy to do and in fact, in my experience teams do it all the time. According to the people who measure these things, like in the 2004 Standish CHAOS report, we seem to be getting better at failing projects over time. I like to think that somehow, in my own small way, I’ve helped to contribute to those statistics. The good news is that you too can contribute to our long and not-so-distinguished history of software project failures. For those who are just starting out at failing software projects I have a few tips to help you along.

First things first, you have to pick or become part of a project that you really don’t have much passion or interest in. Nothing beats raw, unadulterated apathy to guarantee the failure of a project. There are all sorts of clever ways to justify our presence on projects that we really don’t care much about:

1. It’s a down economy and I’ll do whatever it takes to keep a job. No, really – anything.
2. It’s too hard to do the work required to find something we’re really passionate about that pays the bills
3. Let someone else make the decisions about what we work on. This has the added benefit of enabling us to point the finger of blame for our situation at someone else!
4. Adopt a strategy of learned helplessness. This isn’t as easy as it sounds – it takes literally years of really hard work to completely stifle a person’s initiative and will to fight. But hang in there, I’m here to tell you it can be done. Persistence matters.
5. Join a team of people you really don’t particularly like or admire. If you have trouble with this, try taking on a superior attitude. That way they won’t like you even if you don’t find them particularly offensive.

If you are unfortunate enough to come across a project that perhaps your team does have some interest in, don’t despair – there are some things you can do to fix it so that nobody will want to be a part of the project in short order. First, you need to cultivate a very selfish attitude. Try the following:

1. Just go through the motions. Show up at the daily team meeting and avoid sharing anything of any use to others on the team. Make it all about you. Just like show and tell in first grade. As far as I can tell, this seems to be the natural state of affairs for most standup meetings, so it should be easy to manage.
2. Avoid the elephant in the room. Elephant dodging is truly an art form. I’ve witnessed teams go through contortions similar to dancing the “Limbo dance” in order to avoid tangling with the team pachyderm.
3. When in meetings, be sure that you attend without making any significant contribution or preparation. I find sitting quietly with my arms crossed and occasionally nodding off during a meeting tends to discourage people from inviting me to more meetings – and that’s generally a good thing – for me.
4. If someone solicits your input, give it grudgingly if at all. If people have a hard time getting your contribution, they’ll see it as a rare commodity and value it more highly.
5. Whatever you do, don’t make the classic mistake of getting frustrated and asking more of others – otherwise they’ll start to do it too, and then eventually they might do it to you!
6. Be very quiet. Don’t speak up unless asked, and when that happens, be sure to answer using monosyllables. “No” is always a good start. Even better – just shake your head.
7. Don’t *ever* rock the boat.

Oh, one more thing: I know people are going to need help with some of this, so I want to offer my services as a consultant. If you really want to fail the easy way, give me a call – my services are available for a very high price. In fact the steep price alone may be enough to guarantee project failure. Of course as far as I can tell the competition is pretty fierce these days. There are a lot of people out there who will cheerfully escort you down the well trodden path to failure while taking your money and spouting meaningless managerial advice.

Continuous Improvement & Risk

I witnessed an interesting pattern today while running Boris Gloger’s “The Ball Game” exercise with a team. The basic idea is to iterate a team activity, stopping to make improvements each iteration. The idea is to practice and measure the impact of continuous improvement on team performance of a task. In general, the team did as you might expect: the first iteration things were pretty rough and their performance wasn’t very good. In subsequent iterations, their performance continued to steadily improve until they were nearly perfect at peforming the task.

Here is what I think I saw happening: with each iteration the group became more stable. They eliminated variation until they reached a plateau in their performance. They found stability, but they also reached a plateau where they were not making significant additional gains with each iteration. It felt very much like they were playing it safe. They didn’t want to do anyting to risk their “score” each iteration of the game.

Now I knew something that they didn’t – as facilitator I knew about other rather creative ways of configuring the group that would have given them a quantum leap in performance. There was an opportunity to take a chance and rethink the problem and make some stunning gains in performance – but at a very real risk to their short term performance. What I saw was a group that was tweaking the small stuff and missing the opportunity to change the big things that would make dramatic differences performance. It felt like there were competing pressures that were impeding the teams ability to see opportunities for performance improvements. Now of course this was just an exercise, so there really was no risk if they didn’t perform well – so any pressure they were putting on themselves was basically self imposed. And that may have been enough to blind them from seeing the opportunity for greater change.

How often do we do this on our own teams? We make improvements that fine tune the status-quo until it feels reasonably stable – and then we stop. I know it happens to me. Add a little pressure from management, and I very quickly can’t discern the forest from the trees any longer. There may be opportunities for change that offer dramatic improvements, but I will very likely not even consider them if it means potentially risking my team’s established performance.

I think this is all the more reason to focus on making the team feel “safe”. As managers we sometimes need to protect our teams external pressures so that they can keep relaxed and flexible – open minded enough to see all the possible alternatives.

Or I could be nuts. You decide.

Learning Games

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.

Understanding “There Is Only Us”

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”

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:

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 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!

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

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!