I moved  from my old domain and just wanted to assure my old friends that they are indeed in the right place.  I think you will find the new home a little nicer than the old place and a bit more comfortable.  I look forward to more good times with all of you and making many more new friends at my new location.  Thanks for dropping by and come back often.

… but don’t prohibit other people from giving it a try.

I heard the MOST ignorant statement the other day while facilitating a workshop.

“Pair programming is useful when you’re 23.  When you turn 24, there is no need for pair programming.”

From the tone of the speaker’s voice, I knew this individual was not interested in dialogue.  I also could not let their comment go unanswered and be accepted as a true, so I responded:

“I have had a different experience and I disagree with you.”

Pair programming – probably the most controversial practice to come out of Kent Beck’s Extreme Programming Explained and continues to remain controversial almost 10 years later.  The practice has evolved over the years, but it is still essentially two people working together at one keyboard solving a code and design problem.  Since I have had such a different experience pair programming, I am not sure why some people have such a knee-jerk hatred for it.  Some of the most productive code and the best designs have come out of my pair programming sessions.  In my experience pair programming is a practice that allows the sum of two programming minds to exceed the individual parts.  

So where does this resistance come from?  I think much of it comes down to fear – fear that we are not as good as we think and the other person we are coding with will find that out.  As I have heard Ron Jefferies say, “You are not as bad as you think.”  Since I am not a zealot, I will be the first to admit pair programming is not for everyone.  It is an extremely intense shared design experience.  If you are not good at expressing yourself and having your ideas challenged, you will not like pair programming.  If you simply work best by thinking in silence and hammering away at the keyboard until the app is done, then pair programming probably will not be for you.

However, just because pair programming might not fit your personal style of writing code, that does not mean no one should be allowed to use it.  Let other people try and figure out how to succeed where you might have faltered.  There are a lot of ways to write high quality code and for some people, pair programming is their way of doing that.  Let us have some variation and see what produces the best code before limiting our options.

Agile 2009 is accepting submissions.  This year I really feel I have something unique to bring to the larger Agile community, so I submitted two proposals - Product Design Tools for Agile Product Owners (on the Agile Product Management stage) and Charting the Agile Transition (on the Agile Adoption stage). Both build off of my recent work looking for the best tools from the Design for Six Sigma world to apply on Agile teams.  Please feel free to comment on the Agile 2009 website if you have any feedback.

Jeff Atwood has posted some great stuff on some of the most dangerous mistakes you can make when programming.  Check it out.

… they are too short.

Mark Levison has posted an interesting article, Making TDD Stick, on InfoQ that covers some of my observations about how to sustain test-driven development (TDD) in an organization.  I have found the best way to teach TDD is to mentor\pair with an individual one-on-one until they “get it” (about 4 to 6 weeks).

Unfortunately, one-on-one mentoring is not feasible or economic as bigger organizations try to improve their quality with TDD.  There are just not that many self-proclaimed TDD experts out there.  To solve this scarcity issue, often times big companies bring in a TDD expert to provide classroom training for the 40 or so developers deficient in this skill.  Once the trainer has been scheduled, the participants are rounded up, sit in a one or two day class, the consultant gets their check and then nothing happens!

I have not seen the model of flying in a training for a one or two day training ever work.  Why?  People do not know what to do after the trainer leaves.  TDD is hard and makes highly skilled (and highly paid) professionals feel like morons.  After a day of flailing about in their IDE, most developers jettison the whole thing and walk away with the idea that TDD only works on “toy projects”.  Not surprising since that is all they saw in their training – an easy-to-understand and easy-to-teach example that fits within the confines of a day.  Little guidance or no guidance is provided on how to apply the TDD concepts back at your desk.

What is my alternative?  Make the class longer – about two to three weeks.

1. Week One – Basic TDD training (up to 1 day) followed by 4 days of practical application.
2. Week Two – Advanced TDD concepts (up to 1 day) followed by 4 days of practical application.
3. Week Three (optional) – Five days of practical application and mentoring.

At the end of each day, I gather all the team members together for an afternoon show-and-tell of all the tests they wrote.  Everyone is required to show at least one test.  The purpose of the discussion is to learn where people are having trouble, who needs help from the trainer, what is working for the developers and allow people to express their frustrations.  The daily retrospective amplifies the learning and allows the teams members (or the trainer) to make mentoring connections among themselves.  At least you now have a fighting chance to make TDD succeed instead of people suffering alone at their desk hating life.

This week I began conversational Spanish lessons from Carolina Mery-Wood at Pura Buena Onda.  Before the Holidays, I met with Caro for a short one-on-one interview\conversation to gauge my skill level.  She told me that while my vocabulary was excellent, I needed to improve my listening comprehension – I was between a beginner and intermediate.  She said it was up to me if I wanted to be the star pupil in the beginner class or perhaps the weaker of the intermediate students.

I had my first class today with six other people and it was a lot of fun!  I was a bit anxious about my ability coming into the class, but I just dove in.  It was not as bad as I imagined it to be.  This is going to be fun and I am really looking forward to next week.

