Reading further into Extreme Programming, my impression is that it's the most comprehensive attempt to address the requirements of Wicked Problems I've seen so far. Given Wicked Problems are not confined to software, I'm sure many of the practices translate to e.g. developing consumer products or delivering a consultancy service. One concept in XP, for example is ClearTheFog (apologies for the lack of spaces, its a programmer thing). In a sense nothing radical,it just says produce something - anything - that will help clarify requirements. But how often do knowledge workers get a vague request and respond by doing the quickest thing possible to test if they're on the right track? In business we may call it a straw man, but I've seen people spend months producing straw men - that's a huge risk to carry. So its not that people outside sopftware development don't intuitively know these practices, but that in XP their use is enshrined.

Note too that many XP principles are entirely conter to the trajectory most organizations are taking their knowledge workers. While most business publications talk about tele-working, virtual teams, global teams, hot-desking and outsourcing parts of your business process (e.g. services to your employees), XP advocates putting all developers and a customer representative in the same room, collaborating by sitting side-by-side, sympathetic desk arrangements and 'stand up' meetings.

The implication? If you are responsible for a workplace that tackles wicked problems, do you have a strategy that's moving towards XP principles or away?

The Costs & Benefits of Pair Programming
Excellent article on pair programming, a key feature of Extreme Programming - XP. It set me thinking about the wider implications for knowledge work. The claimed benefits are:

* fewer bugs so cheaper overall
* more fun
* people learn best practice from each other
* project gainst robustness can can survive losing people - (nicely put as upping a project's 'truck number' - how many team members must a truck hit to take out the project?)
* programmers can 'tag wrestle' problems so that as one person't energy fails, the other can take over.

For me, as a KM practioner not working with software developers, I'm wondering where else it could be applied. I've had some great 'lock yourself in a room with a colleague' sessions. But these involved us working in parallel on different parts of the same task. Benefits were easy communication to clarify ideas, align interpretations and help out with blocks. They also reduced my tendency to find distraction tasks whenever I get stuck just out of a sense of social obligation. However, I find, say, drafting an e-mail with somebody else at the keyboard excruciating. I'd only do it when absence of errors and immediate consensus were so important that it was worth the agony (memo-type e-mails have to be right first time).

The article also makes a link to apprenticeship and the legitimate peripheral participation concept of Lave and Wenger. If you consider non-IT work there are some good examples. It'd be quite natural for the apprentice salesman to work with the old hand on a pitch, for example, or think of apprenticeships in plumbing, building etc. What seems to be the barrier is that knowledge-workers are wedded to the solo-user norm of IT interfaces.

Can you really debrief people to reduce the impact of them leaving? I've just been on a trip to help part of my organization debrief a retiring expert. Now, if I had put it to them bluntly, they were well aware that 20+ years of accumulated knowledge could not be conveniently extracted for them in a day - knowledge can't be tinned like tuna. However, it was certainly the fear of that loss that had prompted action. I had mixed feelings - helping out reinforced the misconception that it was feasible, yet surely it was better than nothing?
I tried to focus on assisting dialog with 'apprentices', rather than codifying anything. I also did a quick 'expectation' setting of why 'flavour' of knowledge could be transferred ('FASHEN' adapted from Snowden's model) - %ages represent how much of that flavour we could hope to transfer.
Facts - declarative knowledge. Yes. But most people know it in the field. 50%
Artefacts - documents etc. Yes. focus on structuring and context of when others should use. 25%
Skills - could be taught, but only over a long period 0%
Heuristics - rules of thumb, 'natural' theories. Depends on expert about how well they can articulate these. 5%
Experience - can be reflected in stories, say 5%
Natural Talent - non-starter 0%

Not a very encouraging picture. I was left with the feeling that what people value in an expert is not the depth of their knowledge but their ability to articulate just the right bit at the right time when asked a question. So its not the content at all, but the skill of retrieval that makes the difference.

I took a nostalgic look at the Aion Rule-Based System. I used to be a consultant for this tool. Masses of potential for e-commerce, but few people seemed to 'get' what if offered. Looking back, the big problem was that programmers weren't brought up to think this way, so it wasn't that the software model was flawed, but that the organizational change of replacing database-thinkers with rule-based thinkers was too great. The more acttive companies like Firepond and Inference (now called e-Gain) are wisely positioning themselves in CRM for the timebeing.

I was recently chatting to a conference organizer looking for new angles on KM. I mentioned that I thought the field had failed to carry over much of what was learned in the early days of Expert Systems (akak Rule-Based Systems and Knowledge-Based Systems). Its been a while since I worked in the field myself and I was alarmed to discover just how dead my network was.
However, there are still some good products out there (e.g. Firepond) and Aion that ares till being put to good use behind the scenes. Anyone driving a B2C website or call centre that has high training costs would still do well to look at this technology as a way to automate knowledge-rich processes.
Philosophical -aside: Expert Systems are about the only case where computers are doing more than storing and manipulating information\data, for those that get hierarchical about such distinctions.

Rats! My lack of faith in Blogging has already been shaken by David Buchan who responded to my request for people interested in KM & XP to contact me. He has a lively KM-related blog of his own - watch that space.
thought?horizon