Pattern: Orientation

Because of our development process it is easy for us to work on the same project and even the same functionalities with the whole team together. As we explained before we use Stories to categorize and describe the necessary features for a project. Once we start on a story we split it up in tasks. Tasks are simple things comparable with todo's and can typically be accomplished by one pair of designers or programmers working together on the same computer.

Tasks that do not produce actual code, like server maintenance or registering a domain name can be carried out by individuals working solo of course.

Most tasks inside a story will however be development tasks and will be carried out by two people working together using a technique called Pair Programming. Using the orientation pattern it becomes really simple to switch pairs for developers.

For it to work correctly you need to understand about the TDD (Test Driven Development) cycle, here it is;

1. Write a test
2. Make it compile
3. Watch it fail
4. Write a little code
5. Make it pass
6. Refactor mercilessly
repeat until you cannot think of any more tests.

Now stories will typically be split up into tasks, for example:

* Write marketing text
* Design landing page
* Register domain name
* Code landing page HTML
* Submit a form and validate name and email
* Store validated name and email in database
* Submit a form and check if not already stored
* Give AJAX feedback on errors
* Give AJAX feedback on success
* Test in 3 target browsers
* Deploy database, cvs and apache
* Write a blog entry
* Add small advertisement to brains4all homepage
* Write a newsletter article

So you see this story includes a lot of different tasks, not all tasks are Design or Development tasks by a long shot. Still since those are most often carried out by a pair these are the most interesting when you're switching pairs halfway through a task. Let's look at these development tasks:

* Submit a form and validate name and email
* Store validated name and email in database
* Submit a form and check if not already stored
* Give AJAX feedback on errors
* Give AJAX feedback on success

Suppose I've finished with my registering the domain name tasks and I go and sit next to Serge. To help me orientate I can ask these simple questions:

Marko: Hi, what are you working on?
Serge: I'm working on Submit a form and check if not already stored.
Marko: So what are you doing?
Serge: I'm making this test here pass.
Marko: Okay, let's go!

By asking these simple questions I can quickly orientate myself inside the pair. I know what task we're working on in the story, I know in which part of the TDD cycle we are. For me this is enough to be able to dive in almost immediately and add value to the pair.

A funny side effect of this is that a task can be finished by completely different people that started it and almost everybody on the team may have worked on it. This helps to spread knowledge about the system throughout the team and helps you to keep code easy to change. Also by switching pairs frequently I've experienced a much higher sense of accomplishment and team effort. It also helps to keep a lot of energy in the team and if you change pair every 5-15 minutes it helps you prevent those Gung-Ho refactorings that seem to take forever.

What are your experiences with switching pairs?
How often do you switch and how do you orientate?

Comments

Post a comment