I am facilitating an Agile Playground session with June at XPSD tonight.  Stop by if you are interested in learning some Agile games and want to have some fun.  Here is the short write-up from the XPSD wiki:

“What is Agile software development? What are the essentials I need to know about this stuff? Why is my Agile team so dull and boring? Looking to get energized? Come to this introductory session hosted by Carlton Nettleton & June Clarke and they will demonstrate as many Agile principles and practices as they can in 75 minutes of fun through a variety of short simulations and participatory games. Walk away with the critical insights, the “ah-ha” moments, where the essential Agile concepts slip into place and make sense.”

A group close to my heart, Extreme Programming San Diego (XPSD), is looking for speakers to talk about their experiences applying Agile software development practices.  XPSD meets on the 1st Thursday of every month at The Linkery in North Park from 6 PM to 8 PM to network, share ideas and discuss trends in the Agile software development community.

XPSD is an excellent, knowledgeable community resource on the topic of Agile software development, Scrum and Extreme Programming in San Diego County.  I am consistently impressed with the experience and passion in our group.  I am very proud of how much XPSD has grown over the years and I am glad we have created a friendly space for great dialogue on Agile in San Diego.  We are seeking speakers in these three areas:

1. Experience reports on applying XP, Scrum or Agile techniques in your organization.
2. Explanations on the business and management side of using Scrum on projects or the enterprise.
3. Technical presentations on useful tools or the technical practices of XP or Agile software development (pair programming, iterative design, refactoring, TDD, testing, etc.) that enable agility.

We provide a variety of ways for our speakers to contribute (see below), so if you just want to share some ideas on how something might work or to talk about what your team did, please get in touch with our organizers – Carlton Nettleton (carlton@lookforwardconsulting.com) or June Clarke (joonspoon@yahoo.com) – for more details.

These are the formats we provide for our speakers:

• Roundtable: a casual discussion where we can examine one or two ideas from a variety of perspectives for about an 60 to 90 minutes. The roundtable “host” provides a 10 to 15 minute overview of the topic(s) in order to frame the conversation and then starts the discussion with a provocative question.  This is a great format to get a number of expert opinions on a difficult problem you’ve been facing.
• Lecture: in-depth discussion of one or two themes or ideas and is expected to be about 60 minutes, but no longer than 75 minutes. Great format for an experience report or sharing some results with a wider audience.  XPSD is an inquisitive group, so expect questions during your talk.
• Short topic: intended to explain a technical topic or highlight a new idea.  This new, short format (15 to 30 minutes) is provided by XPSD to help new speakers, ideas, perspectives and experiences get in front of the members.
• Workshop: illustrate a concept or technical skill primarily through audience participation and ideally should not exceed 90 minutes. Workshops are fun and members love them.

This year, the Agile Alliance and PMI formed an Agile Community of Practice.  The community was formed because both sides recognized their is a lot of misunderstanding about each other, yet we often talk about improving the same types of things.  In the sprit of that enterprise, Look Forward Consulting decided to sponsor the October meeting of the PMI Chapter in San Diego and act as an ambassador to the project management community in San Diego.  For those of you unfamiliar with PMI San Diego, their mission (from their website) is:

“…to serve the professional interests of chapter members by enhancing expertise through project management education, training, and PMI certification preparation; as well as, promoting association and networking within the project management community.”

In practice, this means helping project managers make connections with other project managers, educate each other on the latest techniques and promote their ideas in their profession.  It sounds an awful lot like what we do at XP San Diego.  This should be an interesting collaboration and I am looking forward to meeting some new people.

I will be presenting three sessions at the LA Code Camp this year.  Surprisingly, I am not going to be giving my Top Ten Refactoring session; I just did not feel in the mood to do it this year.  Have no fear, Llywellyn and Woody Zuill have that topic covered in their excellent Code Excellence for the Average Programmer talk and demonstration.

The sessions I will be giving are:

1. Experiencing Agile Through Games: we will be playing as many Agile simulations and games as we can in 75 minutes.
2. Insights Into Scrum Illuminated by Lean: we do a lot of counter-intuitive things in Scrum, by looking at Lean we can see why they make sense.
3. Techniques for Improving Distributed Scrum Teams: an encore presentation of my Oct 1st talk at XPSD session about my work in Shanghai this year.

Come to XPSD on October 1st where I will share my ideas and experiences gained while in Shanghai.  I am not sure if I will turn my presentation into a post, but I will give away my key point now: you will have much more impact improving the performance of your Scrum teams by providing soft skill training to the ScrumMasters rather than training on hard skills, i.e. estimation, Planning Poker, Scrum mechanics, etc.

Just wanted to let people know that I will be the speaker at the XPSD meeting in September.  I will be talking about my experiences coaching Scrum teams in China and my insights on what essential skills a ScrumMaster needs to be successful.

Update: this was postponed until Oct 1st due to my knee surgery.  The topic will be the same – CEN 09/03/2009

I will be attending my first big Agile conference this year in Chicago from Aug 24 to Aug 28.  The program for Agile 2009 looks really good and some friends of mine, Lleywelln Falco and Dan Gilkerson, from XPSD are speaking on Approval Tests.  This should be a good time to connect with old friends and make new connections.

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.

I am quite busy with the presentations lately.  Next up is an appearance at XPSD on December 4th where I will run a workshop showing how to use some simple tools to chart and monitor an Agile transition for your organization.  This will be a hands-on session.   The tools I will be demonstrating come from my Design for Six Sigma work.   Look forward to seeing you in December!

Cory Foy made an interesting comment today on the XP mailing list. I’ll quote the part which I found interesting:

” My theory is that while we supposedly “Crossed the Chasm” from Early Adopters to Early Majority in the Agile world (referencing emails from about a year ago), we are now trying to cross a second chasm – that between Early Majority and Late Majority.”

While I respect Cory immensely, my experience with moderating and hosting XPSD suggests we have a long way to go as a community before we approach the Late Majority. The demographic that comes to XPSD are in their mid-30’s to mid-40’s (of course, we have younger and older present) who generally work in small teams or at small companies. We mostly have technical people come to our meetings each month with the majority of folks being people who write code for a living.

If we were approaching the Late Majority, then I would expect to be seeing the crowd at XPSD getting a little grayer (we all are getting a little grayer these days, but that is beside the point) and coming from the more conservative organizations and companies – defense contractors, the big biotechs and financial companies. I would also expect to be seeing more of the manager types and supplementary roles associated with software development – the testers, SCM and tech writers. I’d also expect to see a spike, or an increasing trend, in the number of people signing up on our mailing list.

While I wish it were true all these things were happening, I am not seeing it in San Diego. I think as a community, we are still just beginning to penetrate the Early Majority.

[Update - Aug 13] Seems like I am not the only one who questions Cory’s (and Scott Ambler’s) assertions that Agile has crossed into the Late Majority - Dave Nicolete is skeptical as well (here and here).  I agree with his choice of words that Agile is still seen as an “experimental” or “alternative” way to develop software.