I have been wanting to blog on my last presentation at XPSD for a while, but have been so busy with the Holiday Season – so here are my thoughts on how to use the Design for Six Sigma (DfSS) quality function deployment (QFD) tool to gather the Voice of the Customer data around creating a customized Agile process for your organization based on the issues your organization faces and deriving meaningful measures which will allow your group to monitor and track the roll out.

Step 1 - The first thing you need to do is collect the Voice of the Customer (VOC) about what you want your new process to do.  So, to look forward, we need to look back for a little bit.  Gather all the people who will be participating in the process change and ask them some variation on these two questions:

1. What is your biggest pain point with the current process?
2. What is the number one thing you would change about the current process?

To gather the VOC data, I used the Wall of Wonder - allow people to work in small groups quietly for a few minutes, capture each comment on a Post-it note and hang them up on the Wall.

Step 2 -The next step is to group the VOC data into logical categories using an affinity diagram.  I find the best way to do this is ask the participants to get out of their seats and rearrange the items on the Wall of Wonder until everyone is satisfied with the groupings.  In DfSS parlance, each of these categories is called a user need.  A user need is simply trait the new development process must satisfy in order to be considered successful.

After we have labeled all the groupings, I ask the participants to force rank the user needs with the most important traits of the new process receiving the highest ranking.  In my example, addressing issues surrounding requirements and adequate resources were the highest priority for the new process.  You can also rank the user needs from 1 to 5 and allow some user needs to have equal wights.

Step 3 - Once we have ranked user needs, we enter them into the rows of the QFD chart (Room 1 in DfSS language).  Either as a big group or smaller work teams, I then ask the participants to think about what sorts of requirements the new process must have in order to meet our user needs.  This is the point where someone (usually an engineer) gives a solution to the problem and I need to remind the participants that requirements are solution agnostic.  The requirements are then listed as columns along the top of the QFD chart (Room 2).  Requirements are allowed to fulfill more than one user need, but more on that in Step 4.

Step 4 - OK, we have our user needs which define the characteristics that our new process must provide our organization and we have requirements that fulfill those user needs.  How do we make sense of the requirements and find out which requirements are critical to the success of our new development process?  Or put in the language of DfSS, what requirements are critical-to-quality (CTQ)?

To find the CTQ, we first need to complete the interrelation matrix between the user needs and the requirements (Room 3).  For each requirement we need to identify the degree they are related to each user need using the scale of 9 (strongly related), 3 (moderately related), 1 (weakly related) or 0 (not related).  It is best not to spend too much time discussing each of the relationships since they are a lot of boxes to fill in, so a tool like Planning Poker helps move things along.

Step 5 - Next we rank the requirements by multiplying the interrelatedness score of each requirement with the user need ranking in each row and sum each requirement-user need product into a total at the foot of the column.  This example shows how we arrived at the total of 162 for the “on-time delivery” requirement:

  Total = [3 x 8] + [9 x 7] + [3 x 6] + [9 x 5] + [0 x 4] + [3 x 3] + [0 x 2] + [1 x 3]
        = 24 + 63 + 18 + 45 + 0 + 9 + 0 + 3
        = 162

Repeat for each column to rank the requirements from high to low.  The requirements with the highest score are the CTQ and are the MOSTimportant requirements our process must fulfill in order for the roll out to be a success.  Or put another way, these requirements provide us the most leverage on making a successful product for our customers.  If we cannot meet these requirements, it does not matter what process we use – we have a very low probability of making a product that will satisfy our customers.

Step 6 - The final step is to derive our measures that allow us to monitor our CTQ with a scorecard.  In order for measures to be meaningful, they need to tie to something that the organization or customer (this even better) cares about.  It is time well spent to create the measures as a group and reach consensus that the measures are indeed meaningful and what the organization chooses to evaluate itself against, otherwise people will game the scorecards and there will be no accountability.  I find it useful to have about 50% of the measures tied to the customer so they process is grounded in the market.  Too much process transformation is done for the sake of the organization and the improving the customer or the bottom line is often an afterthought.

So where’s the beef?  Really – the word Agile has not even been mentioned up until this point.  Actually, that is the point.  A lot of Agile transitions start out backwards – we want to do Scrum\XP\whatever, so let’s find our problem.  QFD says let us examine and analyze our problem, find out what is most important for US and monitor those items with a scorecard to know if we are on track or not.  This approach is superior because once we have the QFD and the scorecard, we can then begin to think about what Agile process and\or practices that allow us to meet our CTQ and enhance our measures.

Maybe for your organization, you have a CTQ around requirements, then perhaps you can try our user stories and see if they move your metrics?  Perhaps you have another CTQ around quality, then maybe having cross-functional team moves that metric?  The beauty of the QFD is it allows you to mix-and-match to meet your objectives, not what it says in some book.  At least now you have thoughtful information to help you tailor your Agile approach and an objective way to know if the change you are making are having the intended affect.