I guess we can all agree that any task that needs to be carried out requires an adequate skill set in order to be completed. Should the task be more complex or less trivial, a broader set of skills or a more proficient person carrying it out is needed. When I look at software development I see a mix of non triviality and complexity, since it’s usually a long series of pretty difficult tasks. These characteristics and the creative aspect that comes from someone finding my work useful is what attracts me to the software business. In addition to that I find it rewarding and interesting to work with others. My guess is that this is what makes people group together and form teams when they develop large software systems and applications.

In order to address all challenges and aspects of software development these teams usually consists of several persons. Our wish to do a proper job leads us to this. Who can blame us, there’s plenty to consider — right? We need to analyze the business case, create a usable system and store data just to mention a few important things. These multi skilled teams are often called cross functional, referring to the combination of skills that can be put to use by the group.

A non linear challenge

However, these cross functional teams comes at a price: interaction challenges. The more people there are, the more difficult communication becomes. This communication challenge is very closely related to the number of relations in a group, which is a non-linear function by the way. It can be expressed as: f(n) = n * (n – 1) / 2, where n is the number of persons in the group. This function tells us that a group of three people has three unique interpersonal relations: 3 = 3 * (3 – 1) / 2. A group of 4 has 6 relations, whereas a group of 5 has 10, and it quickly adds up. A ten people team has no less than 45 unique relations between its team members. But the number of relations isn’t our only challenge, lets dig a bit deeper.

Distortion and noise

Interaction gets complicated really fast, partly because people continuously need to digest new information, discuss new ideas and act on them respectively. And partly because the interpersonal relations themselves require attention. The function above doesn’t show information distortion like different views, different opinions or different backgrounds. Nor does it effectively convey how communication ‘noise’ like stress, different work hours or multi tasking affects the work.

Nevertheless, they both matter and they have a big impact on our communication.

So, how should we handle all these distorted, noisy paths of communication and interaction, that seems to grows uncontrollably as we add people to our teams?

Self organization and leadership

I’ve been part of a multitude of different groups and teams. Every single one of them, especially the ones where we actually completed something there was leadership..If the task was even remotely creative I’m arguing that the amount of leadership was higher.

Suppose you were a fly on the wall and could observe all my previous doings in all those different situations. When you sit on a wall for a moment, you can’t see titles, wouldn’t know about formalities nor culture. So what would you see? Well, as a fly you would see people, engaging in several different activities, this is what flies does all day so they’re pretty good at it. You’d probably see some actions that looks like they lead to something else, while some doesn’t seem to have any effect at all. But all you see is interaction between people. Would you still be able to tell if I was the leader? Someone else? I think you could — but how?

I’ve found that the activity part is crucial, the actions is what makes an individual a leader for a brief moment, not their title or label. And this is why I argue that it has to be easy to engage in any activity. Then the probability dramatically increases that the desired behavior emerges and then — leadership can be distributed. I want shared leadership and emergent behavior because I see them as the base for self organization.

What activities then?

The base, especially the shared leadership part, isn’t possible if someone in a group is held back by something or someone. Let’s see why.

Back in 2007 I attended Esther Derby’s and Diana Larsen’s excellent workshop — ‘Secrets Of Agile Teamwork’, where one of the exercises focused on leadership activities. After the exercise we discussed what we just did, our actions, how we interacted and in particular the activities that stood and out and made people leaders or enabled leading. That was a real eye opener for me and it made me realize that I want to focus on the activities we engage in.

Some of the activities Esther and Diana pointed out were:

• Instructing
• Following
• Peacemaking
• Coordinating
• Monitoring
• Influencing
• Promoting
• Criticizing
• Reviewing
• Commenting

When I saw these the first time I found some a lot more obvious that others. What do you think?

An overlooked dimension

I’ve used this exercise as a reference and reflected over other situations over the years and many other groups I’ve been a part of. Repeatedly I’ve come back to how every difficult situation seemed to lack an important piece. All the problems seemed to stem from the same source.

What had held me or my team back was the fact that someone couldn’t, wouldn’t or didn’t to step forward and engage in some important [leading] activity. This lead me to believe that every team needs to be cross functional in at least two dimensions; technically and interactively. The former is the ability to execute a task and is what we usually focus on when constructing a team. The latter is how you can enable others trying to complete that same task and we need to be equally strong here. We need people that are comfortable with; instructing, following, promoting etc.

