Gunjan Doshi

I am designing a workshop. One of the presentations in the workshop is titled ‘Principles of Extreme Programming’.

As Martin Fowler talks about it in his blog entry here, the principles of XP are hidden and less talked.

From the first edition of the book, Kent Beck says “From the four values we derive a dozen or so basic principles to guide our new style. We will check proposed development practices to see how they measure up to these principles”.

Most of the principles are common sense. Now, as we all know, common things are less valued and less remembered. I feel keeping these in mind will help learn and exercise the practices better.

Continuing from the book, each principle embodies a value. A value may be vague but principles are concrete.

e.g. On one of a recent projects I coached, the team had a value of Fun. e.g. Pairing for one individual was fun, but for someone else on the team it was actually boring. However, principles like “Rapid Feedback” are more concrete. A simple question like “Are we having fun while pairing. If not, why? What is the learning here? How can we make it fun?”.

When I coach I always tell the team about another principle “Do not assume anything!”. Programmers often assume requirements; Customers often assume the status. I tell the team “Do not assume anything, ask questions”. Of course, they have to assume simplicity.

Now, can the team evolve their own principles or the 15 principles cover everything. I feel the principles need to be evolved. Let us wait for Kent’s 2nd edition and see if the orignal set of principles have evolved.

Following are the orignal 15 principles are written by Kent.

• Rapid feedback
• Assume simplicity
• Incremental change
• Embracing change
• Quality work
• Teach learning
• Small initial investment
• Play to win
• Concrete experiements
• Open, honest communication
• Work with people’s instincts, not against them
• Accepted responsiblity
• Local adaptation
• Travel light
• Honest measurement

Tags: No Comments