In my role as moderator of XP San Diego I was able to arrange for Mike Cohn to speak about Agile transitions to our group. Last year when Mike was in town, we were also able to arrange for some of his time. Mike is a great speaker and I am looking forward to his talk tonight.

Last weekend I started practicing with the San Diego Armada - a beginner’s rugby league in San Diego. When I went to the Agile Coach Camp in Michigan, William Pietri suggested that to be an effective coach, one needs to learn how to do something new from time-to-time. It is important to remember what it feels like to be a beginner and do the stupid things that novices do because they do not know any better. This helps you understand the struggle novices are undergoing when they learn the new Agile practices and methods, be more humble when working with people and be patient with their rate of change.

So here is what I learned this weekend going out for rugby for the first time:

1. Catching a rugby ball is not that hard. When I showed up for the drills people were in circles throwing the ball and I was really nervous that I would have to catch the ball. DUH! It’s rugby, you need to catch the ball. Catching a rugby ball was not that hard once someone showed me how to do it.
2. You need to be running before you call out “Ball!” Since there are no forward passes in rugby, you have to be moving on your teammate before shouting for a pass. If you are just standing still, i.e. flat on your feet, you will not get a pass and if you do, you’ll get tackled and the play is over.
3. Pick your head up when running with the ball. You cannot find the holes in the defense if your head is down. Also, don’t be afraid of the tackle – you’re not made out of glass.
4. Listen to what the experienced players are telling you. They already know how to play the game and if they say you’re offsides, you’re offsides. OTOH, if you ask them a question, they will explain a law or game strategy to you. Since this is a beginner’s league, they are tolerant of errors, but learning how to play the game is your responsibility.
5. Rugby is hard. I thought I was physically fit, but when you run around and play rugby for two hours (yes, that is how long practice was), it takes more energy than you think. Working out and getting fit in the gym is no substitute for playing on a team.
6. I am not the best, but I am not the worst. Since I did not really understand how to play the game, there was not a lot in my performance that was worthy of praise – I was always out of position, offsides frequently, my passes were sloppy, etc., etc. – but a few of my teammates still found the opportunity to praise some aspects of my play when I did something right.

The other day we were talking about DfSS and how much training material we were going to produce and what sort of timelines we could commit to. I was having a hard time wrapping my head around the scope of the problem because it seemed very large and undefined. Specifically, I was thinking I had a LOT of original training I needed to create around some Agile code practices. Somewhere along the way I had missed aan important concept about my role on the DfSS rollout team. For some reason, I was under the impression that DfSS was about making better engineers.

“Noooo. DfSS (DESIGN for Six Sigma) is about taking good engineers (people with good skills and proven engineering aptitude) and training them to become good designers.”

While had been consistently told that DfSS is the program is about “designing quality into the system”, what I heard was “building quality into the system”. During the implementation (ostensibly the work that happens after DfSS), quality engineering practices are monitored and controlled via the scorecard. It is through the scorecard that good engineering practices like continuous integration, automated unit tests,refactoring, etc., etc. are implied to the Team. During implementation, you have to do “something” which will satisfy the scorecard, that “something” is up to you.

Call me a bit skeptical about using the scorecard as a control mechanism for good engineering practices. I feel comfortable that the design coming from DfSS will be excellent, reflect the Voice of the Customer and be marketable, but leaving implementation as a black box to be monitored via a scorecard at phase gates ,or through periodic in-process reviews, leaves me less than satisfied. It seems to me that DfSS relies heavily on the ability of the DfSS Black Belt to bring both an excellent design AND quality engineering practices to the implementation team. In many of the environments I have encountered, there is big gap between the skills of the designers and the implementation team. It might be a bridge too far, I don’t know.

At my current location we develop products that are regulated by the FDA, so we must have a quality system based on CFR Title 21, Part 820. Around here, that quality system is called the Global Development Process or GDP. However, those regulations do not tell you how to build a quality product, just that you need to have a documented process and you need to follow it. Because the FDA allows companies to define their own quality process within the guidelines of Title 21, Part 820, when auditors come for an inspection, what they are looking to see if we are adhering to our own process.

For us, the GDP is simply the minimum requirements we must follow in order to be in compliance with the FDA. While our GDP explains the deliverables we must create and when, it does not provide any guidance on how to produce these deliverables. In addition, it is my understanding that while the GDP is focused on compliance for the FDA, it does not show how to build excellent products within the GDP. I am now part of the core team which will create a set of Lean tools that will help us create excellent products that excite our customers and better help their patients. This concept is calledDesign for Six Sigma (DfSS) and has been described to me as a way to build quality into our new products. I have been selected to be on this team to provide an Agile viewpoint and create tools that will aid software engineers make more robust products and apply widely-used “best practices”.

At first glance, DfSS sounds a lot like waterfall and I am a very Agile guy at heart. Initially, I was very skeptical about this initiative, but I have changed my thinking. This could be a very interesting avenue of study since most of my experience has been working on small teams creating small products using lightweight tools. However, big companies with complex hardware and software requirements, especially ones regulated by the FDA, need a different set of tools, tools that are a more heavyweight than I am used to.

I am not certain that the concepts of DfSS and Agile can be combined, but what intrigues me is the emphasis on the Voice of the Customer (VOC). If we remain committed to learning the VOC and focused on what the customer’s user needs, I can see how Agile and DfSS can play nice together. How that plays out in real life remains to be seen, but I definitely have an open mind that something “bigger” than Agile is needed for big companies and DfSS might be it. Perhaps DfSS is the way big companies make products in a recognizably Agile way?

I found a really cool blog, Notes from Spain, about living in Spain from theNotes In Spanish people. I have been using the free podcasts to improve my Spanish comprehension and listening skills. This blog about what it is like to live in Spain provides a really great insight of how it feels to be an expat – a dream of mine for a while.