A simple example

During the exercise in the ‘Secrets …’-workshop described above, I had a disagreement with someone. We had a lengthy dialog during which we failed to realize that we were about to spend a disproportionate amount of time on a simple matter, until someone pointed that out by simply stating: ‘You seem to disagree’ (commenting & peacemaking). We couldn’t spot that ourselves, but that small interruption snapped us out of discussion mode and turned us to reflection instead. We could then easily see that this question was best answered by a third person, so we turned to them for their opinion and the matter was solved in seconds.

Commenting and peacemaking — simple and really powerful.

Another simple but hard to do example

A few years ago I found following really hard as I felt I had to ‘lead’ in order to be in control. Following is now my current favorite activity, even though I still have problems with it on occasions. I’m not totally over trying to control others, but I practice every day by letting other people coordinate, promote or instruct me. Following more has gradually helped me get used to not being in control and I don’t feel I have to lead to the same extent. Nowadays I pause more often when I talk, pause when I show others how I do things and wait for reactions when I make a comment. 5 seconds is usually enough but that still feels like an eternity sometimes.

I will keep experimenting with following because I’m convinced other crucial behavior depends on it and won’t emerge unless there’s room for other peoples actions and thoughts. And if I lead all the time, the groups I’m a part of might not learn as much and more importantly, I won’t learn at the same pace because I wouldn’t have any time to reflect and see what my own actions lead to.

Way back, more than 10 years ago, when people still argued if Internet could be used to do other stuff than transferring JPGs, me and a colleague got involved in a small project. We where supposed to convert an MS Access application to a web ditto. The whole idea was basically that more users should be able to run the application and future upgrades would be a lot smoother. The current application had a few know bugs and those should be addressed as well.

Smooth sailing

In those days fancy web frameworks weren’t available, JavaScript implementations in browsers were rocky and their compliance to web standards was coincidental at best. Even so, a couple of weeks after we kicked development off we were well on our way and it looked like we could meet the expected delivery date. We worked at rather comfortable pace and finished the project one week late.

The late delivery wasn’t a big deal, no something else was.

A couple of months later we had developed a perfect replica according to our specification and the web app was installed and ready to be used. I later learned that the fact it was a perfect replica was the actual problem. Apart from the obvious bugs we removed we hadn’t realized that there were some more serious flaws in the current implementation.

First Demo

The implementation of the process flow didn’t fit reality which forced the users to go through unnecessary steps and procedure to work around a major design flaw. This became painfully obvious when I sat down with the customer during a demo. At first I felt rather proud of what we had achieved during the weeks of development but as the demo drew to and end the users that where present got more and more agitated. They where supposed to be impressed I thought to myself as I started to break some sweat.

10 minutes before the end I was trying to sum things up as a lady said: ‘What about the work flow …’. ‘Yes, how about the issues with the work flow …’ another one pitched in. I was baffled; ‘Yeah, what about it?’

‘You haven’t fixed the work flow?!’

I hadn’t … because I didn’t know I was supposed to.

In retrospect

Looking back I can see how easy it would’ve been to start pointing fingers and blaming each other or even blamed it on poor specifications. But the specs weren’t poor, were they?

As a developer I thought the specs were great and I had a really good grip on what to do. Just make a web application out of this, this really really precise specification. This legacy app. And we did!

We really managed to implement it. But did that cut the mustard? No it didn’t.

I think I was being misled and fooled by the very precise specification, in this case we had a running MS Access application. Which to me seems very precise. We could see the GUI, all the buttons, the drop-down menus and by golly we even had a reverse engineered schema for the database. Could it be more precise than that? I didn’t think so.

Today I still see lots and lots of people trying to work out very precise specifications. They really put their mind to it and often enough they produce really precise specs. This is what I think leads other people to think they are correct. This much detail … this high precision, no one could be this precise without being correct, right?

A piece of advice

- Precise isn’t the same as correct nor accurate
- Don’t substitute specifications for conversations

And last but not least; Software is of no use unless it’s in production and making peoples life easier.

I like to look at things from a positive angle since I find the opposite to be very … ehrrr … negative. This is not the same as being naive but at times it might look like that. Nor does it imply disregarding risks, negative aspects or criticizing, even though it might look like that as well.

No, it’s just that I like my default mode to be positive, so to speak.

