XP and XK

Extreme knowledge (XK) is an approach to learning, working and product delivery that follows principles & practices in extreme programing (XP). The intent is to reduce time to delivery, reduce risk, improve learning, reduce errors and promote understanding.

XK improves knowledge work in four essential ways; communication, simplicity, feedback, and courage. XK workers communicate with their customers and fellow knowledge workers. They keep their design open, simple and clean. They get feedback by testing their products starting on day one. They deliver their product to the customers as early as possible and implement changes as suggested. With this foundation XK workers are able to courageously respond to changing requirements and technology.

XK / XP "requires an extended development team. The XP team includes not only the developers, but the managers and customers as well, all working together elbow to elbow. Asking questions, negotiating scope and schedules, and creating functional tests require more than just the developers be involved in producing the software".

Extreme Programming (XP) was created in response to problem domains whose requirements change. Your customers may not have a firm idea of what the system should do. You may have a system whose functionality is expected to change every few months. In many software environments dynamically changing requirements is the only constant. This is when XP will succeed while other methodologies do not.

For my money, knowledge workers will greatly benefit by following XP practices and principles as these promote tacit knowledge transfers, foster learning and trust, leading to greater understanding, awareness and agility.

Resources:

XP Introduction

What is XP?

XP FAQ

Do you have any XK experiences to share?

Comments

[Mitra Ardron]

That is an interesting and useful split between the Business (User's) requirements and the Functional (Developer's) Requirements. But I would disagree strongly with your assertion that the Business requirements change glacially. That might be true in some legacy-automation environments, but in most of the environments where I've led development teams, the business requirements HAVE changed rapidly and unpredictably, because the business is changing. Typically this is either because our company has been selling a product - and different client's have different requirements. Or just because the world changes very rapidly these days, and software development for last year's requirements is not going to keep the company on that cutting edge.

While I've not used XP - it is similar to many of the techniques I used in reaction to the weaknesses of more classic programming methodologies. I think there is a lot that KM can learn from those kind of approaches, in particular having a focus on managing Knowledge in a rapidly changing world. The continuous feedback approach (many small releaseses, frequent testing) I think is crucial to actually building something that people can use.

[David Locke]

"Courage?" That's like making the claim that KM is about "The Good."

All work domains involve courage. That is where the worker's risk focus is. But, to use the word the way it was used here, makes courage an empty marketing claim. We all want to feel heroic, so we jump at being corageous. Sorry, the waterfall programmer is equally courageous.

[David Locke]

This statement is utterly false unfortunately:

"Extreme Programming (XP) was created in response to problem domains whose requirements change."

Why? Because problem domains do not change all that fast. Requirements change, because they are defined incorrectly by the software engineering community.

There are two sources of knowledge in a software developement project: the automated domain (the problem domain) and the automating domain (design/implementation domain).

This dichotomy is not reflected in what we commonly call requirements. We put the user's what and the developers what in the same pile. Unfortunately, the content of these two pile are different. The user's what (business requirements) are decisions. The developer's what (functional requirements) are constraints. It is the functional requirements that change, not the business requirements.

Business requirements do change. But at the glacial pace of a paradigm change.

I attended a workshop where we were to implement a web-based, conference registration system. The problem is that "web-based" isn't a requirement it is a constraint. A useless constraint. Why useless? Ask yourself what this requirement statement would look like twenty years ago. It would have been phrased as implement a mainframe based conference registration system.

In those twenty years, what changed in the "conference registration domain." Nothing!

Implementation is all about constraints. Design is about aligning the business requirements with the implementation constraints. What happens to the functional requirements? They either migrate to the implementation component or they are what is called characterization, or emergent behavior. The need to get a transaction done in 3 seconds happens. It constrains the design, but so does the use of a database or some other technology. It is totally irrelevant to the user, except for the administrative tasks that it creates.

There is another argument against the statemet quoted above. This stems from the historic path that lead to XP. Certain aspects of object-oriented programming were abused. And, academia saw the object-oriented paradigm as a force for deskilling or deintellectualizing application development. Keep in mind that ACM defined computer programming as a mathematics-based discipline to keep it from becoming a trade. These same people abandoned OO, because it was too easy in terms of aligning the model with reality. So there was a backlash. The pattern movement arose from these forces. Patterns force developers to abstract away from the real and create a more complicated and disconnected model.

Then, came refactoring. Refactoring makes no claims about complexity. It doesn't make it simpler. It just doesn't make it complex as early. The architectures arrived at by refactoring are just as complicated as those designed by the waterfall or spiral or design-to-schedule or XP or code and fix.

Anyway, problem domains had nothing to do with it. The source for that statement was an insider tryting to justify or sell what they did to the people who are not yet adopting XP or Agile. The statement is a marketing claim.

There are five software lifecycles. Each works in certain situations. Individually, they are only better in those situations. XP can be better. But, XP is not universally better.

Still XK is a cool concept to explore. I still have a problem, however, with the notion that I am going to have some requirements for tacit or implicit knowledge and I am then going to build an explication process to meet those requirements. It doesn't happen that way, particularly if you are talking about social construction.

I know that the XP people don't work from requirements or do design or code, except that they do regardless of whether they want to use those terms. I don't see those terms as phases in some methodology, but rather work involving specific artifacts and specific goals.