Optimal pairing

2 comments:

What was all that rambling about Harmonic Mean?

A while back, I posted a rambling entry about the impact of Harmonic Mean on a team's performance. The post was actually about pairing. My intention was to put a solid mathematical, albeit only pseudo-scientific, explanation behind my paring recommendation, but I think I lost several people (including myself once or twice) in the math and all the fancy words.

In short, whenever you pair two people of disparate skill sets, their contribution to production is more heavily influenced by the lesser skilled or experienced of the two. And the impact is significant. The greater the disparity in skill/experience, the more significant the impact.

Pair with people of similar skill and experience

Maximum performance per pair is achieved when the pairs have identical skills and experience. This is, of course, highly unlikely. It is, however, fairly easy to put together a team with similar skills and experience. This provides us an opportunity to mix pairs, keep things fresh, and disseminate knowledge and experience more rapidly through the team without concern over the impact of mis-matched pairs.

When putting a team together, it is best to make sure the skill sets are within a few degrees of one another. When this is not possible, work to achieve a fairly even distribution of skill and experience. Avoid large gaps and do your best not to leave anyone isolated at the ends of the scale.

Exceptions to the "rule"?

The Software Craftsmanship movement encourages us to apprentice people new to software development. To bring them in, take them under our wing, and provide them the opportunity to learn through direct interaction with other developers in a structured and meaningful way.

Surely, Doc, you are not suggesting that apprentices should teach one another.

Yes, I am.

First of all, a good apprentice program does not immediately toss the new hire into a high-demand deliverable project. A good program provides the apprentice an environment where they can work on breakable toys designed to help learn fundamental concepts. Each step is a building block to the next, wherein fundamentals in both theory and practice are learned and built upon.

Under these conditions, who better to pair with than another individual of similar skill and experience? You can discuss, debate, discover, and learn all under the watchful eye and guiding hand of a more experienced journeyman or craftsman. The master cannot and should not devote his entire time to the growth of the apprentice. It is optimal, even as someone brand new to the craft, to pair with another much like yourself.

Chicago Clojure Group

1 comment:
I am new to Clojure, but when I was asked to help with the Chicago Clojure Group, I was certainly willing to give a hand.

It took me a while to get my act together and whether or not it is entirely together is yet to be seen, but I am happy to announce the re-launch of the Chicago Clojure Group.

You can find out more about the group and our events on the official meetup site.


http://www.meetup.com/Chicago-Clojure/

Hope to see you there.

Apprenticeship Patterns

No comments:
Apprenticeship Patterns is a book of common sense advice derived from years of experience. While it reflects experiences, lessons learned, and patterns derived from the profession of software development, this is really a book about how to craft your own successful career, regardless of chosen vocation.

Each chapter of the book introduces us to new, related patterns. Patterns progress as if in a timeline from those you will find most valuable starting out to those which foster continued growth and learning for a lifetime. The patterns themselves are atomic so while the progression in the book is logical, it is not necessary to read the book front to back. From the last pattern to the first, each is applicable whether you are just starting or are a seasoned veteran.

I recommend Apprenticeship Patterns to everyone, not just friends in the computer industry.

Stories are about why; not what or how

2 comments:
Story Fomats
I've been on numerous Agile projects with varying methods for capturing stories. Quite popular (and purportedly the ThoughtWorks standard) is the "As a, I want, So that" story format.

While I have seen teams do well with this format, I think it can be radically improved with a minor change. I prefer to see "So that, as a, I want" story format.

My reasoning is quite simple; the emphasis is incorrect in the common story format.
Same words, different order
Compare these two statements:

As A Bank Teller, I Want a name search field, So That I can quickly look up customers.
So That I can quickly look up customers, As A Bank Teller, I Want a name search field.

These are arguably the same story. The words are precisely the same; merely in a different order. Pick them apart, word by word, and we all agree these requirements are identical.
Emphasis
But in planning meetings and even our regular work lives, we don't pick each statement apart word by word. Rather we take in the statement linearly, process it for meaning as we go, draw a conclusion of intent, and act.

Let me make it visibly clear what is happening in our minds as we process the two statements:

As a, I want, so that
So that, as a, I want

"As a" is always secondary in our mental process. This is, of course, a generalization. If I am an account manager, I am highly attuned to all "As an Account Manager" stories. But on the whole, for whom is a clarifier, not a primary consideration.

With the common story format, our discussion is likely to be more around what the text field will look like, where it will be on the screen, and how it will function.

With the common story format, I often see stories devolve to the abbreviated, "As a, I want" form. This is quite dangerous. We are now delivering functionality that serves no expressed purpose.
Focus on Why (value)
By placing "So that" at the front of the statement, we've put an emphasis on why the story exists. If we can't say why we are implementing a feature, there is clearly no purpose for the feature. Even when we are certain that the purpose is obvious, it is best to include it. What is clear to the requestor may be opaque to the implementor.

Our discussions are now focused on value. We may spend no less time discussing specifics of the implementation, but we are first assured we know why we are delivering the story. Our implementation is better guided by why. We are free to explore alternatives that better suite the purpose.
Put purpose first; literally and figuratively
It helps to put the purpose of the story at the front of the story form. It places the proper emphasis on why and better frames our discussions. But if the purpose is inadequately stated, we are still likely to have the wrong discussions.

Take the time to genuinely consider the why of each story. What is the value to the business? How will the customer be able to confidently select this story over another in planning sessions? Consider using Vincent Partington's technique for creating clear stories.

Our original story is better stated as follows:

So That I can serve customers faster, As A Bank Teller, I Want an efficient way to look up customers.

We now express the actual value to our client and we do not mandate implementation in the story summary.