A couple of weeks ago I was asked to facilitate a retrospective and since I like to build on the positives of a situation I started to look around. Also I had been talking to a colleague who happens to like to amplify the positive rather than dampen the negative. Since I’m a firm believer in that as well it made me more determined in my search for a good way to hold a retrospective. Having vague memories about appreciative inquiry, it didn’t take very long before I found something I liked.

What’s AI then?

How about An AI retrospective then?

Yes, it has been done before. Diana Larsen describes the concept here.  It’s fine to read that later, or you could do it now if you’d like.

Basically a retrospect consists of five parts:

• Set the stage
• Gather data
• Generate insights
• Decide what to do
• Close the retrospective

How we did it

Me and another colleague ran this retrospect as a pair, stepping back and forth as the facilitator. One of us was managing the present at a detailed level while the other one looked slightly ahead as we went through each stage. I wouldn’t recommend this unless you know each other very well and have done a fair amount of pair work previously.

Stepping back and letting the other take over the facilitation requires a pretty high level of trust. Especially if you like being in control.

Setting the Stage

First, since I was pretty sure no-one in this crowd, beside me and my colleague [the facilitators], knew about AI we explained very briefly what AI is and then ran a round of ‘Appreciations’. The mechanics of an appreciation can be described as follows:

• Think of someone, you honestly appreciate, for doing something
• Face that person and express that. I.e ‘Tom, I appreciate you for helping me find the problem with that tricky threaded design last Monday’
• Tom should acknowledge the appreciation by simply saying ‘Thank you’ or something like that.

The mechanics of an appreciation is as simple as it sounds. The tricky part is being direct, finding things you appreciate and last but not least muster some courage to say it out loud … when you’re sitting in a room with 10 other colleagues. It becomes easier after doing it a dozen times though.

The appreciation round got the group in the right mood. After that we asked the group my favorite question in order to stimulate some abstract thinking around a specific topic.

If this [iteration] was an Ice cream, what would it be like?

I believe that abstract thinking helps a lot later during the ‘Generate Insights’ part and to this day I haven’t met anyone that doesn’t have something to say about Ice Cream. It’s not political, it’s abstract enough, it’s fun and people open themselves up just a little bit more.

Ice Cream … we got a perfect start. The first person really hit the head of the nail by summing up the iteration as a cone of ice cream with three different flavors. Brilliant! The others tagged along and off we went!

Gather Data

Now it was time to start asking some questions to stimulate the data gathering. We asked 4 questions and asked the participants to try to relate those to either a ‘Strength’ the team had, a ‘Success’ or an ‘Event’ that had occurred since the last retrospective.

1. ‘Tell a story or about a time when you where in a flow’
2. ‘Say something that you are particularly proud of achieving’
3. ‘What unique thing did this iteration add’
4. ‘At what time did you feel like you where part of a team the most’

As we asked those questions people told stories and commented while they and the others wrote down their answers and notes on stickies. Small paper notes that can be stuck on a whiteboard.

Generate insights

After that we told the group to close their eyes, imagine they were in the same room only three weeks in the future. While pretending they where in the future, we again asked the same questions and they wrote down their answers. After this round of questions each participant read all their answers out loud and we helped them put the stickies up on a wall.

Now the time had come to prepare for the next stage and in order to do that we wanted to reach some sort of agreement on what to do. We asked the participants to look for patterns and then group the stickies. All this had to be done while remaining completely silent. No talking allowed.

We weren’t quite sure how they would tackle this but the group once again astonished us. In complete silence they had grouped the stickies in less than 5 minutes and they enjoyed it.

Decide that to do

Thinking about their strength as a team and looking at the groups of stickies we then asked them to vote for what area to look into. After a simple dot-voting with a total of 6 dots, 3-2-1, they had come to the conclusion that two areas needed their attention the most. They split up in two groups, talked for a while and then presented two plans on how to achieve their goals. They decided that they would put up those goals where everyone could see them and follow up on that.

Closing the retrospective

We had plans on running a full ‘Temperature Reading’ as a closing activity. However, we ran out of time and opted for ‘Hopes and Wishes’. By this time the group was steaming with positive energy and really going. Despite the fact that we had been going for pretty much 90 minutes straight.

Hopes and wishes are stuff that the participants would like see or happen in the future. Like, ‘I would really like to pair program more’ or ‘I wish I could visit our customer more often’. This closed the retrospective and kept that positive note right to the end.

