XP2006 is over. Here's the first in a series of writeups about what happened.
The XP2006 conference in Oulu, Finland finished the other day. I’m not finished with my visit to Finland, however. I’m going to be in Helsinki next week and I’m sitting here in the hotel room glancing at the midnight sun as it peaks through the curtains and wondering how anyone gets used to it. It’s cool, but to a guy from Florida, well, let’s just say it’s very different.
I was here doing a tutorial on team health indicators and coaching with David Hussman. We had a good crowd in the tutorial and plenty of discussion as we went through close to thirty indicators of health or dysfunction we’ve encountered in teams. We had done some work prior to the tutorial to see if we could find a taxonomy for them, but we didn’t have much luck. More than anything, we were really trying to indicate what we had seen with teams and ways that we had approached particular problems. I think we got that across even though the material didn’t seem to fall into a neat structure. In retrospect I don’t know why we should be surprised by that. After all, life is rarely neat. We were trying to convey experience and a sense of what we do even though it’s hard to capture with theory. That doesn’t mean we’ll stop trying, however.
Design Intuition and Design Decision Making
Later in the conference, I met Carmen Zannier. Carmen was there presenting a paper she cowrote with Frank Mauer entitled ‘Foundations of Agile Decision Making from Agile Mentors and Developers.’ Essentially, their research shows that agile mentors and developers tend to use a naturalistic decision making style (NDM) rather than a rational decision-making (RDM) style when they make design decisions. The distinction is hard to summarize accurately in a blog, but the kernel of it is that NDM tends to draw more on intuition formed by experiences, reading, etc, while RDM involves looking explicitly at all available options, weighing them and then explicitly choosing the optimal one. It’s interesting research; and I have a feeling that the conclusions are true for most development, but perhaps to a lesser degree. In any case, it connected with thoughts I’ve been having about the possibility of teaching design intuition directly. It’s great to see this sort of research happening.
The week went on with many other sessions, and a lot of hallway conversation. One hot topic was Agile Convergence. Steven Fraser and Charlie Poole hosted a goldfish bowl on the topic and there was a lot of talk leading up to the session and following it. The conversation was rather involved and the worlds “unification” and “standardization” came up a number of times. There was a sense that Scrum with XP coding practices was the dominant hybrid out there today. The most common current adoption path seems to be "we (business) want to go agile, we try scrum, we discover we need to adopt more discipline during our sprints, we adopt some XP practices." We've been seeing that scenario in the field over and over again. As scenarios go, it isn't bad in my opinion, but I do think that that path does only nick the core of one of the biggest problems facing any organization transitioning to agile: adopting it end-to-end.
For many reasons, I’m not surprised that this topic is coming up now. As Bob Martin pointed out in his keynote at XP2005, the industry is treating Agile as a menu and it has been for a little while now. People aren’t saying let’s go full-bore XP, or Scrum, or FDD, they are trying things out and picking agile practices on a piecemeal basis. From my point of view, that is clearly a win for businesses who want to be adaptive. It’s not much of a win for businesses who want things in neat little boxes, however. We've already seen a flurry of "neat box making" exercises in agile. I don't think the question is whether one of them will "cross the chasm" but rather whether enough businesses developing software will have gumption to step forward and embrace their own tailorings of agility. It seems to be going that way, and I'm optimistic that it will continue.
Next installment: Post-Agilism, TextTest, APL, Politics, Religion, and Team Synergy.
> NDM tends to draw more on intuition formed by > experiences, reading, etc, while RDM involves > looking explicitly at all available options, > weighing them and then explicitly choosing the > optimal one.
I've mentioned before my thought that George Lakoff's Strict Father / Nurturant Parent model of the conservative / liberal political split seems to me to apply to the CMMI / Agile split as well. I'm now reading his latest, Whose Freedom?, in which he spends some time elaborating that conservatives tend to prefer simple explanations of causality and liberals to prefer complex, systemic explanations. It sounds like RDM could correspond pretty closely to the "simple explanations" and NDM to "complex explanations".
At SolutionsIQ we do see a definite trend with our customers for using Scrum and then finding issues which need resolution since Scrum seems to make existing issues easily visible. After those issues are found many can be tackled using existing Agile techniques such as TDD, continuous integration, and continuous code review (pair programming). There are the others which are not so easily handled by existing practices and must be resolved through personalized coaching and mentoring. The solutions to these issues seem to fall in line with the NDM approach to design. We have multiple coaches and mentors in our organization which help on these matters including myself. There is definitely not always a clear cut solution to a problem and many times you must have the ability to help the customer come up with the solution themselves.