I will definitely do this again.

What I do know is that I have an urge to be in control. So, when I get in a situation where I, for some reason, don’t have all the information I want that, I feel the need to be in control. I start to act irrationally, ineffective and very unorganized. It’s a vicious circle.

Loosing control

Whenever that sort of situation appears I know it’s important to take a few steps back and start asking myself questions. Questions that gives me an idea of what’s going on. It usually boils down to the lack of information. I don’t understand things or didn’t get the information I needed in time.

And I’m not alone.

At least I think there are a lot more people like me out there. We want to have relevant information in time. When transparency turns to opacity, it’s easy to get confused.

If we agree that everybody always are trying to do their best, given their capabilities and the information they’re handed. What you really want to do is make your process as transparent as possible. You want a flow of information with a minimum of delays and noise. You want fast feedback as well. This is the essence.

Humans need information that is tailored to the current situation. Let’s see what happens when you increase transparency in a process.

Increasing transparency

Imagine yourself being part of a team, in a project that develops software. You’re team is noticing a trend. The customer are having difficulties in deciding on how the UI is supposed to work and what is shall look like. Something doesn’t feel right and you’re get the feeling that information gets lost. The team makes the bold decision to start delivering more often. By doing this you’re closing the feedback loop earlier and you get relevant feedback more often. Transparency increases.

Two releases later the testing apartment starts complaining. They can’t keep up. Defects slips through and the customer isn’t very pleased. Management hears this and tension mounts. From around the organization suggestions are made that you ‘Go back to the old way of working’. In short, decrease transparency.

Now it starts to get interesting.

An organization that is serious about improvements will start asking questions instead. Why aren’t testing keeping up? A will to try and find the root cause of the problem is key, not closing ones eyes, pushing the problem away or start blaming each other.

Improvement, leadership and feedback

If you’ll keep on trying to increase the feedback in your organization and make sure information flows freely you will eventually get a more transparent process. You won’t get your hands tied up in a web of lies and misinformation that steals energy and focus from what really makes a difference.

When you and the people around you get used to this, you’ll experience a whole different level of control. You’ll notice you waste less energy on what doesn’t matter and you’ll be able to make use of that energy on the important stuff.

If you still think that the world is spinning faster and faster or if you’re having troubles keeping up, you’re probably wasting energy on the wrong things. Maybe it’s time to increase transparency in your life?

The future is now and the new instrument for control is transparency!

It frees up time, resources and money. But it requires a new kind of leadership. One that is characterized by passion, a will to improve and honest communication. Are you ready?

While this might be true I’ve found that there is one thing that affects me more than any of the above. Namely the nature of the communication. If it’s to pushy I loose interest at best. At worst I get defensive and the other part will usually go defensive as well.

A model

A few months ago I stumbled over a model I’d like to share with you. It describes the nature of (spoken) communication and gives me a pretty good orientation, or at least a hint of where and how the communication is going.

Picture a ladder or an axis, which gets more intense the farther you get to the right. It has five steps and looks like this:

Dialogue -> Conversation -> Discussion -> Argumentation -> Quarrel

You might want to go even further, to the right, and I guess the next stage after a quarrel would be fighting. I don’t count that as communication so I stop at Quarrel.

I want to give you a basic idea of how I experience each stage and what I think characterizes them. I’ll start at the far right and work my way to the left. Sort of ending up where I like my communication to happen.

Quarrel

As said, not very far from getting physical but still verbal. If I picture it in my head it could be a couple on the verge of separation standing in a kitchen and reaching for something to throw while accusing each other of different things. It could also be an upset customer who aren’t very pleased with a product, that has returned for a refund but the supplier says the warranty has been voided.

Argumentation

This is still really intense. Each part in the communication is trying to convince the other part that their view is the correct one. The words can be soft and the tone could also be very gentle, but the intention is still to convince the other part.

Discussion

This is middle ground. Not a quarrel but you’re not really open for another persons perspective either. Sentences like: ‘That’s not how I look at it …’ or ‘Oh yeah, how about the time when you …’, is pretty common. I wouldn’t describe this type of communication as very productive. Not in the long run at least. At best you can determine where a person draws the line but not really gain any deeper understanding.

Conversation

Lunch chit-chat about nothing and everything. You aren’t really really giving the other person your full attention and a comment like: ‘Are you listening … ?’ might appear in this context. This is also the typical mode of exchanging information. A few ‘Can you clarify … ‘ might be tossed in and appear in the conversation. But each part is still spending more time preparing an answer than really trying to understand.

Dialogue

This involves a lot of listening. Here you focus on understanding the other person, before even opening your mouth. You aren’t preparing an answer, the answers and opinions are pulled out of you.

If you give your other communication parties this much attention and really put your hear to it, amazing things will happen to your relationship. Engaging in dialogue is exhausting and requires a lot patience. But with some training anyone can do it.

Summing it up

The farther you go to the left, the more pull oriented the conversation is. The content isn’t key, neither is the tone really. Even though the tone of the communication degrades pretty fast as you move to the right. No, the key thing here is that information is being pulled rather that pushed. As you go left, it gets more pull oriented. Going to the right, more pushy.

What’s important to remember here is the nature of the communication, not it’s content, and how you or the other involved parties react to different natures of communication. What you are trying to communicate and the context also matters.

Oh and one final word. This is a model of the reality, this is not the reality itself.

Another build master is born

Robert whips up the command prompt like he usually does and wonders what kind of surprises he’s going to run into this time. Gentlemen, start your engines. But first, compile time. We copy the copy source files, from this directory here over to the build dir. Then compile. The actual compilation wouldn’t have been too bad if it weren’t for the circular dependencies and other interruptions, Robert thinks, as he heads to the coffee machine while the compile is running. I’m going to need this second cup. What he doesn’t know is that it will take him more than 10 cups before he’s going to be finished, this time.

It comes as no surprise; the build crashed after 4 minutes. A new record Robert thinks to himself as he takes a sip of his blant coffee and searches the command history for the command he usually runs when this happens. Got it, he executes his ‘cleanup command’ and then resumes the compilation. That should do it. He takes another sip of the coffee and starts browsing the net while the build splurts out loads of text and debugging-info in a barely visible terminal, behind his Internet browser.

Suddenly, the text stops scrolling and Robert is snaps out of his zombie-like state. Ugh, what’s this, oh no, not again. Another third party library that isn’t on the build path. It isn’t even two weeks since this happened the last time. Why don’t they bother to put these files in the version control repository. Robert searhes the net for 15 minutes before he finds the correct version of the 3rd party library and is able to put it on the build-path. Then he resumes the building and starts browsing again.

Over and over and over again

After three more interruptions, the day draws to an end. But before he can release the code it has to be obfuscated and packaged. The zip has to go into version control and documents has to be updated. The work spills over to a second day. Two days become three and even more work is needed.

Then, just as he is about to tell the productmanager he’s done; a bug is discovered.
Robert isn’t very happy. In fact he’s pretty darn pissed. But he starts over, thinking, ‘Well, someone has to dig in and do some real work for a change’. He hasn’t realized it. But one iteration from now all he will be doing is managing releases.

The way out

Doing things, by hand, that can be done by computers is not only wasteful, it’s degrading. It sucks the energy out of you and your team members. This energy and time could be used to improve other parts of a software development process. Or pieces of code. Or maybe plain testing.

In short, automation scales very well. It’s a much more linear function than adding developers. Add one computer and you can probably run tests, build code or do any other task twice as fast. As longs it’s fully automated.

Before you automate anything though, you should make sure you can do it by hand. If you can’t do it by hand, chances are it’s very hard to automate. If not impossible.

Beware. Everything that can be automated shouldn’t and everything that seems like it couldn’t should be tried. Let me explain.

When you’re automating you are adding tasks to your process. This makes them harder to question, get rid of or improve. Because you might not really know why they are there. Or rather, why they became part of the process. Therefore you should simplify the things you are automating /before/ actually doing so. That way it’s easy to see where everything fits in.

Simplify, then automate

Things that can’t be automated requires an extra look as well. Why can’t they be automated? The very questioning may lead to insights and later even changes to a process. So, When looking at the same piece of work again you might spot a way to automate it.

Signs that indicate ‘computerwork’. Things that could be automated

• Repeatedly doing the same thing
• A problem seems too simple to be automated
• You often miss important steps while working
• Your mind wanders while working. It could also indicate that you need a break.

There are probably more signs. Can you think of one?

Manny walked back and forth in his room, trying to come up with an idea on how to stop this madness. Because it was madness. The team could easily spend two weeks fixing bugs every release. And sometimes they did.

He came up with nothing and strode over to the window beside his desk. Just as he was about to enter his seat he spun around, grabbed a pen and paper from his desk and ran down to the war room.

He liked the term ‘war room’. Everybody else called it the developers room. But Manny liked the tone and implication of the term war room, he realized as he entered it.

Hey, listen up folks! This weekend will be a bug-fix weekend. The name really says it all, but come to me if you have questions. Manny scans the room to see if he has everyone’s attention It starts Saturday morning … If you can’t attend, write that down beside your name here, on this list. If you can, write down your preferred Pizza.

Manny knew all programmers were suckers for pizza and he had another surprise for them. Everybody that attends get a dinner for two on a restaurant of your choice … he savored the rest of the sentence … per day. So, you can get 2 restaurant visits, or 4 persons in total. He could have sworn he heard a low ‘Ooooh’ from the other side of the room. But he didn’t linger long enough to really hear what people talked about.

He walked out of the room and he knew it would be a success!

Description

Manny might have all the right intentions in the world. Wanting this to be a success. Building some team spirit or whatever. Trying to raise the quality of the product. What he doesn’t realize is that this will have the opposite effect. By running this bug-squash event, he is saying that it is OK to produce code with errors in it. And he has begun institutionalizing waste this way.

Let’s make one thing clear though. It’s OK to make errors. It should be OK to fail. But what Manny does is a totally different story. He communicates that quality is something that can be added later. If needed.

He also communicates that quality isn’t important enough to pay attention to all the time. It is something you can add later, like paint. What he probably hasn’t realized either is that quality is much more expensive to ‘test in’ later. And that the ‘testing in’ approach also results in lower quality.

Software is expensive as it is already. We don’t need waste in the form of bugs to drive costs up further.

Refactored Solution

Q: If quality is expensive to ‘test in’. What is the correct approach then?
A: Build a quality product from the beginning.

Mistake proofing

People are human and we make mistakes. While mistakes aren’t avoidable, defects are. Defects result from mistakes reaching an end customer. So, the goal is to create a process where a defect never reaches the end customer. Doing so is the responsibility of the development team.

This can be achieved by combining various mistake proofing techniques. Now there is no single one technique that can stops all defects from reaching customers. It’s a combination of several ones, fit for the purpose.

Categories of mistake proofing

There are two types of mistake proofing techniques. One is prevention, the other one is detection. If you think them both, you might recognize a few from your every day life. It’s full of examples, both prevention and detection devices.

Detection devices doesn’t enforce correction, They merely signals problems. Take a modern car for instance. When you’re backing up and you come close to a curb or another obstacle, a beeping starts. This signals a warning to you as a driver. It doesn’t kill the engine, although it probably could.

Prevention devices works differently, they remove the need to correct a mistake. Like a power cord. There is only one way you can plug that into a wall socket. If you live in Sweden, where I live, there is actually two. But both ways work. Hence no mistakes are made and none need to be corrected.

Software mistake proofing

In software there are several techniques for mistake proofing. And those techniques are what you need to put to work when improving quality. You will want to design a process where defects doesn’t reach the customer.

Here are some of my favorite techniques. Can you see which category they belong to. Prevention or detecteion.

• Test Driven Development
• Pair Programming
• Regression tests
• Continuous Integration
• Customer tests

I wanted to develop all my code in a pair.

Pairing made me more focused, made me learn at a totally different pace. And it was much more fun too.

I was bitten, I wanted more but my situation changed and that made pairing a bit more complicated. I found myself in a new setup where there was no pairing culture. We didn’t have paring stations. Only solo desks. We didn’t share rooms. Even though we sat only 5-10 meters apart it felt like we were in different timezones. A few months into this I started slipping back into not pairing again.

Physical Setup

It wasn’t just that there was no pairing culture. I came to realize that how you sit matters a lot too. How easy it is to just sit there and solo. Not move your chair a few meters and start pairing. How the room and desk is organized meant a whole lot more than I first imagined.

Rules

Since we didn’t sit right next to each other, me and my co-workers tried scheduling paring sessions. That didn’t work out too well. We tried agreements like, ‘Whenever we work on xxx, we must pair’ and ‘In the afternoon, we always pair’. That didn’t work either.

Excuses

There’s always an excuse NOT to pair. There are always circumstances that make pairing harder. And if one part resists ever so slightly, I’ve found that any excuse will pass. If it’s tried. I came to the conclusion that the physical setup is one very important aspect of pairing. It should be really really easy to engage in pairing.

2 on 1

One year became two years and I didn’t pair as much as I used to. I tried, my colleagues tried occasionally with no lasting result. What had been so natural in my previous project maybe wasn’t very natural at all. I began to wonder.

In my previous project we deliberately had put roughly half the number of workstations as were programmers. Pairing came, more or less natural. Once you have your own computer it’s so much easier to let the hours become days, months and even years without pairing. Even if you really enjoy it.

Half the amount of developers workstations made all the difference. When we removed the option to sit alone and develop, we were forced to a change by removing the old ‘status quo’. We couldn’t fall back to soloing. We had to find another way. Pairing came ‘naturally’. Because we were developers and we wanted to develop.

There was no other way than to pair.

While this is basically true, I’d say it is a flavor of pair programming. If you’ve never heard about it before, this definition gives you a basic idea of what pair programming is about. Or if you’ve never tried it, this approach is one easy way to start. Just sit down next to your peer and start working. The only modification to your working area you need to do is to move your chair closer to your colleagues. And off you go!

First contact

I was involved in a project, with a few other colleagues, which we felt wasn’t heading in the right direction. We had pretty much lost contact with the customer and that us and the customer to feel pretty desperate. We needed to make some dramatic changes to the way we worked. That was obvious.

This was late 2000, ‘eXtreme Programming’ was rather new and one colleague had just picked up the ‘White Book’ as we came to call it. Namely Kent Becks – ‘eXtreme Programming Explained’.

For the first time we came in contact with a methodology that seemed to suit our needs. Light weight, focused on programming practices and pretty much the same values we had within our company. Despite the warnings that came with the book. ‘Don’t try this to save a project’ etc. We decided to give it a go. We also decided if we’re going to try XP we’re going to try all of XP.

Like entering a pool, cannonball style, we would try it all at once. Since Pair programming is one of the practices described in the book this became my first contact with it. Little did I know how much it would affect my programming, collaboration and people skills.

Fumbling and Stumbling

Since we were all beginners I believe that helped us a lot. I think it contributed to a higher tolerance to each others flaws, because we knew we were all beginners. No one had tried pair programming as described in the White book before. Sure, we had sat down together to tackle a difficult problem or to explain something we just did. But none of us had programmed with another developer, side by side, over an extended period of time. How was this going to feel?

Practicalities  at first

One of the earliest memories I have of difficulties during pair programming came from practicalities. How and when to switch partners, who where supposed to team up initially and what happens when someone gets sick or isn’t at the office.

Switching pairs

Switching gave us some headache at first. We never managed to switch pairs mid-iteration. The fact that two pairs very seldom finished a chunk of work at the same time made us wonder. Should one pair wait for the other while doing nothing. Or pick a less important piece of work that was of substantially smaller size, than the most important, just to let the others catch up? We decided not to switch in the midst of an iteration.

It didn’t feel optimal but it was way much better than not switching at all.

Teaming up

We had one rule that I think helped a lot. It was particularly helpful when teaming up. We were not allowed to say no when someone asked for help. This made me a lot more courageous. I clearly remember one time when I was hesitant to pick a piece of work. Then I remembered the rule, grabbed a very interesting story and asked a more seasoned developer for help. He joined me of course, and we both learned a lot. I learned more about programming that he did. And he learned about himself, about his teaching techniques and a few new ways to look at problems.

Now, new challenges arose. Some preferred working together and started teaming up very often.

Sick, sick, sick

When someone got sick or wasn’t at the office for any other reason funny things happened. Some of us took that as an excuse for not pairing while others saw a chance to switch partners. I enjoyed pairing so much so I would rather sit with another pair, than alone. Making us a triple. This wasn’t optimal but neither was sitting alone, I thought.

I found out that there was always someone that was more keen on sitting alone than me. So I normally ended up pairing and they normally ended up sitting alone. Another challenge.

Splash …

All had jumped in the water and it made a big splash. It wasn’t freezing as some of us expected. It wasn’t very hard to swim in a new way either. It was actually rather pleasant for most of us …